Investigate how to support different target frameworks (e.g. .NET 4.x vs .NET 5 / 6)

[GeertvanHorrik]

Copied from initial discussion here: #763

By @0xced

The NetStandardAssemblyResolver was introduced in #701 in order to fix #697 (System.ArgumentNullException deep inside Cecil) and as a bonus adds support for .NET Framework 4.7 and lower.

Do we really want to revert both #696 (Use the assembly resolver from the module definition) and #701? This will drop .NET Framework 4.7 and lower and we are back at the undecipherable System.ArgumentNullException. 🙁

   at Mono.Cecil.Mixin.CheckType(Object type) in D:\Code\Fody\cecil\Mono.Cecil\ModuleDefinition.cs:line 1258
   at Mono.Cecil.ModuleDefinition.ImportReference(TypeReference type, IGenericParameterProvider context) in D:\Code\Fody\cecil\Mono.Cecil\ModuleDefinition.cs:line 859
   at Mono.Cecil.ModuleDefinition.ImportReference(TypeReference type) in D:\Code\Fody\cecil\Mono.Cecil\ModuleDefinition.cs:line 854
   at ModuleWeaver.Resolve(TypeReference baseType)
   at ModuleWeaver.ImportAssemblyLoader(Boolean createTemporaryAssemblies)
   at ModuleWeaver.Execute()
   at InnerWeaver.ExecuteWeavers() in C:\projects\fody\FodyIsolated\InnerWeaver.cs:line 185

=====================================

By @SimonCropp

embedding and loading the net48 version of netstandard is strange. the problem is cause since Costura.Template targets netstandard2 but costura support frameworks that do no support netstandard. ie version 471 and lower of .net has known incompatibilism with netstandard2.0 that MS has no intention of fixing

✔️ CONSIDER adding a target for net461 when you're offering a netstandard2.0 target.
Using .NET Standard 2.0 from .NET Framework has some issues that were addressed in .NET Framework 4.7.2. You can improve the experience for developers that are still on .NET Framework 4.6.1 - 4.7.1 by offering them a binary that is built for .NET Framework 4.6.1.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting

IMO the correct implementation would be to have multiple targets for Costura.Template, ie one that also targets the lowest version that costura supports

So the options here are

• drop support for frameworks that MS has stopped supporting. (yes i know MS is still officially supporting back to 4.5.2, but the number of workarounds required to make it work is IMO untenable for non paid projects)
• roll this back
• experiment multiple targets for Costura.Template

thoughts?

[GeertvanHorrik]

I am happy to work on the multi targeting. Does this mean we have to runtime detect the target fx of an assembly and then use different weaving? I do recall we built something like this in Catel (e.g. detect whether we are running full fx, .net core or netstandard).

[tom-englert]

I would get rid of the extra Costura.Template and move that code into the Costura assembly. Here we can have multiple targets at no cost, and the compiler will ensure the best matching version is already referenced.

I've used this technique e.g. here:
https://github.com/tom-englert/WeakEventHandler.Fody/blob/master/WeakEventHandler.Fody/WeakEventHandlerWeaver.cs#L49-L77

However this would requires to always reference something from the Costura.dll, but this could be solved.

[FreeVB]

Looking forward to support for. Net 5.0 and even. Net 6.0, the. Net 5.0 I tested today was not successful.

[GeertvanHorrik]

We use it successfully in .NET 5. The only downside is that you need to create your own appdomainloader to load the runtime assemblies. Here you can see the implementation we use for our plugin infrastructure:

https://github.com/WildGums/Orc.Extensibility/blob/develop/src/Orc.Extensibility/Watchers/AppDomainRuntimeAssemblyWatcher.cs

[FreeVB]

The screenshot is all the compiled files, and exe cannot be opened

.

[GeertvanHorrik]

@FreeVB Please create a separate ticket for this. This is about the technical discussion how we can / should support it.

[tom-englert]

@GeertvanHorrik what about my suggestion? Does it sound reasonable?
Can I assist with something?

[GeertvanHorrik]

Sorry for the late reply, my hands were tied with a big release. I will try to check this tomorrow.

[tom-englert]

No need to hurry 😄

[0xced]

I assume Costura 5.8.0-alpha0094 includes the changes introduced in #763. Is it correct? Should we revert #763 to avoid the regressions I described above before releasing a new stable version?

[GeertvanHorrik]

I think you are correct. I'll try to put it on my list for this week to look at.

[GeertvanHorrik]

Added back the net standard resolver. Releasing new version now.

@0xced / @tom-englert , please keep this ticket updated for the new release, then we have all information in 1 place.

[tom-englert]

@GeertvanHorrik 5.8.0-alpha0098 works

[GeertvanHorrik]

@0xced , can you verify it's working for you as well?

[0xced]

Sorry, I'm away from computer this week, so I won't be able to check before next Monday.

[GeertvanHorrik]

No problem, we will wait, we want to make sure it all keeps working.

[GeertvanHorrik]

@0xced I don't want to put any pressure on you, but do you have an ETA when you can test this behavior?

[tom-englert]

About the original issue: one option could be to inject the code as source via code generator instead off merging the IL. This way references would always be correct.

[SimonCropp]

side note. i helped build this as an alternative to Costura https://blog.sentry.io/2022/02/24/alias-an-approach-to-net-assembly-conflict-resolution/