1

I have a solution that has the following (simplified) structure:

Application.sln
|- Business.csproj
|- DAL.vbproj

Both projets target .NET Framework 4.5.2. It builds both locally and in VSTS.

I have now added a NuGet package reference in the DAL project, to a .NET Standard 1.1 dll. It still build perfectly on my local machine, but no longer on VSTS. I get the following error:

SGEN : error : An attempt was made to load an assembly with an incorrect format: C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll. [E:\VstsAgents\2\_work\16\s\Src\Business\Business.csproj]

Notice how VSTS seems to complain about Business.csproj instead of DAL.vbproj. Though Business does reference DAL.

I have read about SGEN not being supported for .NET Standard 1.1, but if the option to generate the serialization assembly is set to Auto, it should work. All my projects have it set to Auto.

I have also read about how you should change the build definition, but

  • it's beyond my power to change the build definition
  • I have no error locally using the same configuration (Release, Any CPU)

Should I be looking into the .NET Core Xml Serializer Generator? Ideally, I would like to just have the build skip SGEN for my NuGet package.

Update

Setting the system.debug option to true gives us more info. We have an error message: cannot load a reference assembly for execution. We were also able to reproduce it locally. My machine had .NET 4.7.1 SDK and targeting package installed, but another local machine didn't. Installing that fixed it. We're now looking into installing it on the build machines (apparently, VSTS was set up to use on premise agents).

I believe these are the relevant log lines:

2018-02-14T10:03:33.4980817Z ##[error]SGEN(0,0): Error : An attempt was made to load an assembly with an incorrect format: C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll.
2018-02-14T10:03:33.4980817Z ##[debug]Processed: ##vso[task.logissue type=Error;sourcepath=SGEN;linenumber=0;columnnumber=0;code=;]An attempt was made to load an assembly with an incorrect format: C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll.
2018-02-14T10:03:33.4980817Z    108>SGEN : error : An attempt was made to load an assembly with an incorrect format: C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll. [E:\VstsAgents\2\_work\16\s\Src\Business\Business.csproj]
2018-02-14T10:03:33.4980817Z            - Could not load file or assembly 'file:///C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.runtime.interopservices.runtimeinformation\4.3.0\ref\netstandard1.1\System.Runtime.InteropServices.RuntimeInformation.dll' or one of its dependencies. Reference assemblies should not be loaded for execution.  They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058)
2018-02-14T10:03:33.4980817Z            - Cannot load a reference assembly for execution.

```

tear
  • 191
  • 9
Peter
  • 13,733
  • 11
  • 75
  • 122
  • What's the package you added to DAL project? Can you reproduce this issue with a new solution and projects? Can you share the detail log on the OneDrive (Set system.debug to true, then queue build and share the log)? – starian chen-MSFT Feb 13 '18 at 05:21
  • @starianchen-MSFT We added a custom package (netstandard11) to the DAL project. I added some info on the debug log in an update of the question. I'm not sure I'm allowed to share the entire log. – Peter Feb 14 '18 at 12:56
  • What's the result after installing .NET 4.7.1 on build agent machine? – starian chen-MSFT Feb 15 '18 at 01:33
  • We installed the SDK and targeting package via the Visual Studio Installer, but it didn't help. Which is strange, because it did help on one local machine. I'll see today if we can reproduce again on another machine or when uninstalling the SDK/package. So we can be more sure that that is the issue. – Peter Feb 15 '18 at 06:45
  • Try to build the project manually on build agent machine and check the result. – starian chen-MSFT Feb 15 '18 at 07:42
  • Same issue/error message unfortunately. We've now also tried updating Visual Studio on the build agent (15.5.6), no difference. – Peter Feb 15 '18 at 08:47
  • Try to uninstall VS then reinstall and check the result. – starian chen-MSFT Feb 15 '18 at 08:55
  • It seems .NET 4.7.1 wasn't installed correctly (or there was some miscommunication in the team). It seems installing 4.7.1 has solved the problem, but we're still investigating to be sure (as the build now fails on something else, but that could have other causes). – Peter Feb 15 '18 at 14:29

1 Answers1

0

Apparently, installing .NET 4.7.1 on the build agent fixed it for us.

Peter
  • 13,733
  • 11
  • 75
  • 122