CODEWITHSUNDEEP
msbuildteamcitynuget
Jammer
Jammer

Reputation: 10208

TeamCity - Microsoft.Bcl.Build Dependency

I've just committed some code changes to my repository and all of a sudden (after weeks of being fine). The TC build starts failing as it fails to download the NuGet package for Microsoft.Bcl.Build.1.0.6.

I ended up having to manually copy the contents of the packages directory to the TC build location which utterly defeats the point of NuGet.

What can I check to get to the root cause of this?

Everything about NuGet is enabled in the solution for getting packages.

Upvotes: 3

Views: 2542

Answers (4)

crimbo
crimbo

Reputation: 11211

This blog post is the most thorough one I've seen for explaining the workaround options:

http://blogs.msdn.com/b/dotnet/archive/2013/06/12/nuget-package-restore-issues.aspx

None are great IMO - this problem still needs a better solution.

But for the time being, the best recommended option is to check the Bcl.Build .targets file into source control - which means when the version of Bcl.Build is updated, you'll need to add the new .targets file, and remove the old one.

Upvotes: 1

crimbo
crimbo

Reputation: 11211

I think (but am not sure, so I created this SO question: What does the Microsoft.Bcl.Build NuGet package do?) that Microsoft.Bcl.Build is only needed for development, and is not needed on a build server. So, I have a Builder.targets file that only exists in the build environment, that is indirectly <import> ed into all of our projects, which includes this bit of MSBuild xml:

<!-- Skip Microsoft.Bcl.Build functionality when building only from Source.  Presumably Microsoft.BclBuild is only needed for development. -->
<PropertyGroup>
  <BclBuildImported>Ignore</BclBuildImported>
</PropertyGroup>

Since the block of MSBuild logic inserted into your project by the Bcl.Build nuget package is dependent on the BclBuildImported property being empty, this effectively sidesteps the problem in my build environment - the Microsoft.Bcl.Build steps are skipped, and it no longer breaks my CI builds.

Note that since it appears that this package manages binding redirects in your app.config, and ensures that transitive dependencies are included in your projects, it's important to leave in for development. But I'm not currently aware of a need for it in a build server environment.

Upvotes: 0

Sayed Ibrahim Hashimi
Sayed Ibrahim Hashimi

Reputation: 44322

I've blogged about this issue at http://sedodream.com/2012/12/24/SlowCheetahBuildServerSupportUpdated.aspx. To summarize NuGet package restore (prior to 2.7) is implemented as a part of the MSBuild build process. When MSBuild starts a build it will evaluate the project file and any Import declarations importing other files. This happens before any target gets executed.

Since NuGet pkg restore is a part of the build process the .targets files get restored at a point in time that it is too late for the Import statement to have any impact.

You can work around this by either checking in the .targets file as you stated, or by invoking pkg restore before the build process. I've created a NuGet package, PackageRestore, which can help with the latter approach.

To use PackageRestore just add the NuGet package to your project which will automatically create a file named packageRestore.proj in your projects directory. When configuring your build, you will need to build that item before your .sln/.csproj file.

Upvotes: 5

Jammer
Jammer

Reputation: 10208

OK This is a bit of a nasty issue.

If you are having this problem you need to do something rather ugly to your repository.

Make sure you are checking in the packages\repositories.config file.

Then if your build is failing with unresolved references to Microsoft.Bcl.Build you will need to also checkin the .targets file for this package. eg:

package\Microsoft.Bcl.Build.x.x.x\tools\Microsoft.Bcl.Build.targets

Hideous ...

Upvotes: 2

Related Questions