2

My colleagues are confused that from Visual Studio I can build a solution and have NuGet packages created from the projects automatically. Of course this is because I added to my csproj files the following to the first PropertyGroup:

<BuildPackage>true</BuildPackage>

My colleagues don't trust this capability and don't want to adopt it because they don't see it documented anywhere. They are afraid it is a non-supported customization that should not be utilized.

I believe they are mistaken in their conclusions, but I do concede it is bizarre that there is no documentation. The only reason I knew about the feature is because I read the the NuGet.targets file. Searching for documentation after-the-fact, the only thing on the internet I've found is a single SO post that simply mentions the BuildPackage property.

Can we do better than this? Where is there documentation that mentions this property, along with how and when to use it? It's a shame to hear "that usage is forbidden because it is undocumented."

Community
  • 1
  • 1
Brent Arias
  • 26,187
  • 32
  • 120
  • 209

2 Answers2

3

Creating your package by adding the BuildPackage property to your project file is documented/transparent (see below), but the NuGet team no longer recommends using the mechanism that adds support for that property, "MSBuild-Integrated Package Restore":

Prior to NuGet 2.7, an MSBuild-Integrated Package Restore approach was used and promoted. While this approach is still available, the NuGet team suggests using the Automatic Package Restore and Command-Line Package Restore instead.

Correspondingly, in the 3.0 version of the NuGet Visual Studio extension, the "Enable NuGet Package Restore" context menu item will be removed.

As you discovered, BuildPackage is a target defined in the .nuget\NuGet.targets MSBuild file that Visual Studio adds to your solution if you perform "Enable NuGet Package Restore". 

<Target Name="BuildPackage" DependsOnTargets="CheckPrerequisites">
    <Exec Command="$(BuildCommand)"
          Condition=" '$(OS)' != 'Windows_NT' " />

    <Exec Command="$(BuildCommand)"
          LogStandardErrorAsError="true"
          Condition=" '$(OS)' == 'Windows_NT' " />
</Target>

The Exec task invokes cmd.exe; $(BuildCommand) is a property defined in the same file:

<BuildCommand>
$(NuGetCommand) pack "$(ProjectPath)" -Properties "Configuration=$(Configuration);Platform=$(Platform)" $(NonInteractiveSwitch) -OutputDirectory "$(PackageOutputDir)" -symbols
</BuildCommand>

$(NuGetCommand) will evaluate to .nuget\NuGet.exe within your solution directory.

So in the future, although automatically adding these msbuild nodes will not be supported, you can add them to projects yourself or use other means to execute exactly the same (fully-supported) command-line nuget pack.

weir
  • 3,914
  • 2
  • 23
  • 36
1

I know this post is a bit old, but I am also taking advantage of this property and am curious to know it's fate. The easiest way to make the "feature" work "correctly" that I found was to use "Enable NuGet Package Restore" on my solution, then add the property to the projects that I want to output a package. This way I did not need to add the Nuget.targets import and the $(SolutionDir) property definition to each project in my solution. This is a great "feature" because I don't need to maintain .nuspec files as long as my AssemblyInfo metadata is correct. It's worked great so far... until I discovered that as of Nuget 2.7, the "Enable NuGet Package Restore" method is considered obsolete and should not be used. So...it would be good to know if this "feature" is supposed to be used.

brosenquist
  • 39
  • 4