fparsec icon indicating copy to clipboard operation
fparsec copied to clipboard

Different target frameworks have different assembly version (net45 = 1.0.0.0, netstandard2.0 = 1.1.1.0)

Open mk185147 opened this issue 4 years ago • 4 comments

I'm getting an issue with FParsec 1.1.1, the issue seems to come down to the FParsec package having assemblies with different version numbers for different target frameworks (net45 = 1.0.0.0, netstandard2.0 = 1.1.1.0).

Was it intentional that the net45 assembly has a different version number? It makes very hard to consume a netstandard2.0 library that uses FParsec, from a net472 assembly.

The issue is e.g. seen with Logary 5.0.1 which is netstandard 2.0 library and uses FParsec 1.1.1. We are not able to use that Logary in an .NET Framework project because Logary throws System.IO.FileLoadException on loading Logary.

Originally posted by @brian-reichle in https://github.com/stephan-tolksdorf/fparsec/issues/34#issuecomment-698681506

mk185147 avatar Oct 21 '20 16:10 mk185147

The net45 assembly uses the fixed version number 1.0.0.0 because it is strongly signed, while the netstandard2.0 is not. You'll find discussions on the signing in comments on older issues.

stephan-tolksdorf avatar Oct 21 '20 19:10 stephan-tolksdorf

I assume you are referring to https://github.com/stephan-tolksdorf/fparsec/issues/45#issuecomment-553570745

For signed assemblies not changing the assembly version for non-breaking updates has the advantage that the updated signed assembly can be used by signed downstream assemblies without requiring a binding redirect or rebuilding the referencing assembly.

That doesn't really prevent you from giving the unsigned assembly the same version as the signed assembly.

It's also not clear why you wouldn't sign the netstandard assembly when you do sign the net45 assembly.

brian-reichle avatar Oct 21 '20 22:10 brian-reichle

Trying to track this issue down caused us hours of pain recently 😞 This is breaking a real-world dependency scenario:

             +-----------+
             | MyProject |
             +-----------+
                net471
                   |
                   |
          v---------------------v
    +----------+      +-----------------+
    | PackageA |      | FParsec 1.0.0.0 |
    +----------+      +-----------------+
   netstandard2.0
         +
         v
+-----------------+
| FParsec 1.1.1.0 |
+-----------------+

In this situation, the built MyProject.dll artefact references FParsec v1.0.0.0. This causes runtime issues when trying to use PackageA:

System.IO.FileLoadException : Could not load file or assembly 'FParsec, Version=1.1.1.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)

Please can the assembly versions be made to match, or better yet just remove the .NET Framework target from the NuGet package entirely. It's not necessary as there is no .NET Framework-specific code in FParsec from what I can see.

saul avatar Nov 05 '20 16:11 saul

+1 for removing the net45 target. I'm also struggling with this.

atlemann avatar Nov 05 '21 06:11 atlemann