FileLoadException when trying to load a .netstandard DLL into a .netframework WPF build

[KasperSK]

When I try and reference a .NetStandard dll that references Caliburn.Micro.Core from a WPF program that targets .NetFramework I get the following error:

FileLoadException: Could not load file or assembly 'Caliburn.Micro.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The exception has a Fusion log trace with it:

WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

I suspect that it is because the Caliburn.Micro.Core package for the .NetFramework is strong signed, since I can get this to work if i target .NetCore instead of .NetFramework.

I will upload a test repo later today that illustrates the error.

[nigel-sampson]

Thank you.

[willson556]

I think I'm running into a related issue. With VS 16.6.x, I'm unable to build a project under net472 that references a netstandard2.0 project utilizing Caliburn.Micro.Core.

I get the error:

AModel.cs(5,27): error CS0012: The type 'PropertyChangedBase' is defined in an assembly that is not referenced. You must add a reference to assembly 'Caliburn.Micro.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=null'. [C:\Users\willsont\projects\CaliburnMicroMultiTarget\WPFLib\WPFLib.csproj]

The netcoreapp3.1 target builds fine. I've put a minimal reproduction project up at https://github.com/willson556/caliburnmicro-multitargeting-issue. Thanks!

[nigel-sampson]

Thanks for the reproduction, I can see the same error on my machine and it's pretty perplexing.

[nigel-sampson]

Found that changing Core.csproj to the following lets it build.

<PropertyGroup>
  <TargetFrameworks>netcoreapp3.1;net472</TargetFrameworks>
</PropertyGroup>

[nigel-sampson]

My guess is because you end up with a conflict of which Caliburn.Micro.Core assembly to use, the one built for netstandard vs the one for net472.

[willson556]

My guess is because you end up with a conflict of which Caliburn.Micro.Core assembly to use, the one built for netstandard vs the one for net472.

Yeah, that looks like the issue: https://nugettoolsdev.azurewebsites.net/5.5.0-preview.2.6382/get-nearest-framework?project=net472&package=netstandard2.0%0D%0Anet45%0D%0Anetstandard1.1

Not really sure what the right answer is here -- if the netstandard1.1 assembly was strong-named it presumably wouldn't be an issue? Is there a reason it isn't?

EDIT: It looks like another library ran into similar issues and came to the conclusion that all their assemblies should be strong named (Microsoft at some point seemed to recommend against it but has since changed direction): https://github.com/accord-net/framework/issues/1338

[KasperSK]

Could Caliburn.Micro.Core possibly just target netstandard1.1? As i understand there is not any platform specific code in Caliburn.Micro.Core and so a netstandard project should be consumable from any platform (That supports the version of netstandard that Core targets)?

[KasperSK]

I have also made my repo that should reproduce the error: https://github.com/KasperSK/CaliburnTest, however i think it is similar to willson556's repo.

[nigel-sampson]

When I initially tried out the multi targeting my planned approach was just having Core target netstandard but was seeing a lot of build errors. That moving to multi targeting the whole way up fixed.

Wonder if its gotten any better since then.

[willson556]

It looks like the UAP target is still required for some reason (really doesn't seem like it should be). I ran into the same problem locally that 3708dbe did.

I submitted a PR for one working solution, still need to test in my project to make sure it resolves this issue. Will report back later today.

[nigel-sampson]

Yeah, I can't seem a find a solution to the above error, will be keen to see what you can find.

[willson556]

Just finished testing new packages generated from #704 and they definitely fix my problem. Not sure how much testing should be done on the other targets before considering this a good change.