The assemblies built in this project are not strong-name signed. This makes them unconsumable on .NET Framework from assemblies that are themselves strong-name signed.
What is the benefit of signed assemblies? In my opinion, they don't give you more security. You can always build the source and sign it yourself. Even signing .dlls yourself is possible.
What is the benefit of signed assemblies? In my opinion, they don't give you more security. You can always build the source and sign it yourself. Even signing .dlls yourself is possible.
A good point. Although I personally do not see a major benefit in snk signing, the code base I am working on has snk signing all over and is unable to use avalonia. The argument could be that I remove the signing from the code base (which I am yet to look at).
So checking if Avalonia has plans for snk.
If not, do close this issue and I will check how else to work around it, maybe sign Avalonia myself or remove signing from code-base etc.
Its being worked on.
Is there something I can do in the meantime, such as sign the assemblies myself locally for now?
@danwalmsley @kekekeks Hi! Could you please update the status of this request? We have the situation when our platform are strongly-named and this cannot be changed. We really require this.
I know that there are some third-party packages which are not strongly-named, so is there any chance to see strongly-named Avalonia nearest future?
Currently blocked by https://github.com/tmds/Tmds.DBus/pull/82
@kekekeks tmds/Tmds.DBus 0.9.0 has been released with strong-name.
Most helpful comment
Its being worked on.