MRCollective / ChameleonForms

Shape-shifting your forms experience in ASP.NET Core MVC
MIT License
254 stars 56 forks source link

Make ChameleonForms assembly to have strong name. #84

Closed zabulus closed 10 years ago

zabulus commented 10 years ago

I'me trying to use ChameleonForms in my web-project. Because of project requirements main assembly and all dependant have strong name and signed via sign file. Therefore, my project can't reference not signed assemblies, such as ChaemeleonForms and WebActivator.

robdmoore commented 10 years ago

Hi @zabulus,

Great to hear you are interested in using ChameleonForms :)

I'm not completely adverse to creating a separate NuGet package for ChameleonForms that is signed (something like ChameleonForms-Signed or similar - open to better naming suggestions). I'd want it to be a separate package so that I didn't have to put everyone else that didn't need strong naming through that pain. It looks like there is a strong named version of WebActivator so I could probably move to use that to solve that part of the problem. There is a downside to a second package, which is what other packages that want to depend on ChameleonForms should do, but I can cross that bridge when/if it happens.

Before I go ahead and do that though, I'd like to understand your situation:

I'm going to be upfront with you, I'm not a fan of strong naming at all - I think it's a blight and as responsible .NET developers we should do all we can to stop the use of it (hence why I don't want the main package to have it). I'm not the only one that shares this view point either - here is a GitHub issue thread as an example of some thorough discussion about it.

In saying all that, I'm a pragmatist and I do realise that some people are literally forced into using strong naming, and while I believe they should do all they can to fight against it, I know that sometimes they can't win. If someone in that sort of situation wanted to use a library I developed then I would be willing to help them out by creating a separate package as per above.

So coming back to your situation - are you being forced to use strong naming or do you have an option to not use it?

zabulus commented 10 years ago

I read the thread you specified, and see the point about not using strong-named assemblies in open source projects. I think there is a problem with publish organization of open-source libraries. In case .snk key is placed among code repository - everyone can publish and it is eliminates all strong-name libraries purpose. IMO there should be only maintainer(s) who can publish library and he is only who should have strong-name key. In my case I can disable strong-naming of my project assemblies. Here is counterquestion for you: are you sure there won't be anyone who MUST use strong-named assemblies with your library? OFFTOP: where can I ask questions is some specific feature has support in ChameleonForms?

robdmoore commented 10 years ago

IMO there should be only maintainer(s) who can publish library and he is only who should have strong-name key.

Pretty much all open source libraries that have strong naming make the .snk file public because they are only using strong naming to appease people rather than for security purposes. To be honest if strong naming assemblies is being used for security purposes then I think there is a wider issue - if someone can tamper with your dependent dlls then what's stopping them tampering with the core dlls and just removing strong naming? There are other ways of achieving this type of security that are much more secure.

Here is counterquestion for you: are you sure there won't be anyone who MUST use strong-named assemblies with your library?

No, but much like @shiftkey has expressed here I haven't yet found someone that actually needs it so until that happens I won't bother wasting my time / making things more complex for myself and others :)

OFFTOP: where can I ask questions is some specific feature has support in ChameleonForms?

Just raise an issue in this GitHub site or ask me on twitter: @robdmoore.

Thanks :)