Language-ext: Strongly named version

Created on 30 Jun 2016  Â·  9Comments  Â·  Source: louthy/language-ext

Do you have a strongly named version of this? Or plan to?
Thanks.

help wanted

Most helpful comment

I tried using LanguageExt with StrongNamer, but there's one _major_ downside - StrongNamer forces the solution to be rebuilt from scratch every single time, effectively ditching "incremental building".

In a fairly large project, build times go from a couple of seconds to >1 minute. This makes the test-fail-code loop completely unbearable. Writing tests is no longer practical, and my team decided not to use this lib for this reason.

I beg you to reconsider signing this library.

IMHO, the biggest challenge in signing an OSS library is keeping the key out of the git repository, so that only the author has access to it. But, if I'm only signing the lib to make it work with other signed projects, I find there's no value in keeping the key out of the repository. I've done this successfully in other OSS projects.

So, in my experience, if you simply add a key to the project _and_ to the repository, it shouldn't have any impact on builds and deployments.

I'm sure there are plenty of people out there who would benefit from this.
Thanks.

All 9 comments

@vintem have you seen this? https://github.com/dsplaisted/strongnamer

I haven't. Gonna try it. Thanks

That solved it. Thanks.

Sorry, no I won't be using strong names. There are downsides, and that is
it's even more time out of my life dealing with builds and deployment.
Especially when you appear to have a solution which just involves upgrading
VS.

On Thu, 4 Aug 2016 at 14:59 Diogo Castro [email protected] wrote:

Could this issue be reconsidered? Using StrongNamer works, but it requires
Nuget 2.12 which, unfortunately, I can't use yet. It also requires VS2013,
and some of my coworkers are still using VS2012.

As far as I know, there is no downside to signing an assembly.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/louthy/language-ext/issues/100#issuecomment-237561126,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5kk-pZCU1JzerLK_tRUGlZp10xHV3Uks5qcfAsgaJpZM4JCUAf
.

I tried using LanguageExt with StrongNamer, but there's one _major_ downside - StrongNamer forces the solution to be rebuilt from scratch every single time, effectively ditching "incremental building".

In a fairly large project, build times go from a couple of seconds to >1 minute. This makes the test-fail-code loop completely unbearable. Writing tests is no longer practical, and my team decided not to use this lib for this reason.

I beg you to reconsider signing this library.

IMHO, the biggest challenge in signing an OSS library is keeping the key out of the git repository, so that only the author has access to it. But, if I'm only signing the lib to make it work with other signed projects, I find there's no value in keeping the key out of the repository. I've done this successfully in other OSS projects.

So, in my experience, if you simply add a key to the project _and_ to the repository, it shouldn't have any impact on builds and deployments.

I'm sure there are plenty of people out there who would benefit from this.
Thanks.

For me it's the same thing. I can use it, but everything is rebuild every time.

@vintem @jbarbosa Take a look at this batch file in the root of the project:

https://github.com/louthy/language-ext/blob/master/pack.bat

I run that batch file to build the nuget packages that I use to deploy lang-ext. If you can provide me with a pull-request that modifies that batch to build both strong and weak nuget packages, then I'm happy to take a look at it. I just don't personally have time to look into this right now.

Thank you for reopening this.

Is there a need for a weak version? Can the strong version not be used in all situations where a weak version is used?

@jbarbosa I'm semi-sure that it can have problems. I seem to remember reading about issues with stong-naming with relation to the StackExchange.Redis library (which is used in this project, they have a separate strong-named package: https://www.nuget.org/packages/StackExchange.Redis.StrongName/).

Ok, found the link: http://blog.marcgravell.com/2014/06/snk-we-need-to-talk.html

Was this page helpful?
0 / 5 - 0 ratings