1
votes

I'm having a problem where my .Net build system is looking in the wrong folders for its framework references. The machine has .Net 4.0 and Visual Studio 2010 installed, and this problem happens on projects where the .Net version is less than 4.0 (my example is in .Net 3.5). The problem looked like build issues, but digging deeper into it, I found that Microsoft.Build.Tasks.v4.0.dll (called during the build process) is calling mscoree.dll and getting the wrong information back:

(decompiled source) FrameworkLocationHelper. ConstructDotNetFrameworkPathFromRuntimeInfo(string requestedVersion):

        int num1 = 264;
        int num2 = 25;
        StringBuilder pDirectory;
        StringBuilder pVersion;
        uint requestedRuntimeInfo;
        do
        {
            pDirectory = new StringBuilder(num1);
            pVersion = new StringBuilder(num2);
            uint dwDirectoryLength;
            uint dwlength;
-------->   requestedRuntimeInfo = NativeMethodsShared.GetRequestedRuntimeInfo(string.Empty, requestedVersion, string.Empty, 16U, 64U, pDirectory, num1, out dwDirectoryLength, pVersion, num2, out dwlength);
            num1 *= 2;
            num2 *= 2;
        }
        while ((int)requestedRuntimeInfo == -2147024774);
        if ((int)requestedRuntimeInfo == 0)
            return Path.Combine(((object)pDirectory).ToString(), ((object)pVersion).ToString());

The problem is the call to NativeMethodsShared.GetRequestedRuntimeInfo(...), which on other machines returns the version of .Net that is being requested (3.5, 3.0, and 2.0) but on the problem machine returns 4.0 each time, resulting in reference paths referencing .Net 4.0 (which shouldn't happen in a .Net 3.5 build). Unfortunately, this is a call into mscoree.dll, and I don't know how to debug this or find the source code:

[DllImport("mscoree.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern uint GetRequestedRuntimeInfo(string pExe, string pwszVersion, string pConfigurationFile, uint startupFlags, uint runtimeInfoFlags, StringBuilder pDirectory, int dwDirectory, out uint dwDirectoryLength, StringBuilder pVersion, int cchBuffer, out uint dwlength);

For reference, other working machines will have these framework directories:

TargetFrameworkDirectories: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\, C:\Windows\Microsoft.NET\Framework\v3.5\, C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\, C:\Windows\Microsoft.NET\Framework\v3.0\, C:\Windows\Microsoft.NET\Framework\v2.0.50727\

While the problem machine has these framework directories:

TargetFrameworkDirectories: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\, C:\Windows\Microsoft.NET\Framework\v4.0.30319\, C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\, C:\Windows\Microsoft.NET\Framework\v4.0.30319\, C:\Windows\Microsoft.NET\Framework\v4.0.30319\

Also, I've uninstalled and re-installed .Net 2.0, 3.0, 3.5, 4.0, and Visual Studio 2010

1

1 Answers

1
votes

Mscoree.dll is not an oracle. Use SysInternals' ProcMon utility to find out where your machine's registry is toasted. Best to compare the trace against a machine that's okay to quickly narrow it down.