Hi @JakeRadMSFT , thanks for reaching out! Integration with ML.NET samples is definitely something that increases the priority of this issue quite a bit!

What i don't want to happen is implementing this while not understanding it and then have issues down the line due to it. I have read a bit into strong named assemblies and i am a little bit confused about the concept, so here are some questions/things i need to understand before implementing this.:

In general, newer MS tutorials and docs (e.g. here or here) seem to indicate that this is only concerned with giving the assembly a persistent identifier, and as a consequence recommends to check the key used for signing the assembly into source control. Is every assembly signed with this key, or do we have to use one key per assembly?
I am not sure if i have seen a F# project doing this (might be possible that i have seen it and just not realized what was going on though). Can you link me an example?
Hows the process like? Is it literally just adding <AssemblyOriginatorKeyFile>YouKey.snk</AssemblyOriginatorKeyFile and <SignAssembly>True</SignAssembly> to the project file and checking in the key? If this is so easy and has no disadvantages, why does it seem to be always such a discussion/long process until this is done for OSS libraries (see threads linked below, which have been active for years before the signing happened)?
This seems to impose the requirement of all dependencies being strongly named as well (use strong name #240). We have control of one of them, but there are several third party libraries used:
- Newtonsoft.Json, which seems to cause all kinds of problems with strong naming i have to admit i do not understand, but that might be outdated.
- Several Dotnet interactive libraries , but i suspect those are signed as i bet you have to use those for your notebooks anyways
- Puppeteersharp (although only a dependency of the Plotly.NET.ImageExport package) which does not seem to have a strong name.

Also, i have read in some threads that this basically breaks all dependent projects once, not sure if that's true. If so, this would require a major version increase i guess?

All together, the essence of threads such as this one or this one seems to be that this is legacy stuff but it cannot hurt to support it.

The thing is that i cannot control that for third party libraries. This seems like the exact thing that causes development workflow issues down the line. How should we handle third-party dependencies?

Strongly named assembly #175

Description

WhiteBlackGooseopenedon Sep 3, 2021

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

WhiteBlackGoose
openedon Sep 3, 2021