I just spent a couple of days debugging a weird problem. We have a fairly large product that has several Visual Studio solutions in it, all of which target .NET 3.5. No, that's not the problem. The problem was that we were able to build each solution separately in the correct dependency order just fine, but when the whole thing ran together in an automated fashion, the build would fail.
The failure message indicated that an extension method was not being recognized. Something like:
'Foo' does not contain a definition for 'Bar'
Again, it would build on its own, but not in the larger environment. What gives?
I figured the problem had to be the targeted .NET environment - that the project was targeting .NET 2.0 when run in the larger build but .NET 3.5 when run alone. And I was right, but not how I thought.
As it turns out, a custom build task run in an earlier build was setting an environment variable called COMPLUS_Version to v2.0.50727, which forced everything after that to run in .NET 2.0.
I had no idea such an environment variable existed. Doing a quick Google search on it, the only documentation on it has to do with build and test environments forcing things to run in different .NET versions, like if you're building something for .NET 1.1 and want to see how it runs in .NET 2.0. I searched MSDN and other sites, but I can't actually find any "official" documentation on this. It's just one of those things you figure out.
Valid settings for COMPLUS_Version seem to be the same as the names of the folders you see when you go to the %WINDIR%\Microsoft.NET\Framework directory, like:
- v1.1.4322
- v2.0.50727
- v3.5
...and so on.
Setting the value will force future processes in that space to use the specified .NET runtime, like:
set COMPLUS_Version = v3.5
That would force everything to run in .NET 3.5.
And we tried that - doing a set to .NET 3.5 to force everything to that runtime, but we then ran into another issue: We were using the vsdbcmd.exe program to do some database work during a build (that's another story) and if you force it to run in .NET 3.5 you get the error:
To run this application, you must first install one of the following versions of the .NET Framework:
v3.5
Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework
That made no sense to me since I obviously have .NET 3.5 installed.
The answer was to get rid of COMPLUS_Version entirely. After the custom build task ran, set the variable, and completed its work, we used the MSBuildCommunityTasks "script" task to unset the environment variable:
<PropertyGroup>
<SetCode>
<![CDATA[
public static void ScriptMain() {
System.Environment.SetEnvironmentVariable("COMPLUS_Version", null);
}
]]>
</SetCode>
</PropertyGroup>
<Script Language="C#" Code="$(SetCode)" Imports="System" />
Doing that removes the variable from the process space and later executables can allow the CLR to choose which environment to target automatically.