In NuGet package, .NET Framework and .NET Standard versions of JIL should use the same assembly identity

[dsplaisted]

Currently, the layout of the Jil NuGet package is similar to this:

lib/
    net45/
        Jil.dll
    netstandard1.6
        Jil.Core.dll

IE, the assembly name is different depending on whether you are using the .NET Framework version or the .NET Standard version. This presents a problem when a .NET Framework project references a .NET Standard project which uses Jil. The .NET Standard project will be compiled against Jil.Core.dll, but in the .NET Framework project it will be Jil.dll that is deployed, and at runtime Jil.Core.dll won't be available.

When creating a NuGet package with different versions of a library for different targets, the library should use the same assembly name for each platform, and platforms with "broader" reach (ie .NET Standard) should be "API Compatible" with the more specific versions (ie .NET 4.5).

In order to make this work without breaking code which was compiled against previous versions of the package and Jil.Core.dll, I would suggest creating a version of Jil.Core.dll which has type forwards to Jil.dll for all the types that were previously in Jil.Core.dll. Then deploy that type-forward version of Jil.Core in both the lib/net45 and lib/netstandard1.6 folders of the package.

[andybn-zz]

We have the same problem ... Is there any solution?

[xemicalas]

Can this issue be more prioritized? We are facing it too..

[ShamsulAmry]

Ditto

[NickCraver]

We hit this in the Stack Overflow port to .NET Core as well. I took today and did all the work here - PR incoming shortly.

[NickCraver]

I've opened PR #304 to fix this mismatch up in the next release.

[NickCraver]

Jil 2.16.0 has been released and I've confirmed this all behaves as expected now.

For anyone that hit this: an upgrade to 2.16.0 should fix you up. There's also now a netstandard2.0 build with fewer dependencies to boot.

[andreycha]

I can confirm that 2.16.0 fixes the issue. Thanks a lot @NickCraver !

[NickCraver]

Closing this out to tidy up - it's all fixed up now :)

[Vaccano]

This fix causes a conflict when an application uses 2 NuGets that use this library when:

1. One of the NuGets depends on a pre-change version (2.15.4 for me)
2. Another that depends on a post change version (2.17 for me)

Basically, the pre-change dependency is looking for a jil.core assembly and cannot find it in the newer version. (See this stack overflow question for details: https://stackoverflow.com/questions/60609571/nuget-package-is-looking-for-exact-version).

I have not found a way around it at this time. (Aside from contacting the package maintainers and asking them to upgrade. But that is a timeline killer.)

[NickCraver]

@Vaccano The bad news is: tt was an issue either way. If another package was netstandard and one was net4x, it'd also have errored (that's how we hit it in the Stack Overflow port). It's unfortunate that you have 2 chains in the path here, but there was no other way out of the problem. It was a bad bug...that had to be fixed.

Which package are you hitting against on an old version? It's possible I could poke something there.

[Vaccano]

@NickCraver I appreciate the offer for help! However it is an internal team that built the package that is using the 2.15.4 version.

I am already leaning on them to update the dependency.