News
NuGet Package Restore Workaround
Microsoft responded to developer reports that two Microsoft package files, Microsoft.Bcl.Build and Microsoft.Bcl.Compression, have been breaking the NuGet package restore feature. In a .NET Framework Blog post, Microsoft's Immo Landwerth describes the problem: "Microsoft.Bcl.Build and Microsoft.Bcl.Compression require custom target files, which do not work well with NuGet's package restore feature."
Landwerth explains that each time a NuGet package is added to a developer's solution, NuGet downloads the package, puts it into the solution in a "packages" directory and installs the package. The installation "will add references to additional framework assemblies, references to assemblies provided by the NuGet package, add additional content to [the] project and last, but not least, import any custom target files," Landwerth writes. However, he adds, "In order to build your project on a build server you have to check in all sources as well as all third-party libraries. Many developers cringe when binaries need to be checked in to version control as they typically aren't stored very efficiently and cause bloat over time."
This problem can be solved with the NuGet package restore feature, which must be explicitly enabled within a solution. Landwerth describes the package restore functionality: "After package restore is enabled you can delete the 'packages' directory from your solution. Rebuilding the project will automatically re-create this directory and retrieve all missing packages; whether they are downloaded from the Internet or a local file share. This allows excluding the packages directory from version control as the build machine can retrieve the packages and thus doesn't need a checked-in version of the NuGet packages."
Developers have reported issues with the package restore feature and the Microsoft.Bcl.Build and Microsoft.Bcl.Compression files. These two files provide a custom target file, a "file that provides additional functionality that extends the build process," Landwerth writes, adding: "We use [custom target files] for several features for which NuGet doesn't provide declarative features today."
Developers are receiving error messages when these custom target files can't be located at load time. "Installing Microsoft.Bcl.Build will change your project by adding an <import> entry for the target file to your project," Landwerth explains. "The target file is located in the packages folder … [And] if package restore is enabled, it's likely the packages folder is excluded, so the .targets file isn't available on the build machine."
For now, the Microsoft .NET Framework team is suggesting this workaround: "The easiest way to fix the package restore issues is by checking in any .targets files that are stored under the packages directory," according to Landwerth. Developers can also "explicitly run package restore before building the project," he notes.
"We understand that this isn't a good long-term solution and are working with NuGet to greatly reduce the need for custom .targets files," Landwerth writes. "The idea is to add some features that allow packages to be declarative as opposed to adding code that runs during the build."
About the Author
Katrina Carrasco is the associate group managing editor for the 1105 Enterprise Computing Group. She can be reached at [email protected].