MSBuild cannot find SGen when compiling a solution
Asked Answered
P

4

9

I've looked at several other SGen-related questions on here and either their answers don't apply or their answers don't fix this for me. I have installed several SDKs to fix this issue with no luck. Reference types should not be changed since this is the only place this is a problem. Once suggestion is to put SGen.exe into the C:\Windows\Microsoft.NET\Framework\v3.5 folder, but that's not been done on the box where this is not a problem. In this scenario, SGen.exe actually exists and is right where it's supposed to be, but MSBuild still is having issues with finding it for some reason!

Background:

We have a NAnt script that automates our builds. In this scenario, NAnt is calling MSBuild and MSBuild is generating the error claiming to be unable to find SGen. The project is .NET 3.5-based. I have my primary dev environment (64-bit Vista Ultimate) where the script works perfectly and I am attempting to duplicate it in a VM (64-bit Win 7 Ultimate). I THINK I have everything to the point where I should be good-to-go but this fails on the Win7 box (works perfectly on the Vista box).

I have done some comparisons between the two boxes and they both look identical in this regard, but it still fails. For example, the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework's sdkInstallRootv2.0 value is set to C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\ on both machines. In both machines, SGen.exe is in that path's bin subdirectory.

NAnt Script:

<target name="report-installer" depends="fail-if-environment-not-set">
    <exec program="MSBuild.exe" basedir="${framework35.directory}">
        <arg value="${tools.directory.current}\ReportInstaller\ReportInstaller.sln" />
        <arg value="/p:Configuration=${buildconfiguration.current}" />
    </exec>
</target>

The error message I get is this:

report-installer:

     [exec] Microsoft (R) Build Engine Version 3.5.30729.4926
     [exec] [Microsoft .NET Framework, Version 2.0.50727.4927]
     [exec] Copyright (C) Microsoft Corporation 2007. All rights reserved.
     [exec]
     [exec] Build started 4/8/2010 11:28:23 AM.
     [exec] Project "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.sln" on node 0 (default targets).
     [exec]   Building solution configuration "Release|Any CPU".
     [exec] Project "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.sln" (1) is building "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.csproj" (2) on node 0 (default targets).
     [exec]   Could not locate the .NET Framework SDK.  The task is looking for the path to the .NET Framework SDK at the location specified in the SDKInstallRootv2.0 value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework.  You may be able to solve the problem by doing one of the following:  1.) Install the .NET Framework SDK.  2.) Manually set the above registry key to the correct location.
     [exec] CoreCompile:
     [exec] Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
     [exec] C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1902,9): error MSB3091: Task failed because "sgen.exe" was not found, or the .NET Framework SDK v2.0 is not installed.  The task is looking for "sgen.exe" in the "bin" subdirectory beneath the location specified in the SDKInstallRootv2.0 value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework. You may be able to solve the problem by doing one of the following:  1.) Install the .NET Framework SDK v2.0.  2.) Manually set the above registry key to the correct location.  3.) Pass the correct location into the "ToolPath" parameter of the task.
     [exec] Done Building Project "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.csproj" (default targets) -- FAILED.
     [exec] Done Building Project "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.sln" (default targets) -- FAILED.
     [exec]
     [exec] Build FAILED.
     [exec]
     [exec] "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.sln" (default target) (1) ->
     [exec] "C:\Projects\Production\Tools\ReportInstaller\ReportInstaller.csproj" (default target) (2) ->
     [exec] (GenerateSerializationAssemblies target) ->
     [exec]   C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1902,9): error MSB3091: Task failed because "sgen.exe" was not found, or the .NET Framework SDK v2.0 is not installed.  The task is looking for "sgen.exe" in the "bin" subdirectory beneath the location specified in the SDKInstallRootv2.0 value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework.  You may be able to solve the problem by doing one of the following:  1.) Install the .NET Framework SDK v2.0.  2.) Manually set the above registry key to the correct location.  3.) Pass the correct location into the "ToolPath" parameter of the task.
     [exec]
     [exec]     0 Warning(s)
     [exec]     1 Error(s)
     [exec]
     [exec] Time Elapsed 00:00:00.24
     [call] C:\Projects\Production\Source\reports.build(15,4):
     [call] External Program Failed: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe (return code was 1)

What am I doing wrong here that is causing MSBuild to STILL be unable to find SGen?

Protoplast answered 8/4, 2010 at 17:4 Comment(2)
For clarification, I have installed the 3.5 and the 2.0 SDKs and neither of them changed the behavior for this.Protoplast
Did you already try to MSBuild your solution directly (without being called by NAnt)?Malherbe
M
18

This seems to be a common issue I just ran into these days myself.

In your project properties on the "Build" tab set the option "Generate serialization assembly" from "Auto" to "Off".


update

If you not already tried, make sure that <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies> is set for Release AND Debug configuration.

Malherbe answered 8/4, 2010 at 17:28 Comment(5)
I tried this and there was no change in behavior. This part of my build script is a single-project solution and I looked into that .csproj file and it contains <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies> from when I changed that setting, but I get the exact same error.Protoplast
To respond to your update: I had thought of that and that wasn't an issue.Protoplast
Thanks Filburt, that works for me, not sure what I'd do if I did need SerializationAssemblies. :-]Windsor
also: to help people googling, my initial error from the build server (Cruise Control .net) reads something like this: SGEN (,): error: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.Windsor
@Protoplast when you look in the .csproj file the <GenerateSerializationAssemblies>Off</GenerateSerializationAssemblies> should be in there TWICE, once for your debug build on your machine, and once for your release build on the build server, and setting it via the UI will only set it ONCE... (assuming you have a setup anything like mine :-)Windsor
B
0

I think there is a solution without the pain of installing old versions of VS

Please try the following:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0\

String Value: Name: InstallationFolder Value(default): C:\Program Files (x86)\Microsoft.NET\SDK\v2.0\

or save this code as .reg file and execute:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft.NET\\SDK\\v2.0
Bittencourt answered 26/1, 2016 at 10:27 Comment(0)
C
0

In your project properties on the "Build" tab set the option "Generate serialization assembly" from "Auto" to "Off".

Its resolved my issue.

Cistern answered 22/6, 2017 at 6:37 Comment(0)
P
-2

I'm not sure what or why this was happening but what I did to get around this was to install Visual Studio 2005. I had already installed the .NET 2.0 SDK as well as the .NET 3.5 SDK with no luck but something with the Visual Studio 2005 installer resolved this issue for me. This is a HORRIBLE solution, but it was, nonetheless, a solution.

Hopefully we can migrate to .NET 4.0 soon and be completed rid of .NET 2.0 and its issues.

Protoplast answered 8/4, 2010 at 19:0 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.