Possibility to adopt strong naming?

[kMutagene]

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]

Hi Kevin I don't understand the problem, can you elaborate? It's not up to me, but if this involves tweaking the namespace I have no issue with it

…

On Tue, 28 Feb 2023, 15:06 Kevin Schneider, ***@***.***> wrote: Hi there, I know its legacy stuff and maybe much to ask, but is there the possibility of adopting a strong name <https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named> for this package? I maintain a graphing library, Plotly.NET <https://github.com/plotly/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 <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)? — Reply to this email directly, view it on GitHub <#23>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIGJF7NMZVO5SXL6GMKSKDWZWPWXANCNFSM6AAAAAAVKKUMCI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kMutagene]

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]

thanks for the explanation, so why is plotly strongly named?

…

On Wed, 1 Mar 2023 at 20:25, Kevin Schneider ***@***.***> wrote: here is the lengthy discussion we had in plotly.NET before adopting it: plotly/Plotly.NET#175 <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 useers now have when using Plotly.NET in .NET framework applications. 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 <https://github.com/plotly/Plotly.NET/blob/1e5fec1496e5b78dc4bb7cad7648a95cefdb975a/src/Plotly.NET/Plotly.NET.fsproj#L17-L18> and maybe setting assembly version on build/pack/publish calls. — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIGJF2WWSF22BYL4HA6SETWZ452ZANCNFSM6AAAAAAVKKUMCI> . You are receiving this because you commented.Message ID: ***@***.***>

-- Friendly Regards Bradley Phillips M: 0473 257 737

[kMutagene]

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]

strongly named seems to be causing issues here, why is ml.net strongly named?

…

On Wed, 1 Mar 2023 at 21:22, Kevin Schneider ***@***.***> wrote: so why is plotly strongly named? To make the story of plotly/Plotly.NET#175 <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). — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIGJF552FGOVJ6DTQPUW43WZ5EPTANCNFSM6AAAAAAVKKUMCI> . You are receiving this because you commented.Message ID: ***@***.***>

-- Friendly Regards Bradley Phillips M: 0473 257 737

[kMutagene]

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

[TheAngryByrd]

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]

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]

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]

What if another csproj file is added to this solution for a strong name? Target both?

…

On Wed, 15 Mar 2023, 17:25 Kevin Schneider, ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIGJF5OG4VJMR4OEELCW6LW4GDJRANCNFSM6AAAAAAVKKUMCI> . You are receiving this because you commented.Message ID: ***@***.***>

[kMutagene]

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]

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

…

On Thu, 16 Mar 2023, 12:06 Kevin Schneider, ***@***.***> wrote: 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 — Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIGJF47HL4SBGM6GQ7GLHDW4KGUXANCNFSM6AAAAAAVKKUMCI> . You are receiving this because you commented.Message ID: ***@***.***>

[kMutagene]

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]

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?