Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Possibility to adopt strong naming? #23

Closed
kMutagene opened this issue Feb 28, 2023 · 18 comments
Closed

Possibility to adopt strong naming? #23

kMutagene opened this issue Feb 28, 2023 · 18 comments

Comments

@kMutagene
Copy link
Contributor

Hi there,

I know its legacy stuff and maybe much to ask, but is there the possibility of adopting a strong name for this package?

I maintain a graphing library, Plotly.NET, which is a strong named DLL. I forgot about that legacy stuff when updating my html generation backend to use this package, and now people on netfx face these problems: plotly/Plotly.NET#371

Another solution would be copying the two source files of Giraffe.ViewEngine into our project. That would have the advantage of not asking you to do anything, but the disadvantage of not attributing any package downloads. Would that be something you'd allow (IANAL but i think your license allows this, i think it would still be better to ask as well)?
@bradder555
Copy link
Collaborator

bradder555 commented Feb 28, 2023 via email

@kMutagene
Copy link
Contributor Author

kMutagene commented Mar 1, 2023 •
edited
Loading

here is the lengthy discussion we had in plotly.NET before adopting it: plotly/Plotly.NET#175

The gist of it is that it provides a stable identifier for your package in .NET framework environments. For .NET core / .NET 5 onwards it has no effect at all.

To cite from microsoft docs:

For .NET Framework, strong-named assemblies are useful in the following scenarios:

You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.

An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.

You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.

You want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

The "problem" now is that for the thing to work, the dependencies of a project must also be strongly named, hence the problem our users now have when using Plotly.NET in .NET framework applications since i have added Giraffe.ViewEngine as a dependency.

Since this repo has no external dependencies, it should make no difference for you.

I can also file a PR if you want to adopt strong naming. It would consist of generating a key that is used to sign the assembly on build and will also be checked into source control. Then a little tweak to the project file and maybe setting assembly version on build/pack/publish calls.

@bradder555
Copy link
Collaborator

bradder555 commented Mar 1, 2023 via email

@kMutagene
Copy link
Contributor Author

so why is plotly strongly named?

To make the story of plotly/Plotly.NET#175 short, we were asked because of the same reason as I ask here, someone wanted to use it in a environment that required it to have a strong name:

I'm Jake from the ML.NET team (one of .NET's Machine Learning libraries) - we're creating a bunch of sample notebooks and we'd love to use Plotly.NET in some of our Interactive Extensions. Unfortunately, we can't take dependency on Plotly.NET until it's signed.

We'd also like to use Plotly.NET in Model Builder (That is what LittleLittleCloud was asking about above).

@bradder555
Copy link
Collaborator

bradder555 commented Mar 1, 2023 via email

@kMutagene
Copy link
Contributor Author

For the reasons i laid out in my previous answer - its a thing used in .NET framework applications which they support

@TheAngryByrd
Copy link
Member

I've seen a lot of libraries go for Strong Naming then reverse course later. One of on the better write up about it are StephenCleary/AsyncEx#129 (comment).

Is it possible for the ML Team to sign their own assemblies with their key with something like: https://github.com/brutaldev/StrongNameSigner

@kMutagene
Copy link
Contributor Author

Is it possible for the ML Team to sign their own assemblies with their key with something like: https://github.com/brutaldev/StrongNameSigner

To quote from the back and forth we had in Plotly.NET then:

Ultimately, there is a policy in the https://github.com/dotnet org's repos and builds that enforces signing. We also want to use this inside of Visual Studio's Model Builder and that is .NET Framework ... which requires strong-named.

So basically we are stuck with this in plotly.NET now as well because I really want them to keep using the lib. I read the first thread you quoted then as well, which is why i was so hesitant in the original discussion in plotly/Plotly.NET#175 , but ultimately i deemed integration into their stack being worth it.

I understand however if you don't, hence why i suggested the other option with copying the source code

@kMutagene
Copy link
Contributor Author

Hi guys, have you decided on your stance on this? As said, I absolutely understand if you don't want to go for a strong name, but if that's the case please tell me so I can proceed implementing html generation directly.

@bradder555
Copy link
Collaborator

bradder555 commented Mar 16, 2023 via email

@kMutagene
Copy link
Contributor Author

That is another possibility, yes. Something like 'Giraffe.ViewEngine.StrongName' there are other projects that decided to do it this way https://www.nuget.org/packages?q=Strongname

@bradder555
Copy link
Collaborator

bradder555 commented Mar 16, 2023 via email

@kMutagene kMutagene mentioned this issue Mar 31, 2023
Closed
@kMutagene
Copy link
Contributor Author

I think this is a good approach, other thoughts other contributors??

I have created a PR (#24) for this. I don't know enough about your github actions to adapt them for also releasing this package, i would leave that up to someone with more knowledge about this repo.

@dustinmoris
Copy link
Member

I have to admit I know little about .NET strongly named assemblies. It sounds absolutely crazy and makes little sense to me that if someone wants to "strongly name" their assembly (whatever that means) that they have to ask all downstream dependencies to make changes to their libraries as well. Surely you should be able to package up your assembly however you want without this library having to change. If it already works now then why does it need to do this strong naming as well which sounds like adds more problems than it helps in order for a consuming library to also strongly name. Is there like no way to strongly name your library in any other way?

@kMutagene
Copy link
Contributor Author

kMutagene commented Mar 31, 2023 •
edited
Loading

Surely you should be able to package up your assembly however you want without this library having to change

yes this is true and also what I did initially. The problem arises if someone wants to consume it in an environment that cares about strong names (legacy/.NET framework stuff). The specific issue is this:

FileLoadException: Could not load file or assembly 'Giraffe.ViewEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required (plotly/Plotly.NET#371)

In an environment that does not care about strong names (anything .NET core / .NET 5+) it does not matter. Which is the reason why i only recognized this issue after adding a dependency to this library - i develop on a modern machine, using .NET SDK and therefore encountered no issues.

If it already works now then why does it need to do this strong naming as well which sounds like adds more problems than it helps in order for a consuming library to also strongly name

This is not true though. Consuming libraries that do not care about strong names can reference strongly named assemblies without being strongly named themselves. Large libraries like Newtonsoft.Json have strong names, and are being used by many dependents that are not signed.

Is there like no way to strongly name your library in any other way?

Consumers of non-signed libraries can apply the solution mentioned by @TheAngryByrd - they can sign the assemblies themselves before consuming it., but that's about it. Not very ergonomic, but one can argue that if you have to work in such an environment, you just have to endure the pain.

I could also sign a dll of this lib and redistribute it with my library, but that would be basically the same as copying your source code into my lib - and all I wanted to do in this issue is show a good faith approach of trying other solutions before just doing that, including a PR that leaves the original project an package intact as discussed above.

@kMutagene
Copy link
Contributor Author

I think I can read the writing on the wall. I'll fork this repo and redistribute it with a strong name. Thanks for the discussion.

@anpin
Copy link

anpin commented May 9, 2024

I think I can read the writing on the wall. I'll fork this repo and redistribute it with a strong name. Thanks for the discussion.

With the fork you have made it is now impossible to use Plotly.Net library in a Giraffe project

Components.fs(286,9): error FS0001: All elements of a list must be implicitly convertible to the type of the first element, which here is 'Giraffe.ViewEngine.HtmlElements.XmlAttribute (Giraffe.ViewEngine.StrongName, Version=2.0.0.0, Culture=neutral, PublicKeyToken=028aa8e2a326f4d0)'. This element has type 'Giraffe.ViewEngine.HtmlElements.XmlAttribute (Giraffe.ViewEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null)'. [Components.fsproj::TargetFramework=net8.0]

@anpin anpin mentioned this issue May 9, 2024
Open
@kMutagene
Copy link
Contributor Author

i don't know what i could do about that other than the maintainers of this repo reconsidering this issue.

@kMutagene kMutagene mentioned this issue Jul 18, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@TheAngryByrd @dustinmoris @anpin @bradder555 @kMutagene