Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

All Lucene.NET assemblies are signed, aka strongly named.

We are starting to run into problems with dependencies which not being
signed. What's becoming more common in the .NET world (OSS mainly) is to
stop signing assemblies because its
pretty<http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven>
much<http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly>
useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
last link: What Strong Names Can't Do).

Regardless of the argument about SN it seems to bring more fraction and
trouble than anything good, especially considering we are an open-source
library.

Case in question, I'm moving to updating the spatial module and want to
fetch dependencies from nuget. While spatial4n is signed (so it can be used
from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
time soon. Since signed assemblies cannot reference non-strongly-named
assemblies, I can't currently do that - not through nuget at least. This
introduces a lot of frustration and tons of fraction which I'd like to have
removed.

Ideally I'd want to move to removing strong-naming from all Lucene.NET
assemblies (v4 and forward), and having a wiki page that describes why
signing is pointless and how to manually sign it if you insist.

I can see 2 disadvantages for not signing, both of which I doubt really
matter nowadays and given our usage scenarios:

1. Deploy Lucene.NET to the GAC without further steps (non-signed
assemblies can be SN or ILMerged as part of the install process)

2. Signed assemblies / project won't be able to get Lucene.NET from nuget
directly because they'll have to sign it before referencing it. Or lose SN
themselves.

Thoughts?

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I went ahead and discussed this in length here:
http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net

I'm assuming most place which _require_ SN, and their process can't really
change easily, will also likely not being using nuget anyway (big
corporate, government agencies, etc). While this is not always the case,
I'm happy with assuming this and redirecting them to the download page.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Tue, Apr 29, 2014 at 3:40 PM, michael herndon <
mherndon@michaelherndon.com> wrote:

> Signed assemblies do hurt projects that use unsigned assemblies.  Binding
> redirects are painful.
>
> There seems to be a lot of discussion around this issue for other projects:
> * https://github.com/octokit/octokit.net/issues/405
> * https://twitter.com/search?q=%23nomorestrongnaming&src=hash
> * http://shouldiusestrongnaming.azurewebsites.net/
> * the aforementioned post from Jeremy Miller.
>
> There are pain points on both sides of the issue which is why there is a
> big discussion happening in the .NET community.
>
> The real solution might need the community to step up and change the
> package manager nuget in order to accommodate a single feed that allows for
> signed and unsigned assemblies and a way to filter on them.
>
> -M
>
>
> On Tue, Apr 29, 2014 at 5:30 AM, Alexey Shcherbachev <
> alexey@renaissance-it.ru> wrote:
>
> > Hi,
> >
> > I would strongly opt to keep assemblies signed by default too. Due to
> > platform constrains our solution is forced to install assemblies into the
> > GAC, which means that everything has to be signed.
> >
> > I would note, that number of projects that depends on Lucene.Net being
> > signed is considerably higher than number of assemblies referenced by
> > Lucene itself. So it is easier to keep them signed rather than force
> > everybody who needs a signed version to do that themselves or use
> > alternative distribution. And since keeping Lucene.Net signed won't hurt
> > projects that use unsigned assemblies, but it will hurt everybody who
> uses
> > signed version, it sounds more reasonable to keep everything as is.
> >
> > Regards,
> > Alexey Shcherbachev
> > US: 408.600.2737
> > Russia (mobile): +7 (905) 47-97-677
> > Russia (office): +7 (863) 266-50-67
> > Skype: Leha-2304
> > LinkedIn: http://linkedin.com/in/shcherbachev
> >
> >
> > On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle <
> > magnus.strale@episerver.com
> > > wrote:
> >
> > > Hi,
> > >
> > > I've been following this mailing list for a long time with the intent
> of
> > > eventually become more actively involved. Professionally I use
> Lucene.NET
> > > and we are relying on the NuGet distribution both internally and for
> our
> > > customers / partners that are building on our platform.
> > >
> > > Removing strong naming / signing of the assemblies shipped in the NuGet
> > > feed will be a *big* pain for us.
> > >
> > > 1. We have signed assemblies that have dependencies on lucene.net.
> > > 2. We have a large number of installations that are set up with NuGet
> > > dependencies to Lucene
> > > 3. We push updates on a fairly regular basis (weekly).
> > > 4. Some of our partners implement various solutions based on Lucene.Net
> > >
> > > The combination of 1 & 4 used to be a big problem, but now (mostly)
> just
> > > works thanks to NuGet.
> > >
> > > As I see our only practical option would be to create our own
> Lucene.net
> > > NuGet package and get all our customers/partners to take  dependency on
> > > that version.
> > >
> > > Please, please - keep the main distribution signed. If you really have
> to
> > > go to an unsigned distribution, at least wait until the 4.x release and
> > > continue to provide signed 3.x releases.
> > >
> > > ...and yes - this is the time for me to step up. What would be the best
> > > area for me to start help out with Lucene.Net? Automation of the NuGet
> > > release process with signed assemblies?
> > >
> > > Magnus Stråle
> > > EPiServer AB
> > >
> > > -----Original Message-----
> > > From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com]
> > On
> > > Behalf Of Itamar Syn-Hershko
> > > Sent: den 28 april 2014 19:07
> > > To: dev@lucenenet.apache.org
> > > Cc: user@lucenenet.apache.org
> > > Subject: Re: Removing signing of assemblies (starting in v4)
> > >
> > > Yes, and this is why we are going to provide signed versions as
> downloads
> > > + scripts to sign the sources, just not in the main distribution stream
> > > which is nuget.
> > >
> > > We will take a canary testing kind of approach where we will do a
> > > pre-release of v4 and a bugfix release of v3 both usigned and see how
> > much
> > > people will complain.
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant Author of RavenDB in Action <
> > > http://manning.com/synhershko/>
> > >
> > >
> > > On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org>
> wrote:
> > >
> > > > +1 to Oren's point here
> > > >
> > > > Remember the signing dependency issue works both ways, there are lots
> > > > of other projects that depend on Lucene.Net which do sign their
> > > > dependencies and so changing whether the project is signed breaks
> > > > upstream consumers of the library
> > > >
> > > > An unsigned assembly can happily depend on a signed assembly whereas
> > > > the opposite is not true
> > > >
> > > > Regardless of how effective/valuable SN signing is we are
> > > > unfortunately stuck with it in the .Net world and you will only get
> > > grief.
> > > >
> > > > My own project got rid of signing for a while and had to bring it
> back
> > > > because we got too many user complaints about this.  For comparison
> my
> > > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > > would strongly suspect you will get far more user complaints far more
> > > > quickly if you drop signing in future releases.
> > > >
> > > > Rob
> > > >
> > > >
> > > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > > > wrote:
> > > >
> > > > >I'm many corporate environment that is a big requirement In a
> library
> > > > >like Lucene, where other people depend on it, a sign build is
> > > > >important On Apr 23, 2014 2:27 PM, "Petar Repac"
> > > > ><pe...@gmail.com> wrote:
> > > > >
> > > > >> There is a long discussion about SN here:
> > > > >> https://nuget.codeplex.com/discussions/247827
> > > > >>
> > > > >> I'd suggest that even if decision is not to sign, there should be
> > > > >>an easy  way to get signed assemblies.
> > > > >>
> > > > >> Like:
> > > > >> 1. clone repo (signing keys are publicly accessible in repository)
> > > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p
> > > > >> files from /build folder
> > > > >>
> > > > >> I stopped signing my assemblies long ago, but probably there still
> > > > >>are many  that still do  and less obstacles in adopting Lucene.NET
> > > > >>the better.
> > > > >>
> > > > >> Regards,
> > > > >> Petar Repac
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko
> > > > >> <itamar@code972.com
> > > > >> >wrote:
> > > > >>
> > > > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > > > >> >
> > > > >> > We are starting to run into problems with dependencies which not
> > > > >> > being signed. What's becoming more common in the .NET world (OSS
> > > > >> > mainly) is
> > > > >>to
> > > > >> > stop signing assemblies because its pretty<
> > > > >> >
> > > > >>
> > > > >>
> > > >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-
> > > > eve
> > > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > > >> > >
> > > > >> > much<
> > > > >> >
> > > > >>
> > > > >>
> > > >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> > > > nin
> > > > >>g-a-net-assembly
> > > > >> > >
> > > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx
> >
> > > > >> > (in
> > > > >>the
> > > > >> > last link: What Strong Names Can't Do).
> > > > >> >
> > > > >> > Regardless of the argument about SN it seems to bring more
> > > > >> > fraction
> > > > >>and
> > > > >> > trouble than anything good, especially considering we are an
> > > > >>open-source
> > > > >> > library.
> > > > >> >
> > > > >> > Case in question, I'm moving to updating the spatial module and
> > > > >> > want
> > > > >>to
> > > > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> > > > >> > can be
> > > > >> used
> > > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> > > > >> > signed
> > > > >>any
> > > > >> > time soon. Since signed assemblies cannot reference
> > > > >> > non-strongly-named assemblies, I can't currently do that - not
> > > through nuget at least.
> > > > >>This
> > > > >> > introduces a lot of frustration and tons of fraction which I'd
> > > > >> > like to
> > > > >> have
> > > > >> > removed.
> > > > >> >
> > > > >> > Ideally I'd want to move to removing strong-naming from all
> > > > >> > Lucene.NET assemblies (v4 and forward), and having a wiki page
> > > > >> > that describes why signing is pointless and how to manually sign
> > it
> > > if you insist.
> > > > >> >
> > > > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > > > >>really
> > > > >> > matter nowadays and given our usage scenarios:
> > > > >> >
> > > > >> > 1. Deploy Lucene.NET to the GAC without further steps
> (non-signed
> > > > >> > assemblies can be SN or ILMerged as part of the install process)
> > > > >> >
> > > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> > > > >> > from
> > > > >>nuget
> > > > >> > directly because they'll have to sign it before referencing it.
> > > > >> > Or
> > > > >>lose
> > > > >> SN
> > > > >> > themselves.
> > > > >> >
> > > > >> > Thoughts?
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Itamar Syn-Hershko
> > > > >> > http://code972.com | @synhershko <
> https://twitter.com/synhershko>
> > > > >> > Freelance Developer & Consultant Author of RavenDB in Action
> > > > >> > <http://manning.com/synhershko/>
> > > > >> >
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I went ahead and discussed this in length here:
http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net

I'm assuming most place which _require_ SN, and their process can't really
change easily, will also likely not being using nuget anyway (big
corporate, government agencies, etc). While this is not always the case,
I'm happy with assuming this and redirecting them to the download page.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Tue, Apr 29, 2014 at 3:40 PM, michael herndon <
mherndon@michaelherndon.com> wrote:

> Signed assemblies do hurt projects that use unsigned assemblies.  Binding
> redirects are painful.
>
> There seems to be a lot of discussion around this issue for other projects:
> * https://github.com/octokit/octokit.net/issues/405
> * https://twitter.com/search?q=%23nomorestrongnaming&src=hash
> * http://shouldiusestrongnaming.azurewebsites.net/
> * the aforementioned post from Jeremy Miller.
>
> There are pain points on both sides of the issue which is why there is a
> big discussion happening in the .NET community.
>
> The real solution might need the community to step up and change the
> package manager nuget in order to accommodate a single feed that allows for
> signed and unsigned assemblies and a way to filter on them.
>
> -M
>
>
> On Tue, Apr 29, 2014 at 5:30 AM, Alexey Shcherbachev <
> alexey@renaissance-it.ru> wrote:
>
> > Hi,
> >
> > I would strongly opt to keep assemblies signed by default too. Due to
> > platform constrains our solution is forced to install assemblies into the
> > GAC, which means that everything has to be signed.
> >
> > I would note, that number of projects that depends on Lucene.Net being
> > signed is considerably higher than number of assemblies referenced by
> > Lucene itself. So it is easier to keep them signed rather than force
> > everybody who needs a signed version to do that themselves or use
> > alternative distribution. And since keeping Lucene.Net signed won't hurt
> > projects that use unsigned assemblies, but it will hurt everybody who
> uses
> > signed version, it sounds more reasonable to keep everything as is.
> >
> > Regards,
> > Alexey Shcherbachev
> > US: 408.600.2737
> > Russia (mobile): +7 (905) 47-97-677
> > Russia (office): +7 (863) 266-50-67
> > Skype: Leha-2304
> > LinkedIn: http://linkedin.com/in/shcherbachev
> >
> >
> > On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle <
> > magnus.strale@episerver.com
> > > wrote:
> >
> > > Hi,
> > >
> > > I've been following this mailing list for a long time with the intent
> of
> > > eventually become more actively involved. Professionally I use
> Lucene.NET
> > > and we are relying on the NuGet distribution both internally and for
> our
> > > customers / partners that are building on our platform.
> > >
> > > Removing strong naming / signing of the assemblies shipped in the NuGet
> > > feed will be a *big* pain for us.
> > >
> > > 1. We have signed assemblies that have dependencies on lucene.net.
> > > 2. We have a large number of installations that are set up with NuGet
> > > dependencies to Lucene
> > > 3. We push updates on a fairly regular basis (weekly).
> > > 4. Some of our partners implement various solutions based on Lucene.Net
> > >
> > > The combination of 1 & 4 used to be a big problem, but now (mostly)
> just
> > > works thanks to NuGet.
> > >
> > > As I see our only practical option would be to create our own
> Lucene.net
> > > NuGet package and get all our customers/partners to take  dependency on
> > > that version.
> > >
> > > Please, please - keep the main distribution signed. If you really have
> to
> > > go to an unsigned distribution, at least wait until the 4.x release and
> > > continue to provide signed 3.x releases.
> > >
> > > ...and yes - this is the time for me to step up. What would be the best
> > > area for me to start help out with Lucene.Net? Automation of the NuGet
> > > release process with signed assemblies?
> > >
> > > Magnus Stråle
> > > EPiServer AB
> > >
> > > -----Original Message-----
> > > From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com]
> > On
> > > Behalf Of Itamar Syn-Hershko
> > > Sent: den 28 april 2014 19:07
> > > To: dev@lucenenet.apache.org
> > > Cc: user@lucenenet.apache.org
> > > Subject: Re: Removing signing of assemblies (starting in v4)
> > >
> > > Yes, and this is why we are going to provide signed versions as
> downloads
> > > + scripts to sign the sources, just not in the main distribution stream
> > > which is nuget.
> > >
> > > We will take a canary testing kind of approach where we will do a
> > > pre-release of v4 and a bugfix release of v3 both usigned and see how
> > much
> > > people will complain.
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant Author of RavenDB in Action <
> > > http://manning.com/synhershko/>
> > >
> > >
> > > On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org>
> wrote:
> > >
> > > > +1 to Oren's point here
> > > >
> > > > Remember the signing dependency issue works both ways, there are lots
> > > > of other projects that depend on Lucene.Net which do sign their
> > > > dependencies and so changing whether the project is signed breaks
> > > > upstream consumers of the library
> > > >
> > > > An unsigned assembly can happily depend on a signed assembly whereas
> > > > the opposite is not true
> > > >
> > > > Regardless of how effective/valuable SN signing is we are
> > > > unfortunately stuck with it in the .Net world and you will only get
> > > grief.
> > > >
> > > > My own project got rid of signing for a while and had to bring it
> back
> > > > because we got too many user complaints about this.  For comparison
> my
> > > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > > would strongly suspect you will get far more user complaints far more
> > > > quickly if you drop signing in future releases.
> > > >
> > > > Rob
> > > >
> > > >
> > > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > > > wrote:
> > > >
> > > > >I'm many corporate environment that is a big requirement In a
> library
> > > > >like Lucene, where other people depend on it, a sign build is
> > > > >important On Apr 23, 2014 2:27 PM, "Petar Repac"
> > > > ><pe...@gmail.com> wrote:
> > > > >
> > > > >> There is a long discussion about SN here:
> > > > >> https://nuget.codeplex.com/discussions/247827
> > > > >>
> > > > >> I'd suggest that even if decision is not to sign, there should be
> > > > >>an easy  way to get signed assemblies.
> > > > >>
> > > > >> Like:
> > > > >> 1. clone repo (signing keys are publicly accessible in repository)
> > > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p
> > > > >> files from /build folder
> > > > >>
> > > > >> I stopped signing my assemblies long ago, but probably there still
> > > > >>are many  that still do  and less obstacles in adopting Lucene.NET
> > > > >>the better.
> > > > >>
> > > > >> Regards,
> > > > >> Petar Repac
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko
> > > > >> <itamar@code972.com
> > > > >> >wrote:
> > > > >>
> > > > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > > > >> >
> > > > >> > We are starting to run into problems with dependencies which not
> > > > >> > being signed. What's becoming more common in the .NET world (OSS
> > > > >> > mainly) is
> > > > >>to
> > > > >> > stop signing assemblies because its pretty<
> > > > >> >
> > > > >>
> > > > >>
> > > >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-
> > > > eve
> > > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > > >> > >
> > > > >> > much<
> > > > >> >
> > > > >>
> > > > >>
> > > >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> > > > nin
> > > > >>g-a-net-assembly
> > > > >> > >
> > > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx
> >
> > > > >> > (in
> > > > >>the
> > > > >> > last link: What Strong Names Can't Do).
> > > > >> >
> > > > >> > Regardless of the argument about SN it seems to bring more
> > > > >> > fraction
> > > > >>and
> > > > >> > trouble than anything good, especially considering we are an
> > > > >>open-source
> > > > >> > library.
> > > > >> >
> > > > >> > Case in question, I'm moving to updating the spatial module and
> > > > >> > want
> > > > >>to
> > > > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> > > > >> > can be
> > > > >> used
> > > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> > > > >> > signed
> > > > >>any
> > > > >> > time soon. Since signed assemblies cannot reference
> > > > >> > non-strongly-named assemblies, I can't currently do that - not
> > > through nuget at least.
> > > > >>This
> > > > >> > introduces a lot of frustration and tons of fraction which I'd
> > > > >> > like to
> > > > >> have
> > > > >> > removed.
> > > > >> >
> > > > >> > Ideally I'd want to move to removing strong-naming from all
> > > > >> > Lucene.NET assemblies (v4 and forward), and having a wiki page
> > > > >> > that describes why signing is pointless and how to manually sign
> > it
> > > if you insist.
> > > > >> >
> > > > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > > > >>really
> > > > >> > matter nowadays and given our usage scenarios:
> > > > >> >
> > > > >> > 1. Deploy Lucene.NET to the GAC without further steps
> (non-signed
> > > > >> > assemblies can be SN or ILMerged as part of the install process)
> > > > >> >
> > > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> > > > >> > from
> > > > >>nuget
> > > > >> > directly because they'll have to sign it before referencing it.
> > > > >> > Or
> > > > >>lose
> > > > >> SN
> > > > >> > themselves.
> > > > >> >
> > > > >> > Thoughts?
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Itamar Syn-Hershko
> > > > >> > http://code972.com | @synhershko <
> https://twitter.com/synhershko>
> > > > >> > Freelance Developer & Consultant Author of RavenDB in Action
> > > > >> > <http://manning.com/synhershko/>
> > > > >> >
> > > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[michael herndon <mh...@michaelherndon.com>]

Signed assemblies do hurt projects that use unsigned assemblies.  Binding
redirects are painful.

There seems to be a lot of discussion around this issue for other projects:
* https://github.com/octokit/octokit.net/issues/405
* https://twitter.com/search?q=%23nomorestrongnaming&src=hash
* http://shouldiusestrongnaming.azurewebsites.net/
* the aforementioned post from Jeremy Miller.

There are pain points on both sides of the issue which is why there is a
big discussion happening in the .NET community.

The real solution might need the community to step up and change the
package manager nuget in order to accommodate a single feed that allows for
signed and unsigned assemblies and a way to filter on them.

-M


On Tue, Apr 29, 2014 at 5:30 AM, Alexey Shcherbachev <
alexey@renaissance-it.ru> wrote:

> Hi,
>
> I would strongly opt to keep assemblies signed by default too. Due to
> platform constrains our solution is forced to install assemblies into the
> GAC, which means that everything has to be signed.
>
> I would note, that number of projects that depends on Lucene.Net being
> signed is considerably higher than number of assemblies referenced by
> Lucene itself. So it is easier to keep them signed rather than force
> everybody who needs a signed version to do that themselves or use
> alternative distribution. And since keeping Lucene.Net signed won't hurt
> projects that use unsigned assemblies, but it will hurt everybody who uses
> signed version, it sounds more reasonable to keep everything as is.
>
> Regards,
> Alexey Shcherbachev
> US: 408.600.2737
> Russia (mobile): +7 (905) 47-97-677
> Russia (office): +7 (863) 266-50-67
> Skype: Leha-2304
> LinkedIn: http://linkedin.com/in/shcherbachev
>
>
> On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle <
> magnus.strale@episerver.com
> > wrote:
>
> > Hi,
> >
> > I've been following this mailing list for a long time with the intent of
> > eventually become more actively involved. Professionally I use Lucene.NET
> > and we are relying on the NuGet distribution both internally and for our
> > customers / partners that are building on our platform.
> >
> > Removing strong naming / signing of the assemblies shipped in the NuGet
> > feed will be a *big* pain for us.
> >
> > 1. We have signed assemblies that have dependencies on lucene.net.
> > 2. We have a large number of installations that are set up with NuGet
> > dependencies to Lucene
> > 3. We push updates on a fairly regular basis (weekly).
> > 4. Some of our partners implement various solutions based on Lucene.Net
> >
> > The combination of 1 & 4 used to be a big problem, but now (mostly) just
> > works thanks to NuGet.
> >
> > As I see our only practical option would be to create our own Lucene.net
> > NuGet package and get all our customers/partners to take  dependency on
> > that version.
> >
> > Please, please - keep the main distribution signed. If you really have to
> > go to an unsigned distribution, at least wait until the 4.x release and
> > continue to provide signed 3.x releases.
> >
> > ...and yes - this is the time for me to step up. What would be the best
> > area for me to start help out with Lucene.Net? Automation of the NuGet
> > release process with signed assemblies?
> >
> > Magnus Stråle
> > EPiServer AB
> >
> > -----Original Message-----
> > From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com]
> On
> > Behalf Of Itamar Syn-Hershko
> > Sent: den 28 april 2014 19:07
> > To: dev@lucenenet.apache.org
> > Cc: user@lucenenet.apache.org
> > Subject: Re: Removing signing of assemblies (starting in v4)
> >
> > Yes, and this is why we are going to provide signed versions as downloads
> > + scripts to sign the sources, just not in the main distribution stream
> > which is nuget.
> >
> > We will take a canary testing kind of approach where we will do a
> > pre-release of v4 and a bugfix release of v3 both usigned and see how
> much
> > people will complain.
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant Author of RavenDB in Action <
> > http://manning.com/synhershko/>
> >
> >
> > On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
> >
> > > +1 to Oren's point here
> > >
> > > Remember the signing dependency issue works both ways, there are lots
> > > of other projects that depend on Lucene.Net which do sign their
> > > dependencies and so changing whether the project is signed breaks
> > > upstream consumers of the library
> > >
> > > An unsigned assembly can happily depend on a signed assembly whereas
> > > the opposite is not true
> > >
> > > Regardless of how effective/valuable SN signing is we are
> > > unfortunately stuck with it in the .Net world and you will only get
> > grief.
> > >
> > > My own project got rid of signing for a while and had to bring it back
> > > because we got too many user complaints about this.  For comparison my
> > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > would strongly suspect you will get far more user complaints far more
> > > quickly if you drop signing in future releases.
> > >
> > > Rob
> > >
> > >
> > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > > wrote:
> > >
> > > >I'm many corporate environment that is a big requirement In a library
> > > >like Lucene, where other people depend on it, a sign build is
> > > >important On Apr 23, 2014 2:27 PM, "Petar Repac"
> > > ><pe...@gmail.com> wrote:
> > > >
> > > >> There is a long discussion about SN here:
> > > >> https://nuget.codeplex.com/discussions/247827
> > > >>
> > > >> I'd suggest that even if decision is not to sign, there should be
> > > >>an easy  way to get signed assemblies.
> > > >>
> > > >> Like:
> > > >> 1. clone repo (signing keys are publicly accessible in repository)
> > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p
> > > >> files from /build folder
> > > >>
> > > >> I stopped signing my assemblies long ago, but probably there still
> > > >>are many  that still do  and less obstacles in adopting Lucene.NET
> > > >>the better.
> > > >>
> > > >> Regards,
> > > >> Petar Repac
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko
> > > >> <itamar@code972.com
> > > >> >wrote:
> > > >>
> > > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > > >> >
> > > >> > We are starting to run into problems with dependencies which not
> > > >> > being signed. What's becoming more common in the .NET world (OSS
> > > >> > mainly) is
> > > >>to
> > > >> > stop signing assemblies because its pretty<
> > > >> >
> > > >>
> > > >>
> > > http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-
> > > eve
> > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > >> > >
> > > >> > much<
> > > >> >
> > > >>
> > > >>
> > > http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> > > nin
> > > >>g-a-net-assembly
> > > >> > >
> > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> > > >> > (in
> > > >>the
> > > >> > last link: What Strong Names Can't Do).
> > > >> >
> > > >> > Regardless of the argument about SN it seems to bring more
> > > >> > fraction
> > > >>and
> > > >> > trouble than anything good, especially considering we are an
> > > >>open-source
> > > >> > library.
> > > >> >
> > > >> > Case in question, I'm moving to updating the spatial module and
> > > >> > want
> > > >>to
> > > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> > > >> > can be
> > > >> used
> > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> > > >> > signed
> > > >>any
> > > >> > time soon. Since signed assemblies cannot reference
> > > >> > non-strongly-named assemblies, I can't currently do that - not
> > through nuget at least.
> > > >>This
> > > >> > introduces a lot of frustration and tons of fraction which I'd
> > > >> > like to
> > > >> have
> > > >> > removed.
> > > >> >
> > > >> > Ideally I'd want to move to removing strong-naming from all
> > > >> > Lucene.NET assemblies (v4 and forward), and having a wiki page
> > > >> > that describes why signing is pointless and how to manually sign
> it
> > if you insist.
> > > >> >
> > > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > > >>really
> > > >> > matter nowadays and given our usage scenarios:
> > > >> >
> > > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > >> > assemblies can be SN or ILMerged as part of the install process)
> > > >> >
> > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> > > >> > from
> > > >>nuget
> > > >> > directly because they'll have to sign it before referencing it.
> > > >> > Or
> > > >>lose
> > > >> SN
> > > >> > themselves.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Itamar Syn-Hershko
> > > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > >> > Freelance Developer & Consultant Author of RavenDB in Action
> > > >> > <http://manning.com/synhershko/>
> > > >> >
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Alexey Shcherbachev <al...@renaissance-it.ru>]

Hi,

I would strongly opt to keep assemblies signed by default too. Due to
platform constrains our solution is forced to install assemblies into the
GAC, which means that everything has to be signed.

I would note, that number of projects that depends on Lucene.Net being
signed is considerably higher than number of assemblies referenced by
Lucene itself. So it is easier to keep them signed rather than force
everybody who needs a signed version to do that themselves or use
alternative distribution. And since keeping Lucene.Net signed won't hurt
projects that use unsigned assemblies, but it will hurt everybody who uses
signed version, it sounds more reasonable to keep everything as is.

Regards,
Alexey Shcherbachev
US: 408.600.2737
Russia (mobile): +7 (905) 47-97-677
Russia (office): +7 (863) 266-50-67
Skype: Leha-2304
LinkedIn: http://linkedin.com/in/shcherbachev


On Tue, Apr 29, 2014 at 11:39 AM, Magnus Stråle <magnus.strale@episerver.com
> wrote:

> Hi,
>
> I've been following this mailing list for a long time with the intent of
> eventually become more actively involved. Professionally I use Lucene.NET
> and we are relying on the NuGet distribution both internally and for our
> customers / partners that are building on our platform.
>
> Removing strong naming / signing of the assemblies shipped in the NuGet
> feed will be a *big* pain for us.
>
> 1. We have signed assemblies that have dependencies on lucene.net.
> 2. We have a large number of installations that are set up with NuGet
> dependencies to Lucene
> 3. We push updates on a fairly regular basis (weekly).
> 4. Some of our partners implement various solutions based on Lucene.Net
>
> The combination of 1 & 4 used to be a big problem, but now (mostly) just
> works thanks to NuGet.
>
> As I see our only practical option would be to create our own Lucene.net
> NuGet package and get all our customers/partners to take  dependency on
> that version.
>
> Please, please - keep the main distribution signed. If you really have to
> go to an unsigned distribution, at least wait until the 4.x release and
> continue to provide signed 3.x releases.
>
> ...and yes - this is the time for me to step up. What would be the best
> area for me to start help out with Lucene.Net? Automation of the NuGet
> release process with signed assemblies?
>
> Magnus Stråle
> EPiServer AB
>
> -----Original Message-----
> From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On
> Behalf Of Itamar Syn-Hershko
> Sent: den 28 april 2014 19:07
> To: dev@lucenenet.apache.org
> Cc: user@lucenenet.apache.org
> Subject: Re: Removing signing of assemblies (starting in v4)
>
> Yes, and this is why we are going to provide signed versions as downloads
> + scripts to sign the sources, just not in the main distribution stream
> which is nuget.
>
> We will take a canary testing kind of approach where we will do a
> pre-release of v4 and a bugfix release of v3 both usigned and see how much
> people will complain.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant Author of RavenDB in Action <
> http://manning.com/synhershko/>
>
>
> On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> > +1 to Oren's point here
> >
> > Remember the signing dependency issue works both ways, there are lots
> > of other projects that depend on Lucene.Net which do sign their
> > dependencies and so changing whether the project is signed breaks
> > upstream consumers of the library
> >
> > An unsigned assembly can happily depend on a signed assembly whereas
> > the opposite is not true
> >
> > Regardless of how effective/valuable SN signing is we are
> > unfortunately stuck with it in the .Net world and you will only get
> grief.
> >
> > My own project got rid of signing for a while and had to bring it back
> > because we got too many user complaints about this.  For comparison my
> > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > would strongly suspect you will get far more user complaints far more
> > quickly if you drop signing in future releases.
> >
> > Rob
> >
> >
> > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > wrote:
> >
> > >I'm many corporate environment that is a big requirement In a library
> > >like Lucene, where other people depend on it, a sign build is
> > >important On Apr 23, 2014 2:27 PM, "Petar Repac"
> > ><pe...@gmail.com> wrote:
> > >
> > >> There is a long discussion about SN here:
> > >> https://nuget.codeplex.com/discussions/247827
> > >>
> > >> I'd suggest that even if decision is not to sign, there should be
> > >>an easy  way to get signed assemblies.
> > >>
> > >> Like:
> > >> 1. clone repo (signing keys are publicly accessible in repository)
> > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p
> > >> files from /build folder
> > >>
> > >> I stopped signing my assemblies long ago, but probably there still
> > >>are many  that still do  and less obstacles in adopting Lucene.NET
> > >>the better.
> > >>
> > >> Regards,
> > >> Petar Repac
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko
> > >> <itamar@code972.com
> > >> >wrote:
> > >>
> > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > >> >
> > >> > We are starting to run into problems with dependencies which not
> > >> > being signed. What's becoming more common in the .NET world (OSS
> > >> > mainly) is
> > >>to
> > >> > stop signing assemblies because its pretty<
> > >> >
> > >>
> > >>
> > http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-
> > eve
> > >>r-fully-verified-when-loaded-to-check-they-haven
> > >> > >
> > >> > much<
> > >> >
> > >>
> > >>
> > http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> > nin
> > >>g-a-net-assembly
> > >> > >
> > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> > >> > (in
> > >>the
> > >> > last link: What Strong Names Can't Do).
> > >> >
> > >> > Regardless of the argument about SN it seems to bring more
> > >> > fraction
> > >>and
> > >> > trouble than anything good, especially considering we are an
> > >>open-source
> > >> > library.
> > >> >
> > >> > Case in question, I'm moving to updating the spatial module and
> > >> > want
> > >>to
> > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> > >> > can be
> > >> used
> > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> > >> > signed
> > >>any
> > >> > time soon. Since signed assemblies cannot reference
> > >> > non-strongly-named assemblies, I can't currently do that - not
> through nuget at least.
> > >>This
> > >> > introduces a lot of frustration and tons of fraction which I'd
> > >> > like to
> > >> have
> > >> > removed.
> > >> >
> > >> > Ideally I'd want to move to removing strong-naming from all
> > >> > Lucene.NET assemblies (v4 and forward), and having a wiki page
> > >> > that describes why signing is pointless and how to manually sign it
> if you insist.
> > >> >
> > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > >>really
> > >> > matter nowadays and given our usage scenarios:
> > >> >
> > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > >> > assemblies can be SN or ILMerged as part of the install process)
> > >> >
> > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> > >> > from
> > >>nuget
> > >> > directly because they'll have to sign it before referencing it.
> > >> > Or
> > >>lose
> > >> SN
> > >> > themselves.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > --
> > >> >
> > >> > Itamar Syn-Hershko
> > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > >> > Freelance Developer & Consultant Author of RavenDB in Action
> > >> > <http://manning.com/synhershko/>
> > >> >
> > >>
> >
> >
> >
> >
> >
>

RE: Removing signing of assemblies (starting in v4)

[Magnus Stråle <ma...@episerver.com>]

Hi,

I've been following this mailing list for a long time with the intent of eventually become more actively involved. Professionally I use Lucene.NET and we are relying on the NuGet distribution both internally and for our customers / partners that are building on our platform.

Removing strong naming / signing of the assemblies shipped in the NuGet feed will be a *big* pain for us.

1. We have signed assemblies that have dependencies on lucene.net.
2. We have a large number of installations that are set up with NuGet dependencies to Lucene
3. We push updates on a fairly regular basis (weekly).
4. Some of our partners implement various solutions based on Lucene.Net

The combination of 1 & 4 used to be a big problem, but now (mostly) just works thanks to NuGet.

As I see our only practical option would be to create our own Lucene.net NuGet package and get all our customers/partners to take  dependency on that version. 

Please, please - keep the main distribution signed. If you really have to go to an unsigned distribution, at least wait until the 4.x release and continue to provide signed 3.x releases.

...and yes - this is the time for me to step up. What would be the best area for me to start help out with Lucene.Net? Automation of the NuGet release process with signed assemblies?

Magnus Stråle
EPiServer AB

-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar Syn-Hershko
Sent: den 28 april 2014 19:07
To: dev@lucenenet.apache.org
Cc: user@lucenenet.apache.org
Subject: Re: Removing signing of assemblies (starting in v4)

Yes, and this is why we are going to provide signed versions as downloads + scripts to sign the sources, just not in the main distribution stream which is nuget.

We will take a canary testing kind of approach where we will do a pre-release of v4 and a bugfix release of v3 both usigned and see how much people will complain.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Author of RavenDB in Action <http://manning.com/synhershko/>


On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> +1 to Oren's point here
>
> Remember the signing dependency issue works both ways, there are lots 
> of other projects that depend on Lucene.Net which do sign their 
> dependencies and so changing whether the project is signed breaks 
> upstream consumers of the library
>
> An unsigned assembly can happily depend on a signed assembly whereas 
> the opposite is not true
>
> Regardless of how effective/valuable SN signing is we are 
> unfortunately stuck with it in the .Net world and you will only get grief.
>
> My own project got rid of signing for a while and had to bring it back 
> because we got too many user complaints about this.  For comparison my 
> project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I 
> would strongly suspect you will get far more user complaints far more 
> quickly if you drop signing in future releases.
>
> Rob
>
>
> On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> wrote:
>
> >I'm many corporate environment that is a big requirement In a library 
> >like Lucene, where other people depend on it, a sign build is 
> >important On Apr 23, 2014 2:27 PM, "Petar Repac" 
> ><pe...@gmail.com> wrote:
> >
> >> There is a long discussion about SN here:
> >> https://nuget.codeplex.com/discussions/247827
> >>
> >> I'd suggest that even if decision is not to sign, there should be 
> >>an easy  way to get signed assemblies.
> >>
> >> Like:
> >> 1. clone repo (signing keys are publicly accessible in repository) 
> >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....) 3. c/p 
> >> files from /build folder
> >>
> >> I stopped signing my assemblies long ago, but probably there still 
> >>are many  that still do  and less obstacles in adopting Lucene.NET 
> >>the better.
> >>
> >> Regards,
> >> Petar Repac
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko 
> >> <itamar@code972.com
> >> >wrote:
> >>
> >> > All Lucene.NET assemblies are signed, aka strongly named.
> >> >
> >> > We are starting to run into problems with dependencies which not 
> >> > being signed. What's becoming more common in the .NET world (OSS 
> >> > mainly) is
> >>to
> >> > stop signing assemblies because its pretty<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-
> eve
> >>r-fully-verified-when-loaded-to-check-they-haven
> >> > >
> >> > much<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-sig
> nin
> >>g-a-net-assembly
> >> > >
> >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> 
> >> > (in
> >>the
> >> > last link: What Strong Names Can't Do).
> >> >
> >> > Regardless of the argument about SN it seems to bring more 
> >> > fraction
> >>and
> >> > trouble than anything good, especially considering we are an
> >>open-source
> >> > library.
> >> >
> >> > Case in question, I'm moving to updating the spatial module and 
> >> > want
> >>to
> >> > fetch dependencies from nuget. While spatial4n is signed (so it 
> >> > can be
> >> used
> >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get 
> >> > signed
> >>any
> >> > time soon. Since signed assemblies cannot reference 
> >> > non-strongly-named assemblies, I can't currently do that - not through nuget at least.
> >>This
> >> > introduces a lot of frustration and tons of fraction which I'd 
> >> > like to
> >> have
> >> > removed.
> >> >
> >> > Ideally I'd want to move to removing strong-naming from all 
> >> > Lucene.NET assemblies (v4 and forward), and having a wiki page 
> >> > that describes why signing is pointless and how to manually sign it if you insist.
> >> >
> >> > I can see 2 disadvantages for not signing, both of which I doubt
> >>really
> >> > matter nowadays and given our usage scenarios:
> >> >
> >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed 
> >> > assemblies can be SN or ILMerged as part of the install process)
> >> >
> >> > 2. Signed assemblies / project won't be able to get Lucene.NET 
> >> > from
> >>nuget
> >> > directly because they'll have to sign it before referencing it. 
> >> > Or
> >>lose
> >> SN
> >> > themselves.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > Itamar Syn-Hershko
> >> > http://code972.com | @synhershko <https://twitter.com/synhershko> 
> >> > Freelance Developer & Consultant Author of RavenDB in Action 
> >> > <http://manning.com/synhershko/>
> >> >
> >>
>
>
>
>
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

Yes, and this is why we are going to provide signed versions as downloads +
scripts to sign the sources, just not in the main distribution stream which
is nuget.

We will take a canary testing kind of approach where we will do a
pre-release of v4 and a bugfix release of v3 both usigned and see how much
people will complain.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> +1 to Oren's point here
>
> Remember the signing dependency issue works both ways, there are lots of
> other projects that depend on Lucene.Net which do sign their dependencies
> and so changing whether the project is signed breaks upstream consumers of
> the library
>
> An unsigned assembly can happily depend on a signed assembly whereas the
> opposite is not true
>
> Regardless of how effective/valuable SN signing is we are unfortunately
> stuck with it in the .Net world and you will only get grief.
>
> My own project got rid of signing for a while and had to bring it back
> because we got too many user complaints about this.  For comparison my
> project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> would strongly suspect you will get far more user complaints far more
> quickly if you drop signing in future releases.
>
> Rob
>
>
> On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> wrote:
>
> >I'm many corporate environment that is a big requirement
> >In a library like Lucene, where other people depend on it, a sign build is
> >important
> >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> >
> >> There is a long discussion about SN here:
> >> https://nuget.codeplex.com/discussions/247827
> >>
> >> I'd suggest that even if decision is not to sign, there should be an
> >>easy
> >> way to get signed assemblies.
> >>
> >> Like:
> >> 1. clone repo (signing keys are publicly accessible in repository)
> >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> >> 3. c/p files from /build folder
> >>
> >> I stopped signing my assemblies long ago, but probably there still are
> >>many
> >> that still do
> >> and less obstacles in adopting Lucene.NET the better.
> >>
> >> Regards,
> >> Petar Repac
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >> >wrote:
> >>
> >> > All Lucene.NET assemblies are signed, aka strongly named.
> >> >
> >> > We are starting to run into problems with dependencies which not being
> >> > signed. What's becoming more common in the .NET world (OSS mainly) is
> >>to
> >> > stop signing assemblies because its
> >> > pretty<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> >>r-fully-verified-when-loaded-to-check-they-haven
> >> > >
> >> > much<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> >>g-a-net-assembly
> >> > >
> >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> >>the
> >> > last link: What Strong Names Can't Do).
> >> >
> >> > Regardless of the argument about SN it seems to bring more fraction
> >>and
> >> > trouble than anything good, especially considering we are an
> >>open-source
> >> > library.
> >> >
> >> > Case in question, I'm moving to updating the spatial module and want
> >>to
> >> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> >> used
> >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> >>any
> >> > time soon. Since signed assemblies cannot reference non-strongly-named
> >> > assemblies, I can't currently do that - not through nuget at least.
> >>This
> >> > introduces a lot of frustration and tons of fraction which I'd like to
> >> have
> >> > removed.
> >> >
> >> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> >> > assemblies (v4 and forward), and having a wiki page that describes why
> >> > signing is pointless and how to manually sign it if you insist.
> >> >
> >> > I can see 2 disadvantages for not signing, both of which I doubt
> >>really
> >> > matter nowadays and given our usage scenarios:
> >> >
> >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> >> > assemblies can be SN or ILMerged as part of the install process)
> >> >
> >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> >>nuget
> >> > directly because they'll have to sign it before referencing it. Or
> >>lose
> >> SN
> >> > themselves.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > Itamar Syn-Hershko
> >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> >> > Freelance Developer & Consultant
> >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >> >
> >>
>
>
>
>
>

Re: Removing signing of assemblies (starting in v4)

[Troy Howard <th...@gmail.com>]

FWIW, I totally support Itamar's plan of delivering unsigned libs as the
main distribution and offering signed as an optional download. Best of both
worlds.

Re: scripts to do the signing.. Worth noting that people can't sign as us
without our key file. They can of course, sign with their own key file, but
that wouldn't be a drop in replacement for our signed libs. It would
essentially represent a private fork, which is of course, totally fine, but
would mean a dependency signature update, which may have conflict w/ other
libs they use that also depend on our lib.

Thanks,
Troy


On Mon, Apr 28, 2014 at 10:16 AM, Itamar Syn-Hershko <it...@code972.com>wrote:

> And compile every component we use in (spatial4n, NTS, etc) and kill every
> opportunity for people to enhance Lucene.NET on their own? no thanks
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Mon, Apr 28, 2014 at 7:15 PM, Petar Repac <pe...@gmail.com>
> wrote:
>
> >
> >
> http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/
> >
> > ILMerge ?
> >
> >
> > On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
> >
> > > +1 to Oren's point here
> > >
> > > Remember the signing dependency issue works both ways, there are lots
> of
> > > other projects that depend on Lucene.Net which do sign their
> dependencies
> > > and so changing whether the project is signed breaks upstream consumers
> > of
> > > the library
> > >
> > > An unsigned assembly can happily depend on a signed assembly whereas
> the
> > > opposite is not true
> > >
> > > Regardless of how effective/valuable SN signing is we are unfortunately
> > > stuck with it in the .Net world and you will only get grief.
> > >
> > > My own project got rid of signing for a while and had to bring it back
> > > because we got too many user complaints about this.  For comparison my
> > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > would strongly suspect you will get far more user complaints far more
> > > quickly if you drop signing in future releases.
> > >
> > > Rob
> > >
> > >
> > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > > wrote:
> > >
> > > >I'm many corporate environment that is a big requirement
> > > >In a library like Lucene, where other people depend on it, a sign
> build
> > is
> > > >important
> > > >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> > > >
> > > >> There is a long discussion about SN here:
> > > >> https://nuget.codeplex.com/discussions/247827
> > > >>
> > > >> I'd suggest that even if decision is not to sign, there should be an
> > > >>easy
> > > >> way to get signed assemblies.
> > > >>
> > > >> Like:
> > > >> 1. clone repo (signing keys are publicly accessible in repository)
> > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > > >> 3. c/p files from /build folder
> > > >>
> > > >> I stopped signing my assemblies long ago, but probably there still
> are
> > > >>many
> > > >> that still do
> > > >> and less obstacles in adopting Lucene.NET the better.
> > > >>
> > > >> Regards,
> > > >> Petar Repac
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > >> >wrote:
> > > >>
> > > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > > >> >
> > > >> > We are starting to run into problems with dependencies which not
> > being
> > > >> > signed. What's becoming more common in the .NET world (OSS mainly)
> > is
> > > >>to
> > > >> > stop signing assemblies because its
> > > >> > pretty<
> > > >> >
> > > >>
> > > >>
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > >> > >
> > > >> > much<
> > > >> >
> > > >>
> > > >>
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> > > >>g-a-net-assembly
> > > >> > >
> > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> > (in
> > > >>the
> > > >> > last link: What Strong Names Can't Do).
> > > >> >
> > > >> > Regardless of the argument about SN it seems to bring more
> fraction
> > > >>and
> > > >> > trouble than anything good, especially considering we are an
> > > >>open-source
> > > >> > library.
> > > >> >
> > > >> > Case in question, I'm moving to updating the spatial module and
> want
> > > >>to
> > > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> can
> > be
> > > >> used
> > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> signed
> > > >>any
> > > >> > time soon. Since signed assemblies cannot reference
> > non-strongly-named
> > > >> > assemblies, I can't currently do that - not through nuget at
> least.
> > > >>This
> > > >> > introduces a lot of frustration and tons of fraction which I'd
> like
> > to
> > > >> have
> > > >> > removed.
> > > >> >
> > > >> > Ideally I'd want to move to removing strong-naming from all
> > Lucene.NET
> > > >> > assemblies (v4 and forward), and having a wiki page that describes
> > why
> > > >> > signing is pointless and how to manually sign it if you insist.
> > > >> >
> > > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > > >>really
> > > >> > matter nowadays and given our usage scenarios:
> > > >> >
> > > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > >> > assemblies can be SN or ILMerged as part of the install process)
> > > >> >
> > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> from
> > > >>nuget
> > > >> > directly because they'll have to sign it before referencing it. Or
> > > >>lose
> > > >> SN
> > > >> > themselves.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Itamar Syn-Hershko
> > > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > >> > Freelance Developer & Consultant
> > > >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > >> >
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Troy Howard <th...@gmail.com>]

FWIW, I totally support Itamar's plan of delivering unsigned libs as the
main distribution and offering signed as an optional download. Best of both
worlds.

Re: scripts to do the signing.. Worth noting that people can't sign as us
without our key file. They can of course, sign with their own key file, but
that wouldn't be a drop in replacement for our signed libs. It would
essentially represent a private fork, which is of course, totally fine, but
would mean a dependency signature update, which may have conflict w/ other
libs they use that also depend on our lib.

Thanks,
Troy


On Mon, Apr 28, 2014 at 10:16 AM, Itamar Syn-Hershko <it...@code972.com>wrote:

> And compile every component we use in (spatial4n, NTS, etc) and kill every
> opportunity for people to enhance Lucene.NET on their own? no thanks
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Mon, Apr 28, 2014 at 7:15 PM, Petar Repac <pe...@gmail.com>
> wrote:
>
> >
> >
> http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/
> >
> > ILMerge ?
> >
> >
> > On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
> >
> > > +1 to Oren's point here
> > >
> > > Remember the signing dependency issue works both ways, there are lots
> of
> > > other projects that depend on Lucene.Net which do sign their
> dependencies
> > > and so changing whether the project is signed breaks upstream consumers
> > of
> > > the library
> > >
> > > An unsigned assembly can happily depend on a signed assembly whereas
> the
> > > opposite is not true
> > >
> > > Regardless of how effective/valuable SN signing is we are unfortunately
> > > stuck with it in the .Net world and you will only get grief.
> > >
> > > My own project got rid of signing for a while and had to bring it back
> > > because we got too many user complaints about this.  For comparison my
> > > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > > would strongly suspect you will get far more user complaints far more
> > > quickly if you drop signing in future releases.
> > >
> > > Rob
> > >
> > >
> > > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > > wrote:
> > >
> > > >I'm many corporate environment that is a big requirement
> > > >In a library like Lucene, where other people depend on it, a sign
> build
> > is
> > > >important
> > > >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> > > >
> > > >> There is a long discussion about SN here:
> > > >> https://nuget.codeplex.com/discussions/247827
> > > >>
> > > >> I'd suggest that even if decision is not to sign, there should be an
> > > >>easy
> > > >> way to get signed assemblies.
> > > >>
> > > >> Like:
> > > >> 1. clone repo (signing keys are publicly accessible in repository)
> > > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > > >> 3. c/p files from /build folder
> > > >>
> > > >> I stopped signing my assemblies long ago, but probably there still
> are
> > > >>many
> > > >> that still do
> > > >> and less obstacles in adopting Lucene.NET the better.
> > > >>
> > > >> Regards,
> > > >> Petar Repac
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > >> >wrote:
> > > >>
> > > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > > >> >
> > > >> > We are starting to run into problems with dependencies which not
> > being
> > > >> > signed. What's becoming more common in the .NET world (OSS mainly)
> > is
> > > >>to
> > > >> > stop signing assemblies because its
> > > >> > pretty<
> > > >> >
> > > >>
> > > >>
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> > > >>r-fully-verified-when-loaded-to-check-they-haven
> > > >> > >
> > > >> > much<
> > > >> >
> > > >>
> > > >>
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> > > >>g-a-net-assembly
> > > >> > >
> > > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> > (in
> > > >>the
> > > >> > last link: What Strong Names Can't Do).
> > > >> >
> > > >> > Regardless of the argument about SN it seems to bring more
> fraction
> > > >>and
> > > >> > trouble than anything good, especially considering we are an
> > > >>open-source
> > > >> > library.
> > > >> >
> > > >> > Case in question, I'm moving to updating the spatial module and
> want
> > > >>to
> > > >> > fetch dependencies from nuget. While spatial4n is signed (so it
> can
> > be
> > > >> used
> > > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get
> signed
> > > >>any
> > > >> > time soon. Since signed assemblies cannot reference
> > non-strongly-named
> > > >> > assemblies, I can't currently do that - not through nuget at
> least.
> > > >>This
> > > >> > introduces a lot of frustration and tons of fraction which I'd
> like
> > to
> > > >> have
> > > >> > removed.
> > > >> >
> > > >> > Ideally I'd want to move to removing strong-naming from all
> > Lucene.NET
> > > >> > assemblies (v4 and forward), and having a wiki page that describes
> > why
> > > >> > signing is pointless and how to manually sign it if you insist.
> > > >> >
> > > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > > >>really
> > > >> > matter nowadays and given our usage scenarios:
> > > >> >
> > > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > >> > assemblies can be SN or ILMerged as part of the install process)
> > > >> >
> > > >> > 2. Signed assemblies / project won't be able to get Lucene.NET
> from
> > > >>nuget
> > > >> > directly because they'll have to sign it before referencing it. Or
> > > >>lose
> > > >> SN
> > > >> > themselves.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Itamar Syn-Hershko
> > > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > >> > Freelance Developer & Consultant
> > > >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > >> >
> > > >>
> > >
> > >
> > >
> > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

And compile every component we use in (spatial4n, NTS, etc) and kill every
opportunity for people to enhance Lucene.NET on their own? no thanks

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Mon, Apr 28, 2014 at 7:15 PM, Petar Repac <pe...@gmail.com> wrote:

>
> http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/
>
> ILMerge ?
>
>
> On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> > +1 to Oren's point here
> >
> > Remember the signing dependency issue works both ways, there are lots of
> > other projects that depend on Lucene.Net which do sign their dependencies
> > and so changing whether the project is signed breaks upstream consumers
> of
> > the library
> >
> > An unsigned assembly can happily depend on a signed assembly whereas the
> > opposite is not true
> >
> > Regardless of how effective/valuable SN signing is we are unfortunately
> > stuck with it in the .Net world and you will only get grief.
> >
> > My own project got rid of signing for a while and had to bring it back
> > because we got too many user complaints about this.  For comparison my
> > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > would strongly suspect you will get far more user complaints far more
> > quickly if you drop signing in future releases.
> >
> > Rob
> >
> >
> > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > wrote:
> >
> > >I'm many corporate environment that is a big requirement
> > >In a library like Lucene, where other people depend on it, a sign build
> is
> > >important
> > >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> > >
> > >> There is a long discussion about SN here:
> > >> https://nuget.codeplex.com/discussions/247827
> > >>
> > >> I'd suggest that even if decision is not to sign, there should be an
> > >>easy
> > >> way to get signed assemblies.
> > >>
> > >> Like:
> > >> 1. clone repo (signing keys are publicly accessible in repository)
> > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > >> 3. c/p files from /build folder
> > >>
> > >> I stopped signing my assemblies long ago, but probably there still are
> > >>many
> > >> that still do
> > >> and less obstacles in adopting Lucene.NET the better.
> > >>
> > >> Regards,
> > >> Petar Repac
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > >> >wrote:
> > >>
> > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > >> >
> > >> > We are starting to run into problems with dependencies which not
> being
> > >> > signed. What's becoming more common in the .NET world (OSS mainly)
> is
> > >>to
> > >> > stop signing assemblies because its
> > >> > pretty<
> > >> >
> > >>
> > >>
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> > >>r-fully-verified-when-loaded-to-check-they-haven
> > >> > >
> > >> > much<
> > >> >
> > >>
> > >>
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> > >>g-a-net-assembly
> > >> > >
> > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> (in
> > >>the
> > >> > last link: What Strong Names Can't Do).
> > >> >
> > >> > Regardless of the argument about SN it seems to bring more fraction
> > >>and
> > >> > trouble than anything good, especially considering we are an
> > >>open-source
> > >> > library.
> > >> >
> > >> > Case in question, I'm moving to updating the spatial module and want
> > >>to
> > >> > fetch dependencies from nuget. While spatial4n is signed (so it can
> be
> > >> used
> > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> > >>any
> > >> > time soon. Since signed assemblies cannot reference
> non-strongly-named
> > >> > assemblies, I can't currently do that - not through nuget at least.
> > >>This
> > >> > introduces a lot of frustration and tons of fraction which I'd like
> to
> > >> have
> > >> > removed.
> > >> >
> > >> > Ideally I'd want to move to removing strong-naming from all
> Lucene.NET
> > >> > assemblies (v4 and forward), and having a wiki page that describes
> why
> > >> > signing is pointless and how to manually sign it if you insist.
> > >> >
> > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > >>really
> > >> > matter nowadays and given our usage scenarios:
> > >> >
> > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > >> > assemblies can be SN or ILMerged as part of the install process)
> > >> >
> > >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> > >>nuget
> > >> > directly because they'll have to sign it before referencing it. Or
> > >>lose
> > >> SN
> > >> > themselves.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > --
> > >> >
> > >> > Itamar Syn-Hershko
> > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > >> > Freelance Developer & Consultant
> > >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >> >
> > >>
> >
> >
> >
> >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

And compile every component we use in (spatial4n, NTS, etc) and kill every
opportunity for people to enhance Lucene.NET on their own? no thanks

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Mon, Apr 28, 2014 at 7:15 PM, Petar Repac <pe...@gmail.com> wrote:

>
> http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/
>
> ILMerge ?
>
>
> On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> > +1 to Oren's point here
> >
> > Remember the signing dependency issue works both ways, there are lots of
> > other projects that depend on Lucene.Net which do sign their dependencies
> > and so changing whether the project is signed breaks upstream consumers
> of
> > the library
> >
> > An unsigned assembly can happily depend on a signed assembly whereas the
> > opposite is not true
> >
> > Regardless of how effective/valuable SN signing is we are unfortunately
> > stuck with it in the .Net world and you will only get grief.
> >
> > My own project got rid of signing for a while and had to bring it back
> > because we got too many user complaints about this.  For comparison my
> > project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> > would strongly suspect you will get far more user complaints far more
> > quickly if you drop signing in future releases.
> >
> > Rob
> >
> >
> > On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> > wrote:
> >
> > >I'm many corporate environment that is a big requirement
> > >In a library like Lucene, where other people depend on it, a sign build
> is
> > >important
> > >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> > >
> > >> There is a long discussion about SN here:
> > >> https://nuget.codeplex.com/discussions/247827
> > >>
> > >> I'd suggest that even if decision is not to sign, there should be an
> > >>easy
> > >> way to get signed assemblies.
> > >>
> > >> Like:
> > >> 1. clone repo (signing keys are publicly accessible in repository)
> > >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > >> 3. c/p files from /build folder
> > >>
> > >> I stopped signing my assemblies long ago, but probably there still are
> > >>many
> > >> that still do
> > >> and less obstacles in adopting Lucene.NET the better.
> > >>
> > >> Regards,
> > >> Petar Repac
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > >> >wrote:
> > >>
> > >> > All Lucene.NET assemblies are signed, aka strongly named.
> > >> >
> > >> > We are starting to run into problems with dependencies which not
> being
> > >> > signed. What's becoming more common in the .NET world (OSS mainly)
> is
> > >>to
> > >> > stop signing assemblies because its
> > >> > pretty<
> > >> >
> > >>
> > >>
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> > >>r-fully-verified-when-loaded-to-check-they-haven
> > >> > >
> > >> > much<
> > >> >
> > >>
> > >>
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> > >>g-a-net-assembly
> > >> > >
> > >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> (in
> > >>the
> > >> > last link: What Strong Names Can't Do).
> > >> >
> > >> > Regardless of the argument about SN it seems to bring more fraction
> > >>and
> > >> > trouble than anything good, especially considering we are an
> > >>open-source
> > >> > library.
> > >> >
> > >> > Case in question, I'm moving to updating the spatial module and want
> > >>to
> > >> > fetch dependencies from nuget. While spatial4n is signed (so it can
> be
> > >> used
> > >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> > >>any
> > >> > time soon. Since signed assemblies cannot reference
> non-strongly-named
> > >> > assemblies, I can't currently do that - not through nuget at least.
> > >>This
> > >> > introduces a lot of frustration and tons of fraction which I'd like
> to
> > >> have
> > >> > removed.
> > >> >
> > >> > Ideally I'd want to move to removing strong-naming from all
> Lucene.NET
> > >> > assemblies (v4 and forward), and having a wiki page that describes
> why
> > >> > signing is pointless and how to manually sign it if you insist.
> > >> >
> > >> > I can see 2 disadvantages for not signing, both of which I doubt
> > >>really
> > >> > matter nowadays and given our usage scenarios:
> > >> >
> > >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > >> > assemblies can be SN or ILMerged as part of the install process)
> > >> >
> > >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> > >>nuget
> > >> > directly because they'll have to sign it before referencing it. Or
> > >>lose
> > >> SN
> > >> > themselves.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > --
> > >> >
> > >> > Itamar Syn-Hershko
> > >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > >> > Freelance Developer & Consultant
> > >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >> >
> > >>
> >
> >
> >
> >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Petar Repac <pe...@gmail.com>]

http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/

ILMerge ?


On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> +1 to Oren's point here
>
> Remember the signing dependency issue works both ways, there are lots of
> other projects that depend on Lucene.Net which do sign their dependencies
> and so changing whether the project is signed breaks upstream consumers of
> the library
>
> An unsigned assembly can happily depend on a signed assembly whereas the
> opposite is not true
>
> Regardless of how effective/valuable SN signing is we are unfortunately
> stuck with it in the .Net world and you will only get grief.
>
> My own project got rid of signing for a while and had to bring it back
> because we got too many user complaints about this.  For comparison my
> project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> would strongly suspect you will get far more user complaints far more
> quickly if you drop signing in future releases.
>
> Rob
>
>
> On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> wrote:
>
> >I'm many corporate environment that is a big requirement
> >In a library like Lucene, where other people depend on it, a sign build is
> >important
> >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> >
> >> There is a long discussion about SN here:
> >> https://nuget.codeplex.com/discussions/247827
> >>
> >> I'd suggest that even if decision is not to sign, there should be an
> >>easy
> >> way to get signed assemblies.
> >>
> >> Like:
> >> 1. clone repo (signing keys are publicly accessible in repository)
> >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> >> 3. c/p files from /build folder
> >>
> >> I stopped signing my assemblies long ago, but probably there still are
> >>many
> >> that still do
> >> and less obstacles in adopting Lucene.NET the better.
> >>
> >> Regards,
> >> Petar Repac
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >> >wrote:
> >>
> >> > All Lucene.NET assemblies are signed, aka strongly named.
> >> >
> >> > We are starting to run into problems with dependencies which not being
> >> > signed. What's becoming more common in the .NET world (OSS mainly) is
> >>to
> >> > stop signing assemblies because its
> >> > pretty<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> >>r-fully-verified-when-loaded-to-check-they-haven
> >> > >
> >> > much<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> >>g-a-net-assembly
> >> > >
> >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> >>the
> >> > last link: What Strong Names Can't Do).
> >> >
> >> > Regardless of the argument about SN it seems to bring more fraction
> >>and
> >> > trouble than anything good, especially considering we are an
> >>open-source
> >> > library.
> >> >
> >> > Case in question, I'm moving to updating the spatial module and want
> >>to
> >> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> >> used
> >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> >>any
> >> > time soon. Since signed assemblies cannot reference non-strongly-named
> >> > assemblies, I can't currently do that - not through nuget at least.
> >>This
> >> > introduces a lot of frustration and tons of fraction which I'd like to
> >> have
> >> > removed.
> >> >
> >> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> >> > assemblies (v4 and forward), and having a wiki page that describes why
> >> > signing is pointless and how to manually sign it if you insist.
> >> >
> >> > I can see 2 disadvantages for not signing, both of which I doubt
> >>really
> >> > matter nowadays and given our usage scenarios:
> >> >
> >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> >> > assemblies can be SN or ILMerged as part of the install process)
> >> >
> >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> >>nuget
> >> > directly because they'll have to sign it before referencing it. Or
> >>lose
> >> SN
> >> > themselves.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > Itamar Syn-Hershko
> >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> >> > Freelance Developer & Consultant
> >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >> >
> >>
>
>
>
>
>

Re: Removing signing of assemblies (starting in v4)

[Petar Repac <pe...@gmail.com>]

http://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/

ILMerge ?


On Mon, Apr 28, 2014 at 7:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> +1 to Oren's point here
>
> Remember the signing dependency issue works both ways, there are lots of
> other projects that depend on Lucene.Net which do sign their dependencies
> and so changing whether the project is signed breaks upstream consumers of
> the library
>
> An unsigned assembly can happily depend on a signed assembly whereas the
> opposite is not true
>
> Regardless of how effective/valuable SN signing is we are unfortunately
> stuck with it in the .Net world and you will only get grief.
>
> My own project got rid of signing for a while and had to bring it back
> because we got too many user complaints about this.  For comparison my
> project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> would strongly suspect you will get far more user complaints far more
> quickly if you drop signing in future releases.
>
> Rob
>
>
> On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> wrote:
>
> >I'm many corporate environment that is a big requirement
> >In a library like Lucene, where other people depend on it, a sign build is
> >important
> >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> >
> >> There is a long discussion about SN here:
> >> https://nuget.codeplex.com/discussions/247827
> >>
> >> I'd suggest that even if decision is not to sign, there should be an
> >>easy
> >> way to get signed assemblies.
> >>
> >> Like:
> >> 1. clone repo (signing keys are publicly accessible in repository)
> >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> >> 3. c/p files from /build folder
> >>
> >> I stopped signing my assemblies long ago, but probably there still are
> >>many
> >> that still do
> >> and less obstacles in adopting Lucene.NET the better.
> >>
> >> Regards,
> >> Petar Repac
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >> >wrote:
> >>
> >> > All Lucene.NET assemblies are signed, aka strongly named.
> >> >
> >> > We are starting to run into problems with dependencies which not being
> >> > signed. What's becoming more common in the .NET world (OSS mainly) is
> >>to
> >> > stop signing assemblies because its
> >> > pretty<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> >>r-fully-verified-when-loaded-to-check-they-haven
> >> > >
> >> > much<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> >>g-a-net-assembly
> >> > >
> >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> >>the
> >> > last link: What Strong Names Can't Do).
> >> >
> >> > Regardless of the argument about SN it seems to bring more fraction
> >>and
> >> > trouble than anything good, especially considering we are an
> >>open-source
> >> > library.
> >> >
> >> > Case in question, I'm moving to updating the spatial module and want
> >>to
> >> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> >> used
> >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> >>any
> >> > time soon. Since signed assemblies cannot reference non-strongly-named
> >> > assemblies, I can't currently do that - not through nuget at least.
> >>This
> >> > introduces a lot of frustration and tons of fraction which I'd like to
> >> have
> >> > removed.
> >> >
> >> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> >> > assemblies (v4 and forward), and having a wiki page that describes why
> >> > signing is pointless and how to manually sign it if you insist.
> >> >
> >> > I can see 2 disadvantages for not signing, both of which I doubt
> >>really
> >> > matter nowadays and given our usage scenarios:
> >> >
> >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> >> > assemblies can be SN or ILMerged as part of the install process)
> >> >
> >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> >>nuget
> >> > directly because they'll have to sign it before referencing it. Or
> >>lose
> >> SN
> >> > themselves.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > Itamar Syn-Hershko
> >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> >> > Freelance Developer & Consultant
> >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >> >
> >>
>
>
>
>
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

Yes, and this is why we are going to provide signed versions as downloads +
scripts to sign the sources, just not in the main distribution stream which
is nuget.

We will take a canary testing kind of approach where we will do a
pre-release of v4 and a bugfix release of v3 both usigned and see how much
people will complain.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Mon, Apr 28, 2014 at 8:13 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> +1 to Oren's point here
>
> Remember the signing dependency issue works both ways, there are lots of
> other projects that depend on Lucene.Net which do sign their dependencies
> and so changing whether the project is signed breaks upstream consumers of
> the library
>
> An unsigned assembly can happily depend on a signed assembly whereas the
> opposite is not true
>
> Regardless of how effective/valuable SN signing is we are unfortunately
> stuck with it in the .Net world and you will only get grief.
>
> My own project got rid of signing for a while and had to bring it back
> because we got too many user complaints about this.  For comparison my
> project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
> would strongly suspect you will get far more user complaints far more
> quickly if you drop signing in future releases.
>
> Rob
>
>
> On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com>
> wrote:
>
> >I'm many corporate environment that is a big requirement
> >In a library like Lucene, where other people depend on it, a sign build is
> >important
> >On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
> >
> >> There is a long discussion about SN here:
> >> https://nuget.codeplex.com/discussions/247827
> >>
> >> I'd suggest that even if decision is not to sign, there should be an
> >>easy
> >> way to get signed assemblies.
> >>
> >> Like:
> >> 1. clone repo (signing keys are publicly accessible in repository)
> >> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> >> 3. c/p files from /build folder
> >>
> >> I stopped signing my assemblies long ago, but probably there still are
> >>many
> >> that still do
> >> and less obstacles in adopting Lucene.NET the better.
> >>
> >> Regards,
> >> Petar Repac
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >> >wrote:
> >>
> >> > All Lucene.NET assemblies are signed, aka strongly named.
> >> >
> >> > We are starting to run into problems with dependencies which not being
> >> > signed. What's becoming more common in the .NET world (OSS mainly) is
> >>to
> >> > stop signing assemblies because its
> >> > pretty<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
> >>r-fully-verified-when-loaded-to-check-they-haven
> >> > >
> >> > much<
> >> >
> >>
> >>
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
> >>g-a-net-assembly
> >> > >
> >> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> >>the
> >> > last link: What Strong Names Can't Do).
> >> >
> >> > Regardless of the argument about SN it seems to bring more fraction
> >>and
> >> > trouble than anything good, especially considering we are an
> >>open-source
> >> > library.
> >> >
> >> > Case in question, I'm moving to updating the spatial module and want
> >>to
> >> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> >> used
> >> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> >>any
> >> > time soon. Since signed assemblies cannot reference non-strongly-named
> >> > assemblies, I can't currently do that - not through nuget at least.
> >>This
> >> > introduces a lot of frustration and tons of fraction which I'd like to
> >> have
> >> > removed.
> >> >
> >> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> >> > assemblies (v4 and forward), and having a wiki page that describes why
> >> > signing is pointless and how to manually sign it if you insist.
> >> >
> >> > I can see 2 disadvantages for not signing, both of which I doubt
> >>really
> >> > matter nowadays and given our usage scenarios:
> >> >
> >> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> >> > assemblies can be SN or ILMerged as part of the install process)
> >> >
> >> > 2. Signed assemblies / project won't be able to get Lucene.NET from
> >>nuget
> >> > directly because they'll have to sign it before referencing it. Or
> >>lose
> >> SN
> >> > themselves.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> >
> >> > Itamar Syn-Hershko
> >> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> >> > Freelance Developer & Consultant
> >> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >> >
> >>
>
>
>
>
>

Re: Removing signing of assemblies (starting in v4)

[Rob Vesse <rv...@dotnetrdf.org>]

+1 to Oren's point here

Remember the signing dependency issue works both ways, there are lots of
other projects that depend on Lucene.Net which do sign their dependencies
and so changing whether the project is signed breaks upstream consumers of
the library

An unsigned assembly can happily depend on a signed assembly whereas the
opposite is not true

Regardless of how effective/valuable SN signing is we are unfortunately
stuck with it in the .Net world and you will only get grief.

My own project got rid of signing for a while and had to bring it back
because we got too many user complaints about this.  For comparison my
project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
would strongly suspect you will get far more user complaints far more
quickly if you drop signing in future releases.

Rob


On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com> wrote:

>I'm many corporate environment that is a big requirement
>In a library like Lucene, where other people depend on it, a sign build is
>important
>On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
>
>> There is a long discussion about SN here:
>> https://nuget.codeplex.com/discussions/247827
>>
>> I'd suggest that even if decision is not to sign, there should be an
>>easy
>> way to get signed assemblies.
>>
>> Like:
>> 1. clone repo (signing keys are publicly accessible in repository)
>> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
>> 3. c/p files from /build folder
>>
>> I stopped signing my assemblies long ago, but probably there still are
>>many
>> that still do
>> and less obstacles in adopting Lucene.NET the better.
>>
>> Regards,
>> Petar Repac
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
>> >wrote:
>>
>> > All Lucene.NET assemblies are signed, aka strongly named.
>> >
>> > We are starting to run into problems with dependencies which not being
>> > signed. What's becoming more common in the .NET world (OSS mainly) is
>>to
>> > stop signing assemblies because its
>> > pretty<
>> >
>> 
>>http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
>>r-fully-verified-when-loaded-to-check-they-haven
>> > >
>> > much<
>> >
>> 
>>http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
>>g-a-net-assembly
>> > >
>> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
>>the
>> > last link: What Strong Names Can't Do).
>> >
>> > Regardless of the argument about SN it seems to bring more fraction
>>and
>> > trouble than anything good, especially considering we are an
>>open-source
>> > library.
>> >
>> > Case in question, I'm moving to updating the spatial module and want
>>to
>> > fetch dependencies from nuget. While spatial4n is signed (so it can be
>> used
>> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
>>any
>> > time soon. Since signed assemblies cannot reference non-strongly-named
>> > assemblies, I can't currently do that - not through nuget at least.
>>This
>> > introduces a lot of frustration and tons of fraction which I'd like to
>> have
>> > removed.
>> >
>> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
>> > assemblies (v4 and forward), and having a wiki page that describes why
>> > signing is pointless and how to manually sign it if you insist.
>> >
>> > I can see 2 disadvantages for not signing, both of which I doubt
>>really
>> > matter nowadays and given our usage scenarios:
>> >
>> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
>> > assemblies can be SN or ILMerged as part of the install process)
>> >
>> > 2. Signed assemblies / project won't be able to get Lucene.NET from
>>nuget
>> > directly because they'll have to sign it before referencing it. Or
>>lose
>> SN
>> > themselves.
>> >
>> > Thoughts?
>> >
>> > --
>> >
>> > Itamar Syn-Hershko
>> > http://code972.com | @synhershko <https://twitter.com/synhershko>
>> > Freelance Developer & Consultant
>> > Author of RavenDB in Action <http://manning.com/synhershko/>
>> >
>>

Re: Removing signing of assemblies (starting in v4)

[Rob Vesse <rv...@dotnetrdf.org>]

+1 to Oren's point here

Remember the signing dependency issue works both ways, there are lots of
other projects that depend on Lucene.Net which do sign their dependencies
and so changing whether the project is signed breaks upstream consumers of
the library

An unsigned assembly can happily depend on a signed assembly whereas the
opposite is not true

Regardless of how effective/valuable SN signing is we are unfortunately
stuck with it in the .Net world and you will only get grief.

My own project got rid of signing for a while and had to bring it back
because we got too many user complaints about this.  For comparison my
project has ~10k downloads on NuGet whereas Lucene.Net has ~500k so I
would strongly suspect you will get far more user complaints far more
quickly if you drop signing in future releases.

Rob


On 23/04/2014 08:11, "Oren Eini (Ayende Rahien)" <ay...@ayende.com> wrote:

>I'm many corporate environment that is a big requirement
>In a library like Lucene, where other people depend on it, a sign build is
>important
>On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:
>
>> There is a long discussion about SN here:
>> https://nuget.codeplex.com/discussions/247827
>>
>> I'd suggest that even if decision is not to sign, there should be an
>>easy
>> way to get signed assemblies.
>>
>> Like:
>> 1. clone repo (signing keys are publicly accessible in repository)
>> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
>> 3. c/p files from /build folder
>>
>> I stopped signing my assemblies long ago, but probably there still are
>>many
>> that still do
>> and less obstacles in adopting Lucene.NET the better.
>>
>> Regards,
>> Petar Repac
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
>> >wrote:
>>
>> > All Lucene.NET assemblies are signed, aka strongly named.
>> >
>> > We are starting to run into problems with dependencies which not being
>> > signed. What's becoming more common in the .NET world (OSS mainly) is
>>to
>> > stop signing assemblies because its
>> > pretty<
>> >
>> 
>>http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-eve
>>r-fully-verified-when-loaded-to-check-they-haven
>> > >
>> > much<
>> >
>> 
>>http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signin
>>g-a-net-assembly
>> > >
>> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
>>the
>> > last link: What Strong Names Can't Do).
>> >
>> > Regardless of the argument about SN it seems to bring more fraction
>>and
>> > trouble than anything good, especially considering we are an
>>open-source
>> > library.
>> >
>> > Case in question, I'm moving to updating the spatial module and want
>>to
>> > fetch dependencies from nuget. While spatial4n is signed (so it can be
>> used
>> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
>>any
>> > time soon. Since signed assemblies cannot reference non-strongly-named
>> > assemblies, I can't currently do that - not through nuget at least.
>>This
>> > introduces a lot of frustration and tons of fraction which I'd like to
>> have
>> > removed.
>> >
>> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
>> > assemblies (v4 and forward), and having a wiki page that describes why
>> > signing is pointless and how to manually sign it if you insist.
>> >
>> > I can see 2 disadvantages for not signing, both of which I doubt
>>really
>> > matter nowadays and given our usage scenarios:
>> >
>> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
>> > assemblies can be SN or ILMerged as part of the install process)
>> >
>> > 2. Signed assemblies / project won't be able to get Lucene.NET from
>>nuget
>> > directly because they'll have to sign it before referencing it. Or
>>lose
>> SN
>> > themselves.
>> >
>> > Thoughts?
>> >
>> > --
>> >
>> > Itamar Syn-Hershko
>> > http://code972.com | @synhershko <https://twitter.com/synhershko>
>> > Freelance Developer & Consultant
>> > Author of RavenDB in Action <http://manning.com/synhershko/>
>> >
>>

Re: Removing signing of assemblies (starting in v4)

["Oren Eini (Ayende Rahien)" <ay...@ayende.com>]

I'm many corporate environment that is a big requirement
In a library like Lucene, where other people depend on it, a sign build is
important
On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:

> There is a long discussion about SN here:
> https://nuget.codeplex.com/discussions/247827
>
> I'd suggest that even if decision is not to sign, there should be an easy
> way to get signed assemblies.
>
> Like:
> 1. clone repo (signing keys are publicly accessible in repository)
> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> 3. c/p files from /build folder
>
> I stopped signing my assemblies long ago, but probably there still are many
> that still do
> and less obstacles in adopting Lucene.NET the better.
>
> Regards,
> Petar Repac
>
>
>
>
>
>
> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > All Lucene.NET assemblies are signed, aka strongly named.
> >
> > We are starting to run into problems with dependencies which not being
> > signed. What's becoming more common in the .NET world (OSS mainly) is to
> > stop signing assemblies because its
> > pretty<
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > >
> > much<
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > >
> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> > last link: What Strong Names Can't Do).
> >
> > Regardless of the argument about SN it seems to bring more fraction and
> > trouble than anything good, especially considering we are an open-source
> > library.
> >
> > Case in question, I'm moving to updating the spatial module and want to
> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> used
> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > time soon. Since signed assemblies cannot reference non-strongly-named
> > assemblies, I can't currently do that - not through nuget at least. This
> > introduces a lot of frustration and tons of fraction which I'd like to
> have
> > removed.
> >
> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > assemblies (v4 and forward), and having a wiki page that describes why
> > signing is pointless and how to manually sign it if you insist.
> >
> > I can see 2 disadvantages for not signing, both of which I doubt really
> > matter nowadays and given our usage scenarios:
> >
> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > assemblies can be SN or ILMerged as part of the install process)
> >
> > 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> > directly because they'll have to sign it before referencing it. Or lose
> SN
> > themselves.
> >
> > Thoughts?
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
>

Re: Removing signing of assemblies (starting in v4)

["Oren Eini (Ayende Rahien)" <ay...@ayende.com>]

I'm many corporate environment that is a big requirement
In a library like Lucene, where other people depend on it, a sign build is
important
On Apr 23, 2014 2:27 PM, "Petar Repac" <pe...@gmail.com> wrote:

> There is a long discussion about SN here:
> https://nuget.codeplex.com/discussions/247827
>
> I'd suggest that even if decision is not to sign, there should be an easy
> way to get signed assemblies.
>
> Like:
> 1. clone repo (signing keys are publicly accessible in repository)
> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> 3. c/p files from /build folder
>
> I stopped signing my assemblies long ago, but probably there still are many
> that still do
> and less obstacles in adopting Lucene.NET the better.
>
> Regards,
> Petar Repac
>
>
>
>
>
>
> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > All Lucene.NET assemblies are signed, aka strongly named.
> >
> > We are starting to run into problems with dependencies which not being
> > signed. What's becoming more common in the .NET world (OSS mainly) is to
> > stop signing assemblies because its
> > pretty<
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > >
> > much<
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > >
> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> > last link: What Strong Names Can't Do).
> >
> > Regardless of the argument about SN it seems to bring more fraction and
> > trouble than anything good, especially considering we are an open-source
> > library.
> >
> > Case in question, I'm moving to updating the spatial module and want to
> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> used
> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > time soon. Since signed assemblies cannot reference non-strongly-named
> > assemblies, I can't currently do that - not through nuget at least. This
> > introduces a lot of frustration and tons of fraction which I'd like to
> have
> > removed.
> >
> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > assemblies (v4 and forward), and having a wiki page that describes why
> > signing is pointless and how to manually sign it if you insist.
> >
> > I can see 2 disadvantages for not signing, both of which I doubt really
> > matter nowadays and given our usage scenarios:
> >
> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > assemblies can be SN or ILMerged as part of the install process)
> >
> > 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> > directly because they'll have to sign it before referencing it. Or lose
> SN
> > themselves.
> >
> > Thoughts?
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
>

Re: Removing signing of assemblies (starting in v4)

[michael herndon <mh...@michaelherndon.com>]

It might be easier to hold a vote for this. That way it gets approved and
it can just move forward.

All releases require a vote to pass, so it would be frustrating for someone
to do do all that work, then release only to have it stopped due to the
changes.

I think starting it with v3 would be fine.

-M


On Thu, Apr 24, 2014 at 3:33 AM, Itamar Syn-Hershko <it...@code972.com>wrote:

> I like this idea of a separate download
>
> Do we want this to happen only for v4 or start with the v3 bugfix release
> so it comes out sooner rather than later?
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Thu, Apr 24, 2014 at 4:31 AM, michael herndon <
> mherndon@michaelherndon.com> wrote:
>
> > Corporations and Governments tend to use signed assemblies in their
> > internal applications.
> >
> > They'll typically download the binaries, put it into their own dependency
> > store. Some will take the time to confirm the hash and run security
> checks
> > on the binary.
> >
> > Creating signed assemblies and making them available to download would be
> > less friction to consumers.
> >
> > It might be as simple doing the following:
> >
> >  <PropertyGroup Condition=" '$(Configuration)' == 'ReleaseSigned'">
> >
> >
> > <AssemblyOriginatorKeyFile>Lucene.Net.snk</AssemblyOriginatorKeyFile>
> > <SignAssembly>true</SignAssembly>
> > </PropertyGroup>
> >
> >
> > Another option would be to create an alternate feed on a site like
> > myget.org
> > .
> >
> > -M
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 8:08 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > I thought about the option of having 2 nugets, but I really don't think
> > > that's a good solution. As Petar mentioned, the better solution would
> be
> > to
> > > provide an easy way to sign the assemblies and have it properly
> > documented
> > > and highlighted in the source and our website.
> > >
> > > What that means is places that _do_ need a signed Lucene.NET will have
> to
> > > get it manually (and not through nuget), run the signing script, and
> then
> > > reference it manually. I'd actually expect that in corporate
> environments
> > > where this is indeed required and rules can't be changed nuget won't be
> > in
> > > wide use anyway. At least that's what I usually see.
> > >
> > > Seems like the next release of NTS will be signed again:
> > > https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not
> > sure
> > > how it happened that they stopped signing it and then decided to bring
> it
> > > back. Oh well. What that means is this lost some of the severity
> (besides
> > > delaying the v3 bugfix release), but I still think this is an important
> > > discussion.
> > >
> > > I'm still contemplating on this. I'm thinking of removing signing on
> the
> > v4
> > > branch, and start releasing it as -Pre to nuget and let it boil over
> > there.
> > > Worst case we can only bring signing again, but so far nobody has shown
> > big
> > > objection.
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant
> > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >
> > >
> > > On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com>
> > wrote:
> > >
> > > > We too have moved away from signing assemblies. What about building
> two
> > > > Nugets a signed and an unsigned version differentiated by name. This
> > > would
> > > > lighten the load on adoption of Lucene.Net for organizations which
> > > require
> > > > signing.
> > > >
> > > > - KevM
> > > >
> > > > On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> > > > wrote:
> > > >
> > > > There is a long discussion about SN here:
> > > > https://nuget.codeplex.com/discussions/247827
> > > >
> > > > I'd suggest that even if decision is not to sign, there should be an
> > easy
> > > > way to get signed assemblies.
> > > >
> > > > Like:
> > > > 1. clone repo (signing keys are publicly accessible in repository)
> > > > 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > > > 3. c/p files from /build folder
> > > >
> > > > I stopped signing my assemblies long ago, but probably there still
> are
> > > many
> > > > that still do
> > > > and less obstacles in adopting Lucene.NET the better.
> > > >
> > > > Regards,
> > > > Petar Repac
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > >wrote:
> > > >
> > > > > All Lucene.NET assemblies are signed, aka strongly named.
> > > > >
> > > > > We are starting to run into problems with dependencies which not
> > being
> > > > > signed. What's becoming more common in the .NET world (OSS mainly)
> is
> > > to
> > > > > stop signing assemblies because its
> > > > > pretty<
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > > > > >
> > > > > much<
> > > > >
> > > >
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > > > > >
> > > > > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx>
> (in
> > > the
> > > > > last link: What Strong Names Can't Do).
> > > > >
> > > > > Regardless of the argument about SN it seems to bring more fraction
> > and
> > > > > trouble than anything good, especially considering we are an
> > > open-source
> > > > > library.
> > > > >
> > > > > Case in question, I'm moving to updating the spatial module and
> want
> > to
> > > > > fetch dependencies from nuget. While spatial4n is signed (so it can
> > be
> > > > used
> > > > > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> > any
> > > > > time soon. Since signed assemblies cannot reference
> > non-strongly-named
> > > > > assemblies, I can't currently do that - not through nuget at least.
> > > This
> > > > > introduces a lot of frustration and tons of fraction which I'd like
> > to
> > > > have
> > > > > removed.
> > > > >
> > > > > Ideally I'd want to move to removing strong-naming from all
> > Lucene.NET
> > > > > assemblies (v4 and forward), and having a wiki page that describes
> > why
> > > > > signing is pointless and how to manually sign it if you insist.
> > > > >
> > > > > I can see 2 disadvantages for not signing, both of which I doubt
> > really
> > > > > matter nowadays and given our usage scenarios:
> > > > >
> > > > > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > > > assemblies can be SN or ILMerged as part of the install process)
> > > > >
> > > > > 2. Signed assemblies / project won't be able to get Lucene.NET from
> > > nuget
> > > > > directly because they'll have to sign it before referencing it. Or
> > lose
> > > > SN
> > > > > themselves.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > --
> > > > >
> > > > > Itamar Syn-Hershko
> > > > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > > > Freelance Developer & Consultant
> > > > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > > >
> > > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I like this idea of a separate download

Do we want this to happen only for v4 or start with the v3 bugfix release
so it comes out sooner rather than later?

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Thu, Apr 24, 2014 at 4:31 AM, michael herndon <
mherndon@michaelherndon.com> wrote:

> Corporations and Governments tend to use signed assemblies in their
> internal applications.
>
> They'll typically download the binaries, put it into their own dependency
> store. Some will take the time to confirm the hash and run security checks
> on the binary.
>
> Creating signed assemblies and making them available to download would be
> less friction to consumers.
>
> It might be as simple doing the following:
>
>  <PropertyGroup Condition=" '$(Configuration)' == 'ReleaseSigned'">
>
>
> <AssemblyOriginatorKeyFile>Lucene.Net.snk</AssemblyOriginatorKeyFile>
> <SignAssembly>true</SignAssembly>
> </PropertyGroup>
>
>
> Another option would be to create an alternate feed on a site like
> myget.org
> .
>
> -M
>
>
>
>
>
> On Wed, Apr 23, 2014 at 8:08 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > I thought about the option of having 2 nugets, but I really don't think
> > that's a good solution. As Petar mentioned, the better solution would be
> to
> > provide an easy way to sign the assemblies and have it properly
> documented
> > and highlighted in the source and our website.
> >
> > What that means is places that _do_ need a signed Lucene.NET will have to
> > get it manually (and not through nuget), run the signing script, and then
> > reference it manually. I'd actually expect that in corporate environments
> > where this is indeed required and rules can't be changed nuget won't be
> in
> > wide use anyway. At least that's what I usually see.
> >
> > Seems like the next release of NTS will be signed again:
> > https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not
> sure
> > how it happened that they stopped signing it and then decided to bring it
> > back. Oh well. What that means is this lost some of the severity (besides
> > delaying the v3 bugfix release), but I still think this is an important
> > discussion.
> >
> > I'm still contemplating on this. I'm thinking of removing signing on the
> v4
> > branch, and start releasing it as -Pre to nuget and let it boil over
> there.
> > Worst case we can only bring signing again, but so far nobody has shown
> big
> > objection.
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
> >
> > On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com>
> wrote:
> >
> > > We too have moved away from signing assemblies. What about building two
> > > Nugets a signed and an unsigned version differentiated by name. This
> > would
> > > lighten the load on adoption of Lucene.Net for organizations which
> > require
> > > signing.
> > >
> > > - KevM
> > >
> > > On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> > > wrote:
> > >
> > > There is a long discussion about SN here:
> > > https://nuget.codeplex.com/discussions/247827
> > >
> > > I'd suggest that even if decision is not to sign, there should be an
> easy
> > > way to get signed assemblies.
> > >
> > > Like:
> > > 1. clone repo (signing keys are publicly accessible in repository)
> > > 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > > 3. c/p files from /build folder
> > >
> > > I stopped signing my assemblies long ago, but probably there still are
> > many
> > > that still do
> > > and less obstacles in adopting Lucene.NET the better.
> > >
> > > Regards,
> > > Petar Repac
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > >wrote:
> > >
> > > > All Lucene.NET assemblies are signed, aka strongly named.
> > > >
> > > > We are starting to run into problems with dependencies which not
> being
> > > > signed. What's becoming more common in the .NET world (OSS mainly) is
> > to
> > > > stop signing assemblies because its
> > > > pretty<
> > > >
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > > > >
> > > > much<
> > > >
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > > > >
> > > > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> > the
> > > > last link: What Strong Names Can't Do).
> > > >
> > > > Regardless of the argument about SN it seems to bring more fraction
> and
> > > > trouble than anything good, especially considering we are an
> > open-source
> > > > library.
> > > >
> > > > Case in question, I'm moving to updating the spatial module and want
> to
> > > > fetch dependencies from nuget. While spatial4n is signed (so it can
> be
> > > used
> > > > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> any
> > > > time soon. Since signed assemblies cannot reference
> non-strongly-named
> > > > assemblies, I can't currently do that - not through nuget at least.
> > This
> > > > introduces a lot of frustration and tons of fraction which I'd like
> to
> > > have
> > > > removed.
> > > >
> > > > Ideally I'd want to move to removing strong-naming from all
> Lucene.NET
> > > > assemblies (v4 and forward), and having a wiki page that describes
> why
> > > > signing is pointless and how to manually sign it if you insist.
> > > >
> > > > I can see 2 disadvantages for not signing, both of which I doubt
> really
> > > > matter nowadays and given our usage scenarios:
> > > >
> > > > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > > assemblies can be SN or ILMerged as part of the install process)
> > > >
> > > > 2. Signed assemblies / project won't be able to get Lucene.NET from
> > nuget
> > > > directly because they'll have to sign it before referencing it. Or
> lose
> > > SN
> > > > themselves.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > >
> > > > Itamar Syn-Hershko
> > > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > > Freelance Developer & Consultant
> > > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I like this idea of a separate download

Do we want this to happen only for v4 or start with the v3 bugfix release
so it comes out sooner rather than later?

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Thu, Apr 24, 2014 at 4:31 AM, michael herndon <
mherndon@michaelherndon.com> wrote:

> Corporations and Governments tend to use signed assemblies in their
> internal applications.
>
> They'll typically download the binaries, put it into their own dependency
> store. Some will take the time to confirm the hash and run security checks
> on the binary.
>
> Creating signed assemblies and making them available to download would be
> less friction to consumers.
>
> It might be as simple doing the following:
>
>  <PropertyGroup Condition=" '$(Configuration)' == 'ReleaseSigned'">
>
>
> <AssemblyOriginatorKeyFile>Lucene.Net.snk</AssemblyOriginatorKeyFile>
> <SignAssembly>true</SignAssembly>
> </PropertyGroup>
>
>
> Another option would be to create an alternate feed on a site like
> myget.org
> .
>
> -M
>
>
>
>
>
> On Wed, Apr 23, 2014 at 8:08 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > I thought about the option of having 2 nugets, but I really don't think
> > that's a good solution. As Petar mentioned, the better solution would be
> to
> > provide an easy way to sign the assemblies and have it properly
> documented
> > and highlighted in the source and our website.
> >
> > What that means is places that _do_ need a signed Lucene.NET will have to
> > get it manually (and not through nuget), run the signing script, and then
> > reference it manually. I'd actually expect that in corporate environments
> > where this is indeed required and rules can't be changed nuget won't be
> in
> > wide use anyway. At least that's what I usually see.
> >
> > Seems like the next release of NTS will be signed again:
> > https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not
> sure
> > how it happened that they stopped signing it and then decided to bring it
> > back. Oh well. What that means is this lost some of the severity (besides
> > delaying the v3 bugfix release), but I still think this is an important
> > discussion.
> >
> > I'm still contemplating on this. I'm thinking of removing signing on the
> v4
> > branch, and start releasing it as -Pre to nuget and let it boil over
> there.
> > Worst case we can only bring signing again, but so far nobody has shown
> big
> > objection.
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
> >
> > On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com>
> wrote:
> >
> > > We too have moved away from signing assemblies. What about building two
> > > Nugets a signed and an unsigned version differentiated by name. This
> > would
> > > lighten the load on adoption of Lucene.Net for organizations which
> > require
> > > signing.
> > >
> > > - KevM
> > >
> > > On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> > > wrote:
> > >
> > > There is a long discussion about SN here:
> > > https://nuget.codeplex.com/discussions/247827
> > >
> > > I'd suggest that even if decision is not to sign, there should be an
> easy
> > > way to get signed assemblies.
> > >
> > > Like:
> > > 1. clone repo (signing keys are publicly accessible in repository)
> > > 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > > 3. c/p files from /build folder
> > >
> > > I stopped signing my assemblies long ago, but probably there still are
> > many
> > > that still do
> > > and less obstacles in adopting Lucene.NET the better.
> > >
> > > Regards,
> > > Petar Repac
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > >wrote:
> > >
> > > > All Lucene.NET assemblies are signed, aka strongly named.
> > > >
> > > > We are starting to run into problems with dependencies which not
> being
> > > > signed. What's becoming more common in the .NET world (OSS mainly) is
> > to
> > > > stop signing assemblies because its
> > > > pretty<
> > > >
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > > > >
> > > > much<
> > > >
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > > > >
> > > > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> > the
> > > > last link: What Strong Names Can't Do).
> > > >
> > > > Regardless of the argument about SN it seems to bring more fraction
> and
> > > > trouble than anything good, especially considering we are an
> > open-source
> > > > library.
> > > >
> > > > Case in question, I'm moving to updating the spatial module and want
> to
> > > > fetch dependencies from nuget. While spatial4n is signed (so it can
> be
> > > used
> > > > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed
> any
> > > > time soon. Since signed assemblies cannot reference
> non-strongly-named
> > > > assemblies, I can't currently do that - not through nuget at least.
> > This
> > > > introduces a lot of frustration and tons of fraction which I'd like
> to
> > > have
> > > > removed.
> > > >
> > > > Ideally I'd want to move to removing strong-naming from all
> Lucene.NET
> > > > assemblies (v4 and forward), and having a wiki page that describes
> why
> > > > signing is pointless and how to manually sign it if you insist.
> > > >
> > > > I can see 2 disadvantages for not signing, both of which I doubt
> really
> > > > matter nowadays and given our usage scenarios:
> > > >
> > > > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > > assemblies can be SN or ILMerged as part of the install process)
> > > >
> > > > 2. Signed assemblies / project won't be able to get Lucene.NET from
> > nuget
> > > > directly because they'll have to sign it before referencing it. Or
> lose
> > > SN
> > > > themselves.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > >
> > > > Itamar Syn-Hershko
> > > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > > Freelance Developer & Consultant
> > > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > >
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[michael herndon <mh...@michaelherndon.com>]

Corporations and Governments tend to use signed assemblies in their
internal applications.

They'll typically download the binaries, put it into their own dependency
store. Some will take the time to confirm the hash and run security checks
on the binary.

Creating signed assemblies and making them available to download would be
less friction to consumers.

It might be as simple doing the following:

 <PropertyGroup Condition=" '$(Configuration)' == 'ReleaseSigned'">


<AssemblyOriginatorKeyFile>Lucene.Net.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>
</PropertyGroup>


Another option would be to create an alternate feed on a site like myget.org
.

-M





On Wed, Apr 23, 2014 at 8:08 PM, Itamar Syn-Hershko <it...@code972.com>wrote:

> I thought about the option of having 2 nugets, but I really don't think
> that's a good solution. As Petar mentioned, the better solution would be to
> provide an easy way to sign the assemblies and have it properly documented
> and highlighted in the source and our website.
>
> What that means is places that _do_ need a signed Lucene.NET will have to
> get it manually (and not through nuget), run the signing script, and then
> reference it manually. I'd actually expect that in corporate environments
> where this is indeed required and rules can't be changed nuget won't be in
> wide use anyway. At least that's what I usually see.
>
> Seems like the next release of NTS will be signed again:
> https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not sure
> how it happened that they stopped signing it and then decided to bring it
> back. Oh well. What that means is this lost some of the severity (besides
> delaying the v3 bugfix release), but I still think this is an important
> discussion.
>
> I'm still contemplating on this. I'm thinking of removing signing on the v4
> branch, and start releasing it as -Pre to nuget and let it boil over there.
> Worst case we can only bring signing again, but so far nobody has shown big
> objection.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>
>
> On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com> wrote:
>
> > We too have moved away from signing assemblies. What about building two
> > Nugets a signed and an unsigned version differentiated by name. This
> would
> > lighten the load on adoption of Lucene.Net for organizations which
> require
> > signing.
> >
> > - KevM
> >
> > On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> > wrote:
> >
> > There is a long discussion about SN here:
> > https://nuget.codeplex.com/discussions/247827
> >
> > I'd suggest that even if decision is not to sign, there should be an easy
> > way to get signed assemblies.
> >
> > Like:
> > 1. clone repo (signing keys are publicly accessible in repository)
> > 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> > 3. c/p files from /build folder
> >
> > I stopped signing my assemblies long ago, but probably there still are
> many
> > that still do
> > and less obstacles in adopting Lucene.NET the better.
> >
> > Regards,
> > Petar Repac
> >
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > All Lucene.NET assemblies are signed, aka strongly named.
> > >
> > > We are starting to run into problems with dependencies which not being
> > > signed. What's becoming more common in the .NET world (OSS mainly) is
> to
> > > stop signing assemblies because its
> > > pretty<
> > >
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > > >
> > > much<
> > >
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > > >
> > > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in
> the
> > > last link: What Strong Names Can't Do).
> > >
> > > Regardless of the argument about SN it seems to bring more fraction and
> > > trouble than anything good, especially considering we are an
> open-source
> > > library.
> > >
> > > Case in question, I'm moving to updating the spatial module and want to
> > > fetch dependencies from nuget. While spatial4n is signed (so it can be
> > used
> > > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > > time soon. Since signed assemblies cannot reference non-strongly-named
> > > assemblies, I can't currently do that - not through nuget at least.
> This
> > > introduces a lot of frustration and tons of fraction which I'd like to
> > have
> > > removed.
> > >
> > > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > > assemblies (v4 and forward), and having a wiki page that describes why
> > > signing is pointless and how to manually sign it if you insist.
> > >
> > > I can see 2 disadvantages for not signing, both of which I doubt really
> > > matter nowadays and given our usage scenarios:
> > >
> > > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > > assemblies can be SN or ILMerged as part of the install process)
> > >
> > > 2. Signed assemblies / project won't be able to get Lucene.NET from
> nuget
> > > directly because they'll have to sign it before referencing it. Or lose
> > SN
> > > themselves.
> > >
> > > Thoughts?
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant
> > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I thought about the option of having 2 nugets, but I really don't think
that's a good solution. As Petar mentioned, the better solution would be to
provide an easy way to sign the assemblies and have it properly documented
and highlighted in the source and our website.

What that means is places that _do_ need a signed Lucene.NET will have to
get it manually (and not through nuget), run the signing script, and then
reference it manually. I'd actually expect that in corporate environments
where this is indeed required and rules can't be changed nuget won't be in
wide use anyway. At least that's what I usually see.

Seems like the next release of NTS will be signed again:
https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not sure
how it happened that they stopped signing it and then decided to bring it
back. Oh well. What that means is this lost some of the severity (besides
delaying the v3 bugfix release), but I still think this is an important
discussion.

I'm still contemplating on this. I'm thinking of removing signing on the v4
branch, and start releasing it as -Pre to nuget and let it boil over there.
Worst case we can only bring signing again, but so far nobody has shown big
objection.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com> wrote:

> We too have moved away from signing assemblies. What about building two
> Nugets a signed and an unsigned version differentiated by name. This would
> lighten the load on adoption of Lucene.Net for organizations which require
> signing.
>
> - KevM
>
> On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> wrote:
>
> There is a long discussion about SN here:
> https://nuget.codeplex.com/discussions/247827
>
> I'd suggest that even if decision is not to sign, there should be an easy
> way to get signed assemblies.
>
> Like:
> 1. clone repo (signing keys are publicly accessible in repository)
> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> 3. c/p files from /build folder
>
> I stopped signing my assemblies long ago, but probably there still are many
> that still do
> and less obstacles in adopting Lucene.NET the better.
>
> Regards,
> Petar Repac
>
>
>
>
>
>
> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > All Lucene.NET assemblies are signed, aka strongly named.
> >
> > We are starting to run into problems with dependencies which not being
> > signed. What's becoming more common in the .NET world (OSS mainly) is to
> > stop signing assemblies because its
> > pretty<
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > >
> > much<
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > >
> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> > last link: What Strong Names Can't Do).
> >
> > Regardless of the argument about SN it seems to bring more fraction and
> > trouble than anything good, especially considering we are an open-source
> > library.
> >
> > Case in question, I'm moving to updating the spatial module and want to
> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> used
> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > time soon. Since signed assemblies cannot reference non-strongly-named
> > assemblies, I can't currently do that - not through nuget at least. This
> > introduces a lot of frustration and tons of fraction which I'd like to
> have
> > removed.
> >
> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > assemblies (v4 and forward), and having a wiki page that describes why
> > signing is pointless and how to manually sign it if you insist.
> >
> > I can see 2 disadvantages for not signing, both of which I doubt really
> > matter nowadays and given our usage scenarios:
> >
> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > assemblies can be SN or ILMerged as part of the install process)
> >
> > 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> > directly because they'll have to sign it before referencing it. Or lose
> SN
> > themselves.
> >
> > Thoughts?
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
>

Re: Removing signing of assemblies (starting in v4)

[Itamar Syn-Hershko <it...@code972.com>]

I thought about the option of having 2 nugets, but I really don't think
that's a good solution. As Petar mentioned, the better solution would be to
provide an easy way to sign the assemblies and have it properly documented
and highlighted in the source and our website.

What that means is places that _do_ need a signed Lucene.NET will have to
get it manually (and not through nuget), run the signing script, and then
reference it manually. I'd actually expect that in corporate environments
where this is indeed required and rules can't be changed nuget won't be in
wide use anyway. At least that's what I usually see.

Seems like the next release of NTS will be signed again:
https://code.google.com/p/nettopologysuite/issues/detail?id=174 . Not sure
how it happened that they stopped signing it and then decided to bring it
back. Oh well. What that means is this lost some of the severity (besides
delaying the v3 bugfix release), but I still think this is an important
discussion.

I'm still contemplating on this. I'm thinking of removing signing on the v4
branch, and start releasing it as -Pre to nuget and let it boil over there.
Worst case we can only bring signing again, but so far nobody has shown big
objection.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Wed, Apr 23, 2014 at 4:11 PM, Kevin Miller <sc...@gmail.com> wrote:

> We too have moved away from signing assemblies. What about building two
> Nugets a signed and an unsigned version differentiated by name. This would
> lighten the load on adoption of Lucene.Net for organizations which require
> signing.
>
> - KevM
>
> On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com)
> wrote:
>
> There is a long discussion about SN here:
> https://nuget.codeplex.com/discussions/247827
>
> I'd suggest that even if decision is not to sign, there should be an easy
> way to get signed assemblies.
>
> Like:
> 1. clone repo (signing keys are publicly accessible in repository)
> 2. run BuildSigned.bat (or PowerShell script, Rake, ....)
> 3. c/p files from /build folder
>
> I stopped signing my assemblies long ago, but probably there still are many
> that still do
> and less obstacles in adopting Lucene.NET the better.
>
> Regards,
> Petar Repac
>
>
>
>
>
>
> On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > All Lucene.NET assemblies are signed, aka strongly named.
> >
> > We are starting to run into problems with dependencies which not being
> > signed. What's becoming more common in the .NET world (OSS mainly) is to
> > stop signing assemblies because its
> > pretty<
> >
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> > >
> > much<
> >
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> > >
> > useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> > last link: What Strong Names Can't Do).
> >
> > Regardless of the argument about SN it seems to bring more fraction and
> > trouble than anything good, especially considering we are an open-source
> > library.
> >
> > Case in question, I'm moving to updating the spatial module and want to
> > fetch dependencies from nuget. While spatial4n is signed (so it can be
> used
> > from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> > time soon. Since signed assemblies cannot reference non-strongly-named
> > assemblies, I can't currently do that - not through nuget at least. This
> > introduces a lot of frustration and tons of fraction which I'd like to
> have
> > removed.
> >
> > Ideally I'd want to move to removing strong-naming from all Lucene.NET
> > assemblies (v4 and forward), and having a wiki page that describes why
> > signing is pointless and how to manually sign it if you insist.
> >
> > I can see 2 disadvantages for not signing, both of which I doubt really
> > matter nowadays and given our usage scenarios:
> >
> > 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> > assemblies can be SN or ILMerged as part of the install process)
> >
> > 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> > directly because they'll have to sign it before referencing it. Or lose
> SN
> > themselves.
> >
> > Thoughts?
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant
> > Author of RavenDB in Action <http://manning.com/synhershko/>
> >
>

Re: Removing signing of assemblies (starting in v4)

[Kevin Miller <sc...@gmail.com>]

We too have moved away from signing assemblies. What about building two Nugets a signed and an unsigned version differentiated by name. This would lighten the load on adoption of Lucene.Net for organizations which require signing. 

- KevM 

On April 23, 2014 at 7:45:12 AM, Petar Repac (petar.repac@gmail.com) wrote:

There is a long discussion about SN here:  
https://nuget.codeplex.com/discussions/247827  

I'd suggest that even if decision is not to sign, there should be an easy  
way to get signed assemblies.  

Like:  
1. clone repo (signing keys are publicly accessible in repository)  
2. run BuildSigned.bat (or PowerShell script, Rake, ....)  
3. c/p files from /build folder  

I stopped signing my assemblies long ago, but probably there still are many  
that still do  
and less obstacles in adopting Lucene.NET the better.  

Regards,  
Petar Repac  






On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <it...@code972.com>wrote:  

> All Lucene.NET assemblies are signed, aka strongly named.  
>  
> We are starting to run into problems with dependencies which not being  
> signed. What's becoming more common in the .NET world (OSS mainly) is to  
> stop signing assemblies because its  
> pretty<  
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven  
> >  
> much<  
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly  
> >  
> useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the  
> last link: What Strong Names Can't Do).  
>  
> Regardless of the argument about SN it seems to bring more fraction and  
> trouble than anything good, especially considering we are an open-source  
> library.  
>  
> Case in question, I'm moving to updating the spatial module and want to  
> fetch dependencies from nuget. While spatial4n is signed (so it can be used  
> from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any  
> time soon. Since signed assemblies cannot reference non-strongly-named  
> assemblies, I can't currently do that - not through nuget at least. This  
> introduces a lot of frustration and tons of fraction which I'd like to have  
> removed.  
>  
> Ideally I'd want to move to removing strong-naming from all Lucene.NET  
> assemblies (v4 and forward), and having a wiki page that describes why  
> signing is pointless and how to manually sign it if you insist.  
>  
> I can see 2 disadvantages for not signing, both of which I doubt really  
> matter nowadays and given our usage scenarios:  
>  
> 1. Deploy Lucene.NET to the GAC without further steps (non-signed  
> assemblies can be SN or ILMerged as part of the install process)  
>  
> 2. Signed assemblies / project won't be able to get Lucene.NET from nuget  
> directly because they'll have to sign it before referencing it. Or lose SN  
> themselves.  
>  
> Thoughts?  
>  
> --  
>  
> Itamar Syn-Hershko  
> http://code972.com | @synhershko <https://twitter.com/synhershko>  
> Freelance Developer & Consultant  
> Author of RavenDB in Action <http://manning.com/synhershko/>  
>  

Re: Removing signing of assemblies (starting in v4)

[Petar Repac <pe...@gmail.com>]

There is a long discussion about SN here:
https://nuget.codeplex.com/discussions/247827

I'd suggest that even if decision is not to sign, there should be an easy
way to get signed assemblies.

Like:
1. clone repo (signing keys are publicly accessible in repository)
2. run BuildSigned.bat (or PowerShell script, Rake, ....)
3. c/p files from /build folder

I stopped signing my assemblies long ago, but probably there still are many
that still do
and less obstacles in adopting Lucene.NET the better.

Regards,
Petar Repac






On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <it...@code972.com>wrote:

> All Lucene.NET assemblies are signed, aka strongly named.
>
> We are starting to run into problems with dependencies which not being
> signed. What's becoming more common in the .NET world (OSS mainly) is to
> stop signing assemblies because its
> pretty<
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> >
> much<
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> >
> useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> last link: What Strong Names Can't Do).
>
> Regardless of the argument about SN it seems to bring more fraction and
> trouble than anything good, especially considering we are an open-source
> library.
>
> Case in question, I'm moving to updating the spatial module and want to
> fetch dependencies from nuget. While spatial4n is signed (so it can be used
> from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> time soon. Since signed assemblies cannot reference non-strongly-named
> assemblies, I can't currently do that - not through nuget at least. This
> introduces a lot of frustration and tons of fraction which I'd like to have
> removed.
>
> Ideally I'd want to move to removing strong-naming from all Lucene.NET
> assemblies (v4 and forward), and having a wiki page that describes why
> signing is pointless and how to manually sign it if you insist.
>
> I can see 2 disadvantages for not signing, both of which I doubt really
> matter nowadays and given our usage scenarios:
>
> 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> assemblies can be SN or ILMerged as part of the install process)
>
> 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> directly because they'll have to sign it before referencing it. Or lose SN
> themselves.
>
> Thoughts?
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>

Re: Removing signing of assemblies (starting in v4)

[Petar Repac <pe...@gmail.com>]

There is a long discussion about SN here:
https://nuget.codeplex.com/discussions/247827

I'd suggest that even if decision is not to sign, there should be an easy
way to get signed assemblies.

Like:
1. clone repo (signing keys are publicly accessible in repository)
2. run BuildSigned.bat (or PowerShell script, Rake, ....)
3. c/p files from /build folder

I stopped signing my assemblies long ago, but probably there still are many
that still do
and less obstacles in adopting Lucene.NET the better.

Regards,
Petar Repac






On Wed, Apr 23, 2014 at 1:10 PM, Itamar Syn-Hershko <it...@code972.com>wrote:

> All Lucene.NET assemblies are signed, aka strongly named.
>
> We are starting to run into problems with dependencies which not being
> signed. What's becoming more common in the .NET world (OSS mainly) is to
> stop signing assemblies because its
> pretty<
> http://stackoverflow.com/questions/20105103/are-signed-net-assemblies-ever-fully-verified-when-loaded-to-check-they-haven
> >
> much<
> http://stackoverflow.com/questions/1197133/anything-wrong-with-not-signing-a-net-assembly
> >
> useless <http://msdn.microsoft.com/en-us/magazine/cc163583.aspx> (in the
> last link: What Strong Names Can't Do).
>
> Regardless of the argument about SN it seems to bring more fraction and
> trouble than anything good, especially considering we are an open-source
> library.
>
> Case in question, I'm moving to updating the spatial module and want to
> fetch dependencies from nuget. While spatial4n is signed (so it can be used
> from Lucene.NET), NTS+GeoAPI are not and don't appear to get signed any
> time soon. Since signed assemblies cannot reference non-strongly-named
> assemblies, I can't currently do that - not through nuget at least. This
> introduces a lot of frustration and tons of fraction which I'd like to have
> removed.
>
> Ideally I'd want to move to removing strong-naming from all Lucene.NET
> assemblies (v4 and forward), and having a wiki page that describes why
> signing is pointless and how to manually sign it if you insist.
>
> I can see 2 disadvantages for not signing, both of which I doubt really
> matter nowadays and given our usage scenarios:
>
> 1. Deploy Lucene.NET to the GAC without further steps (non-signed
> assemblies can be SN or ILMerged as part of the install process)
>
> 2. Signed assemblies / project won't be able to get Lucene.NET from nuget
> directly because they'll have to sign it before referencing it. Or lose SN
> themselves.
>
> Thoughts?
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko>
> Freelance Developer & Consultant
> Author of RavenDB in Action <http://manning.com/synhershko/>
>