2

We are trying to upgrade our code base to use Visual Studio 2010 but are having problems getting everything sorted on our build servers. We do not want to install Visual Studio 2010 on our build servers and so have installed just the .Net 4 framework and SDK (v7.1).

We are still wanting to target the .Net 3.5 platform (we will upgrade to .Net 4 at some point in the future but do not want to just yet).

We have managed to get the code to compile but now we are running into runtime errors like the following.

Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

The problem is that runtime is trying to deserialize the embedded resource and if I look at the resources in reflector, I see that they are all .Net 4.0 objects. For example, the icon of our a windows app is of type System.Drawing.Icon, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.

So it looks like MSBuild is compiling the resources incorrectly (using a different runtime to the target)? I have confirmed this by looking at the diffs of the dll built on my dev machine and that built on the build server - it is clear to see that one dll's resources use 2.0.0.0 version and the other (from the build server) uses 4.0.0.0. The project references are to the v2.0.0.0 dlls in both cases (as one would expect).

Does anyone have any idea as to why MSBuild is compiling the resources as 4.0 objects?

Thanks in advance.

Chris

Chris Fewtrell
  • 7,555
  • 8
  • 45
  • 63

1 Answers1

3

When you upgraded your solution to VS2010, did you change the targeted framework? You can look for it by viewing the csproj files in a text editor. Do you have the 7.0a framework in your build server?

EDIT :

I ran into the same problem a while ago and it has something to do with registry key not set. Take a look here : http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources

I think you need to manually add the registry key HKLM\Software\Microsoft\MsBuild\ToolsVersions\SDK35ToolsPath

Benjamin Baumann
  • 4,035
  • 2
  • 25
  • 35
  • When we upgraded the projects, we kept the target framework version as 3.5. The build servers do not have the 7.0A SDK installed (they have the 7.1 SDK). [The 7.0A is installed with visual studio and we have not installed that on the build servers]. – Chris Fewtrell Nov 24 '10 at 08:39
  • SOrry, I was tired last night. Which "ToolsVersion" do you use in your csproj? – Benjamin Baumann Nov 24 '10 at 14:00
  • That link looks very interesting - I have checked on our buildserver and we have the same mis-named keys. I am 99% sure that you have identified the problem (so I will mark it as the answer): I have not tried the work around because, as a result of all the problems we were facing getting our 3.5 targeted code to build that we would upgrade our solution to .Net 4.0. – Chris Fewtrell Dec 16 '10 at 08:04