DidiSoft Ltd. company news, events and announcements.
09
Sep
Should DidiSoft OpenPGP Library for .NET provide strong name assemblies or unsigned assemblies?
Last week we have sent a short survey to subscribers for our OpenPGP Library for .NET mailing list. The survey had only one question:
Should DidiSoft OpenPGP Library for .NET provide strong name (signed) assemblies (DLL’s) or plain unsigned assemblies?
At the end of this post you will find the results of the survey, but first lets explain why did we made it.
DidiSoft OpenPGP Library for .NET was providing limited PGP emails support due to limitations in the System.Net.Mail namespace implementation regarding the MIME email formats (in fact we supported only PGP-inline emails). Recently we had received a numerous requests for additional support for PGP/MIME email format. In order to implement it we decided to use the open source MimeKit library but this is the moment where we were hit with this case:
+-------+ +---+ +--------+ | B +------->+ A +<--------+ D | +---+---+ +---+ +--------+ ^ ^ | | | | +---+---+ +---+---+ | C.1 | | C.2 | +-------+ +-------+
Assembly A needs to use assemblies B and D, which reference different versions of assembly C. Of course this can be resolved with binding redirect in the app.config or dynamically in the AppDomain.CurrentDomain.AssemblyResolve event. But our aim was to provide a DidiSoft.Pgp.Mail.dll which use will be as simple as just referencing it straight away.
Digging for more information in Stackoverflow and MSDN we found out that probably the days when strong named assemblies were a must may have passed away. In order to hear what our community thinks we decided to file the survey. And here are the results:
The results are self explanatory – we must provide both strong named DLLs and unsigned too.
We say “Thank you” to all customers and partners for the excellent cooperation and loyalty during the last year.
