Netstandard not available in .net framework projects

[rouke-broersma]

Hi! Thank you for contributing this helper :)

I am trying to use your helper to solve some assembly resolving issues we have when using Mono.Cecil on Xamarin projects. Your resolver solved our problems, however we can now no longer resolve .NET framework projects due to netstandard not being in the list of referenced assemblies. I was wondering if you had some guidance as to how to overcome this problem.

For reference we are implementing your assembly resolver here: https://github.com/stryker-mutator/stryker-net/pull/1770 The .NET framework test project that is failing is here: https://github.com/stryker-mutator/stryker-net/tree/master/integrationtest/TargetProjects/NetFramework

The list of referenced assemblies as we get them from Buildalyzer (msbuild wrapper basically) is:

C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\Microsoft.CSharp.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\mscorlib.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Core.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Data.DataSetExtensions.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Data.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Net.Http.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Xml.dll
C:\\Program Files (x86)\\Reference Assemblies\\Microsoft\\Framework\\.NETFramework\\v4.6.1\\System.Xml.Linq.dll
C:\\git\\stryker\\stryker-net\\integrationtest\\TargetProjects\\NetFramework\\packages\\Newtonsoft.Json.13.0.1\\lib\\net45\\Newtonsoft.Json.dll

[atykhyy]

It may be possible to rework the helper to not rely on having a netstandard reference, but the use case I developed it for does not require it and I don't have time to experiment. Since you're targeting v4.6.1 which technically implements netstandard2.0, try referencing it from your project directly:

<PropertyGroup>
  <!-- see %ProgramFiles(x86)%\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\Microsoft.NET.Build.Extensions.NETFramework.targets -->
  <!-- this property is not necessary in projects targeting net472 and later -->
  <DependsOnNETStandard>true</DependsOnNETStandard>
</PropertyGroup>
<ItemGroup>
  <Reference Include="netstandard" />
</ItemGroup>

This pulls in a bunch of facade assemblies into the referenced assembly list which are then copied to the output directory, but the output assembly does not depend on them. It may be possible to avoid copying them with some additional MSBuild processing of reference lists (see targets file mentioned in the snippet above for the gory details). I'm not sure if this trick will work (a) with older versions of Visual Studio, or (b) with a packages.config-style project, as the build process may behave slightly differently. If it doesn't, upgrade your project to PackageReference-style - that should be painless.

[rouke-broersma]

Thank you for your reply! The problem is that we are a tool that is run on our external users projects so we don't have any control over their environment. In this case my test project is 4.6 but it could be anything. I see that you're saying this is not on problem anymore from net472. I think we might just decide to no longer support older target frameworks in that case. In any case thank you so much for open sourcing this, it will make it possible for us to support xamarin (and other 'funky') projects.

[atykhyy]

The problem is that we are a tool that is run on our external users projects so we don't have any control over their environment. In this case my test project is 4.6 but it could be anything.

If you were distributing your tool as a nuget package included in external users' projects, you could put these directives in build\<tfm>\Your.props files in your package. But if I understand correctly you're distributing it as a dotnet tool that is run as a MSBuild wrapper of some kind. In this case you could try injecting a .props file with suitable conditional property and item groups into the build you are wrapping using one of the build extensibility points, such as MSBuild property CustomBeforeMicrosoftCommonProps. Caveat: I haven't tried this.

I see that you're saying this is not on problem anymore from net472.

In net472, you no longer need to add that extra property to persuade Microsoft's targets to actually include netstandard in the referenced assembly list despite there being no "real" references to it, but you do have to add the <Reference> item for it if it's not already present in the transitive closure of the reference list.

[rouke-broersma]

I see. We are a mutation testing tool. We run as a dotnet (core) global tool where we scan the users project to gather all relevant project information because we need to modify the project source code and recompile. For the compilation we use Cecil to extract embedded resources from the unmutated assemblies so we don't have to figure out exactly how they gathered their embedded resources originally. In the case of xamarin Cecil in its default configuration for some reason cannot open assemblies using xamarin due to missing the xamarin core assembly. Since we already need all referenced assemblies to be able to compile we already know where to find the xamarin core assembly so with your assembly resolver we can pass the path directly to Cecil. But since your method relies on netstandard this now fails for netframework projects. Gain some, lose some 😂