Correct usage of NuGet installation

Apr 8, 2014 at 9:42 AM
Hello,

I'm using MSBuild Extension Pack as a NuGet package. In order to have access to the Extension Pack's task during build process I have following lines in my project file:
  <PropertyGroup>
    <ExtensionTasksPath>$(SolutionDir)\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\</ExtensionTasksPath>
  </PropertyGroup>
  <Import Project="$(ExtensionTasksPath)MSBuild.ExtensionPack.tasks" />
Works fine as long as MSBuild.Extension.Pack.1.3.0 is installed. But in case of fresh checkout project file fails to load due to absence of MSBuild.Extension.Pack.1.3.0 package which needs nuget restore to fix it.

What would be the right way to use the tasks during the build process without corrupting project file?

Thanks
Apr 14, 2014 at 9:06 AM
I didn't entirely understand what the problem is.
If the MSBuild extension pack package exists and checked in to TFS (or Git), a new project will have to have the same import line you wrote above in order for it
to be able to use the extension tasks. I wouldn't call it "corrupting" the project file.....

Can you elaborate on what exactly you find wrong with that?
Apr 14, 2014 at 9:31 AM
The point is not to check in MSBuild Extension Pack package to the version control system as NuGet manages to get the relevant package data. In this case you have a "corrupt" project file as long as package restore is not executed. A possibility to avoid this "corruption" is to add Condition="Exists..." to the Import.
Apr 14, 2014 at 10:28 AM
Ok, i see, wasn't aware before of the need not to check in packages to source control, but let nuget download missing packages instead ( I myself find little use for that). Anyway, according to this link:using-nuget-without-committing-packages,
you need to have a special *.targets import of nuget in order for that to work.

Do you use that correctly?
Apr 14, 2014 at 10:36 AM
As of NuGet 2.7 and above MSBuild Package Restore is deprecated. You have two ways:
  • Manual nuget restore execution on the fresh project checkout before opening project in VS - in this case everything works fine.
  • VS Automatic Package Resore - in this case you need the Condition in your Extension Pack Import. VS will load project correctly because you are not referencing not existent project and Automatic Package Restore cares of the package content.
Apr 14, 2014 at 11:05 AM
So it seems to me that the condition you suggested on the msbuild extension pack *.tasks file should do the trick, no?
If the package was not downloaded yet, you avoid importing a non existent file (using not yet defined tasks in various targets should not be a problem until you actually build the solution).

Then, when the package is downloaded, all should come into place and work just fine.

I'm guessing that in automatic builds you will use nuget cmdline to invoke package restore?
Apr 14, 2014 at 12:20 PM
That's right. Condition does the trick :)
In VS Automatic Package Restore cares about packages and command line restore on automatic build.
Marked as answer by mikeFourie on 4/20/2014 at 6:45 AM