wcf: SGen doesn't work with reference assemblies (?)

From @KirillOsenkov on Tuesday, November 7, 2017 9:06:31 PM

Steps to reproduce

Create a new Windows Classic Console App in VS 15.3 or newer
Unload the project and add these package references to the .csproj:

  <ItemGroup>
    <PackageReference Include="MassTransit.RabbitMQ">
      <Version>3.5.6</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection">
      <Version>1.1.0</Version>
    </PackageReference>
  </ItemGroup>

Set this property:

    <GenerateSerializationAssemblies>On</GenerateSerializationAssemblies>

Reload the project and build.

Expected behavior

Should build.

Actual behavior

Severity	Code	Description	Project	File	Line	Suppression State
Error		An attempt was made to load an assembly with an incorrect format: C:\Users\kirillo\.nuget\packages\System.Net.Http\4.3.0\ref\net46\System.Net.Http.dll.	DanTupRepro	C:\Users\kirillo\Documents\Visual Studio 2017\Projects\DanTupRepro\SGEN

Environment data

msbuild /version output: 15.3.409.57025

Copied from original issue: microsoft/msbuild#2707

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 25 (1 by maintainers)

Most upvoted comments

The workaround posted from Jmales should work, and I would think the difference is running directly from the csproj will try to find all references and not handle package references correctly, but the sgen.exe tool takes the references needed as parameters so you can pass them in such that it will find them and run.

Since this is the old sgen tool that is part of .NET Framework which is in maintenance mode, I would suggest using a workaround similar to what Jmales suggested. If you don’t want to use the tool manually and want it as part of the build you can add a post-build step with an exec task that runs sgen.exe with the needed parameters, then you can get the desired behavior without the manual step.

dasetser on Mar 9, 2020

Isn’t this repository just dotnet client WCF?

Please note that this problem is happening on msbuild .net framework projects when those are having .netstandard2.0 references in Release build

toebens on Oct 29, 2019