Question

I have a .NET 4.0 application which uses Microsoft.Bcl.Async for async/await support, developed under Visual Studio 2012 in a Windows 8 machine. It builds fine in my machine and it runs fine in other environments (XP/Vista/7).

My build server setup is Windows Server 2008 R2, .NET 4.5 installed and TeamCity.

My build configuration fails to build my solution, with the following error:

GenerateTemporaryTargetAssembly 
GenerateTemporaryTargetAssembly 
Ferox.Local.Wpf\uf4edrwb.tmp_proj 
CoreCompile 
Csc 
MyClass.cs(8, 29): error CS0433: The type 'System.IProgress<T>' exists in both 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll' and 'c:\TeamCity\buildAgent\work\80d9f16a33820be7\packages\Microsoft.Bcl.1.0.19\lib\net40\System.Runtime.dll'

The build configuration is set to Visual Studio 2012. I've checked the agent requirements and it includes a dependency on "DotNetFramework4.5_x86". Hence it must be using .net 4.5 msbuild, as stated here.

I've removed the packages (Microsoft.Bcl.Async, Microsoft.Bcl, Microsoft.Bcl.Build) and added them again. No difference.

I'm running out of options. Any ideas?

EDIT

As I said, I've just set TeamCity and my build configuration is pretty simple. First it checks out the branche from svn.

It has a build step with runner type "Visual Studio (sln)", Visual Studio version is 2012, "Targets" field is "Clean, Build", and the configuration is "Release".

Additionally it uses "AssemblyInfo patcher" to update the version number.

UPDATE

I've followed Jon Skeet's suggestion and changed the runner type do MSBuild. Runner type: MSBuild MSBuild version: Microsoft .NET Framework 4.5 MSBuild ToolsVersion: none Run plataform: x86 Targets: Clean, Build Command line parameters: /P:Configuration=Release

It still gives me the same error.

I've changed the "MSBuild ToolsVersion" to "4.0" (even though I don't think there is any need, because the solution was created with Visual Studio 2012). Same error.

I've changed "Run plataform" to "x64". Same error.

UPDATE

My server machine didn't had the reference assemblies of .NET 4.0 (and 4.0.3). After seeing this post, I thought that might be the cause. With that in mind, I've copied the reference assemblies from my developer machine to the server. Then I tried to build the solution once again. Same error. I really thought I'd suceed that time...

UPDATE

I've tried restarting the server, to see if there were any updates hangging from the .NET4.5 installation affecting the build. Same error.

UPDATE

I've installed the Windows SDK for Windows 7 and .NET 4 in the server. And it finally builds sucessfully! However, I really thought that only copying the reference assemblies, following that Marc Gravell's post and Hans answer, should have fixed the build. I then searched the "...\Reference Assemblies\" folder to see if the sdk installation had added anything else. And then I realized my mistake: I had copied the reference assemblies to the server's folder "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework" instead of copying them to "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework". Hence the build could not find the assemblies.

Was it helpful?

Solution

exists in both 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll' ...

This is an old practice, the way it was done in .NET versions prior to 4.0. Where the reference assemblies where stored in the Framework directory. This is not the way it should be done anymore, it is quite lethal when you have .NET 4.5 installed and trying to build an assembly with .NET 4.0 as the target. The changes in 4.5 are too great, particularly for the plumbing that makes async/await works. Lots of other subtle problems, the ExtensionAttribute class was moved from System.Core.dll to mscorlib.dll for example. A pretty unsubtle change that a [TypeForwardedTo] attribute hides. But can't when the wrong reference assemblies are used.

Reference assemblies are now stored elsewhere, you must reference the ones in c:\program files\reference assemblies. Which has different reference assemblies for different .NET framework versions. The ones for the 4.0 desktop version are in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0 on a 64-bit machine.

It isn't that clear to me how programmers get into a pickle like this. Might have something to do with custom build scripts that started life many years ago. In general, first thing to try is to remove all .NET references and adding them back. Take a closer look at your build system if that doesn't help, the /reference compiler option is the one with the problem.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top