Lack of strong naming in Catel.Core NuGet package leads to compile error

Topics: Issues / bugs
Nov 13, 2014 at 11:29 AM
There is a lot of discussion about strong naming. You should always ask the question: why are you strong naming? If it's for security => stop doing it, it won't help. If you are doing it because it's good practice => stop doing it unless you have really, really good reasons.

We decided to stop strong naming a long time ago. We won't consider bringing it back. What you can do is create strong-name yourself as a pre-build step in visual studio.
Nov 13, 2014 at 1:26 PM

"Caution: Do not rely on strong names for security"

MS is also taking a different approach to SN moving forward.
Essentially allowing the consumer to handle SN the assembly if they want to

So I suggest you take a similar approach with Catel

If you need to SN you assembly for plugin purposes or to avoid name clashes you can

a) ILmerge catel into your assembly and then SN you assembly
b) Build a custom version of catel with your own SN key
c) SN catel with your own key as part of your deployment/packagaing process
d) run inside a custom appdomain
e) offer the maintainer of this project money to maintain a parallel SNed version of this package
Nov 13, 2014 at 3:26 PM
Edited Nov 13, 2014 at 3:26 PM
Thanks for the kind words. Keep in mind that positive or constructive feedback is always better, especially when people do all the work for free. As we have recommended earlier, you can strong name yourself by adding a pre-build step that signs the nuget packages just before you build the software.

Of course you can always give a helping hand. To be honest I was going to create a Catel.*.signed for all extensions just for people that really need signing (VSIX is a good point), but I just lost the appetite to actually create it (especially for free).

Anyway, good luck with the project, I really hope for you it works out.
Nov 13, 2014 at 11:12 PM
@mickyd to be fair, Geert has seen his fair share of people who actually do not know what they are doing and are signing because of 'best practice'.

Your scenario is a pretty narrow use case and is one that signing is not a stupid idea.

The issue is that strong naming breaks NuGet in other ways by introducing version lock. So then versioning work arounds need to be put in place to not change the assembly version between releases.
It is a trade off, both ways cause pain to someone.

To see a bit of the history we have all had with this issue, why don't you read, then lets continue the discussion.
Nov 14, 2014 at 7:57 AM
Edited Nov 14, 2014 at 7:57 AM
So the assembly redirect scenario which causes pain is if some decides they want to build on catel and release a catel.awesome project separately.

Your addin now references both catel and catel.awesome. If catel releases a new version and you update you need assembly redirects to load now because catel and catel.awesome are out of step.

This is version lock.

For frameworks which are not likely to be referenced by intermediate libraries this is not really a problem, but for things like which has many other open source projects built on top of it then this becomes a real pain.
It has resulted in doing not changing the assembly version ever when doing releases. Before that people were IL Merging it into their third party library to stop the pain. This meant if you got an outdated version of in a third party library it was IL Merged so you could not control security fixes etc.

The next issue as you say is the key management, if we sign as part of our build that puts additional burden on the single author to manage the key. Personally, I am not willing to do this and lots of others are not.
But to be honest, checking the key in is not an issue really as the goal is not security it is to solve identity issues with multiple version being allowed in a single app domain.

Another example of where strong naming can be painful is DbUp (a project I manage). I was thinking about splitting it into a Core library then releasing MsSql, MySql, PgSql etc as separate packages.
That won't really work due to strong naming without binding redirects. So if any database support gets an update I release everything and people upgrade without actually giving them anything.
Nov 14, 2014 at 9:11 AM
Edited Nov 14, 2014 at 9:12 AM
If you are too lazy to check a checkbox in Visual Studio then what does that imply for any potential bugs my organisation might want fixed in the future?
The cool thing is that we don't even work with checkboxes. We use the SolutionAssemblyInfo.cs for that. It allows you to uncomment a single line of code to sign everything. So if this is a real requirement, and you recognize that any signing will cause new issues, you can build Catel yourself with the line uncommented et voila, you got your goal.
Why don't we drop the holier-than-thou attitude.
I have dealt with people a lot and I believe being positive is better than being negative (I tried that too, didn't work out). You were really convincing me with actual arguments. Then you started being less positive than I hoped for and it simply killed any motivation to help one out for free.

Note that we are always, and I mean always, open for arguments as long as they have good arguments. I don't want people to do x because people tell them to do so but they don't know why. That's why I always open with the question: why would you like to sign. You response was valid but the way your responded to Simon is simply out of line. We all could have chosen not to respond at all, so keep that in mind next time you need something done by others for free.