Signing nightmares

[Paul Cowan]

Hi,

The recent upgrade of NHibernate 2.1 has brought a mega headache situation to the surface.

It seems most of the projects build by default as signed assemblies.  For example fluentnhibernate references the keyfile fluent.snk.

Nhibernate.search builds unsigned from what I can gather and will not build signed that is if you reference a generated keyfile, you get the error:

 Referenced assembly 'Lucene.Net' does not have a strong name

This means projects like castle.activerecord that have nhibernate.search as a dependency will not build as you get the horrendous error referenced assembly nhibernate.search does not have a strong name:

Quite a few projects use caslte.activerecord so it is quite important that this builds.

Has anyone any idea what to do here as I am totally out of ideas?

This is complete madness.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

[Dru Sellers]

welcome to the pain that is strong names, right. :(

we have added a switch to masstransit that turns SN on and off from a build perspective.

i wonder if we could work with other projects to get them to add something similar.
is that the pain?

-d

[Paul Cowan]

It is just the usual inconsistencies across projects.

Some project have a -D:sign= parameter but nhibernate.search does not.

To make things laughable, nhibernate.search builds unisigned and nhibernate.validator builds signed due to their values in the nant <csc> task.

It is hugely frustrating and I am starting to doubt the effort in this.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

2009/11/3 Dru Sellers <d...@drusellers.com>

[Dru Sellers]

This is where we/you ;) as the super-horn-dude get on the bat phone with some of the teams and start to establish a standard way of doing things. no one is asking us too, and there isn't currently any benefit. come up with a standard for each different build engine (and a way to encode that in the code) and start asking us to do it with the promise of horn awesomeness!

:)

-d

[Dru Sellers]

I would certainly respond to such requests.
-d

[Paul Cowan]

I think alchemy is easier than this or more probable.

[Paul Cowan]

I found this horrible hack on the web:

Solution of the assigning the strong name to the third part DLL by using following command on visual studio command prompt.

E.g. Lets say the name of the third party DLL is myTest.dll.
Step 1: Dis-assemble the assembly
        ildasm myTest.dll /out:myTest.il

Step 2: Re-Assemble using your strong-name key
        ilasm myTest.il /res:myTest.res /dll /key:myTest.snk /out:myTestSN.dll

This code work perfectly to assign strong name.

for verification you can use following command,
sn -vf myTestSN.dll

I was able to patch the lucene.net into the build and nhibernate.search and more importantly castle.activerecord build now.

This is a short term and horrible hack.  If anyone fancies mentioning the signing capability to nhibernate then I would be grateful.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

2009/11/3 Paul Cowan <dag...@scotalt.net>

[Markus Zywitza]

For the AR release, I have compiled NHSearch myself with the Castle
key. However, signing separately after compiling is a better option
for horn, since it can be assigned to any project that requires a
strong name.

-Markus

[Paul Cowan]

With horn it is practically impossible to get a build without everything being singed.

The thing is, who actually keeps anything in the GAC?

I never do.  Should not being signed be the default stance?

2009/11/4 Markus Zywitza <markus....@gmail.com>

--

[Dru Sellers]

its not so much that there should be a default attitude but that there should be a clear way to turn it on and off

-d

[Paul Cowan]

>> there should be a default attitude but that there should be a clear way to turn it on and off

There should be but there is not :-).

Having to disassemble an assembly to get a proper build is not what I call a productive way to spend your time.

2009/11/4 Dru Sellers <d...@drusellers.com>

[Sebastien Lambla]

Wouldn't it be a good idea, in general, to support defaults and lobby the OSS community to adopt the same for the switches that can be used to compile *any* project?
 
I'd be happy standardizing these on OpenRasta!
 
Things that come to mind that are important:
- Strong name signing
- Authenticode signing
- Build either dlls or dlls and installers
- destination platform (AnyCPU / x86 / x64)
- destination framework profile (Silverlight / net 2, 3, 3.5 or 4)
- PDB generation
- Debug mode
- Output folder of output
 
THat's not even considering the inputs of the compilation project, but starting with the outputs may well help sooth a lot of the problems that have been encountered, do you not think?
 
Seb

 

---

Date: Tue, 3 Nov 2009 13:53:46 -0500
Subject: [horn-development] Re: Signing nightmares
From: d...@drusellers.com
To: horn-dev...@googlegroups.com

[Paul Cowan]

>> Wouldn't it be a good idea, in general, to support defaults and lobby the OSS community to adopt the same for the switches that can be used to compile *any* project?

I think it is an amazing idea but I have grown cynical after my horn experiences.  It generally falls on deaf ears or I get a very curt response.  I even mentioned the now infamous lucene.dll on the nhcontib mailing list but as usual it was not perceived as their problem.

That said, I really like the list of things you mention and I would also see something like a central pool of shared libraries.  If everyone referenced the same boo, lucen.net etc. then life would really be easier.  This could and should be automated through the team city build.  

Looking at a yellow screen with "Cannot find boo.extensions version 2.9.32948230984293402" is heart breaking when all you can find in your lib folder is boo.extensions version 2..29342340824083240283402384.  I have started to hack the horn descriptors so they are all referencing the same boo files but this a horrible, horrendous hack.

I think the question is HOW can we get OSS to take notice of this list of reasonable demands.

The whole thing is chaos.  Which is why horn was started.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

2009/11/7 Sebastien Lambla <s...@serialseb.com>

[Dru Sellers]

amen seb!

-d

[Kevin Amerson]

Horn has to reach a certain tipping point whereby project owners are compelled to get their projects listed on hornget.net.  From that angle, be creative with incentives, what can hornget offer the project owners?  Maybe Horn already offers plenty and it is just a marketing / growth / time to adopt issue.

One thing that would help is to just establish and publish the standards desired.  Code Horn to work BEAUTIFULLY if the project follows those standards.  If not then it may or may not compile that project.

It could take a long time to reach that tipping point, the growth so far is awesome!  I think you're all doing a fantastic job!

Cool ideas to help with adoption (since I never suggest a gap without providing some filler):

Horn could establish three parts of the site.  Green projects building and complying with the established standards, Yellow projects that have been breaking, and Red projects that will soon be de-listed.  This way if any user of the Red project is using Horn they may be compelled to contact project owners, or post in mailing lists to draw attention to the project's lack of Horn integration.

Host each build in a Git repository, and alongside straight downloads give the Git url to the build so that people can update the binaries of their favorite projects instead of download, it is also a nice draw to programmers.  Cater to your audience.

Create a profile section of the site, so that a project user/owner can go to the site, log in using OpenID or some cool OAuth technique and mark projects as favorites, then give a custom page with download links or Git links to my favorite projects. Let me setup alerts so that if a project fails to build, I get an email.

Provide Web Hooks to integrate with other sites seamlessly

Kevin

[Sebastien Lambla]

I hear you my friend.
 
There is a chicken and egg problem here.
 
I believe the approach to get leverage would be to provide all those properties to runners by default. If people start seeing they're already there, they can start detecting those and update their build accordingly.
 
If we do this, then other communities can implement it over time. If they don't, at least the projects that use it will build more reliably.
 
Seb
 

---

Date: Sat, 7 Nov 2009 12:47:50 +0000

Subject: [horn-development] Re: Signing nightmares

From: dag...@scotalt.net
To: horn-dev...@googlegroups.com

[Dru Sellers]

mikey likes.

-d