Hi, I have some thoughts but no real answers, sorry. Jerry James <loganjerry@xxxxxxxxx> writes: > Antlr4 4.9.1 is out. This is mostly a small change from version 4.9, > except that the mono runtime has changed drastically. That's a little brave for a patch release.... Mono and .NET Core are two different implementations of .NET/C#. Dropping support for one implementation and adding support for another in a point release is going to lead to many surprises. There are major functional and other differences between the two. And it's even more so in an Linux distro context: dotnet is not part of many Linux distributions at this point (aside from Fedora/RHEL/CentOS plus others that ship binary packages without building them). So using `dotnet build` is just not an option for, say, Debian or Ubuntu. > Upstream now > builds against netstandard2.0 and netstandard2.1, and I can no longer > build with "xbuild Antlr4.mono.sln" because Antlr4.mono.sln is gone. > I figured out that the package needs to BR: dotnet, and build with > "dotnet build", and that we have to build against netstandard2.1 only. > That works fine Locally, maybe. Most likely, It won't work in koji: `dotnet build` downloads nuget packages at build time. I expect this to break when network is not available (which is the case in koji). (You could argue that this is something that the .NET upstream+downstream maintainers should fix and you wouldn't be entirely wrong. This really cripples building any C# project within Fedora using .NET Core.) > , but then we try to install with gacutil: > > Failure adding assembly > runtime/CSharp/bin/Debug/netstandard2.1/Antlr4.Runtime.Standard.dll to > the cache: Strong name cannot be verified for delay-signed assembly > > Upstream provides Antlr4.snk, which is the public key. They don't > hand out their private key for obvious reasons, so I cannot sign with > it. So I remove the signing bits from Antlr4.csproj and try again: > > Failure adding assembly > runtime/CSharp/bin/Debug/netstandard2.1/Antlr4.Runtime.Standard.dll to > the cache: Attempt to install an assembly without a strong name Here's the thing with modern .NET (including .NET Core 3.1 and the recently released .NET 5): there's no Global Assembly Cache (GAC). Even if you managed to install the `.dll` files into the cache, they wont be used. .NET Core really wants you to use nuget packages (`.nupkg` files) as the dependency mechanism. It's as if Java moved from managing dependencies via `.class` files (similar to `.dll` files) to `.jar` files (similar to `.nupkg` files). I suggest you think about packaging up the `.nupkg` files and shipping those in the RPM package (assuming you can get past the build-offline issues). As for strong name signing, some projects (such as .NET Core itself) have a "open" snk file that they use for "public-signing": https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/snk/Open.snk Here's an example of how it's being used: https://github.com/dotnet/arcade/blob/5bc6a0c39d9e8a89f4da5de53f1a2f9b3a6fe5db/src/Microsoft.DotNet.Arcade.Sdk/tools/StrongName.targets#L55-L67 > I don't understand Mono or .NET at all, really. Can somebody who does > tell me what I'm supposed to do? I think you need to talk to upstream and tell them that this breaks building Antlr4 for some prominent Linux distributions that don't allow access to the nuget repository via the network (which `dotnet` uses by default). This sounds like a big regression for a minor patch release. Longer term, by moving to .NET Core, you should think about moving to `nupkg` files instead of the GAC. Regards, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
