So, about that gac....

[Dave Newman]

Hey dudes,

I'm just wondering if it would be a good idea to use the gac to manage dependencies. For example, if NHibernate 2.1 depends on DynamicProxy 2.0 and my app uses NHibernate 2.1 and DynamicProxy 2.2 am I right in assuming that horn would pull the nhibernate source and compile it against DynamicProxy 2.2?

If horn just pulled the dll's in and whacked them in the gac, I could reference nhib in the gac and it could ref DP 2.0 in the gac. My application would reference DynamicProxy 2.2 and everyone would be happy right?

Actually I think I'm missing something...

I'm envisioning a scenario where I add a new project to studio, click "Add Reference With Horn" and I get a window that shows me all the available OSS libraries that can be auto referenced. So I click ORM/NHibernate, select 2.1 and upon realising I don't have this locally in my gac, it pulls the dependency down, gacinstalls it and adds the reference in one foul swoop.

Actually that could work with Horn as it is today, just not sure why we need to build from source.

Cheers,

Dave Newman | @whatupdave | http://snappyco.de

[Simone Busoli]

The first of several issues with this approach I see is that in hosting scenarios the GAC is usually not an option.

--
You received this message because you are subscribed to the Google Groups "HORN Development" group.
To post to this group, send email to horn-dev...@googlegroups.com.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/horn-development?hl=en.

[Sebastien Lambla]

The GAC is *evil*.
 
That is all.
 

---

From: simone...@gmail.com
Date: Wed, 27 Jan 2010 07:57:53 +0100
Subject: Re: [horn-development] So, about that gac....
To: horn-dev...@googlegroups.com

---

We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

[David Lawton]

+1 with seb. GAC is not your friend, stick the dlls in a lib folder and reference them.

GAC causes nothing but headaches

Ninja

2010/1/27 Sebastien Lambla <s...@serialseb.com>

--
"I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage

[Paul Cowan]

I used the GAC once during .NET 1.0 to interop with COM+.

A most regrettable experience.

One reason is that all your projects would need to be working off the same version of nhibernate example.

It would not be possible to have 1 project using the trunk of nhibernate and another using 2.1.x.

The GAC is best avoided IMO.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

2010/1/27 David Lawton <da...@davetheninja.net>

[Sebastien Lambla]

Side-by-side versioning is not so much of an issue. It's the fact that binding happens in the GAC first, and if the GAC responds, you're screwed.
 
For OpenWrap I have a check at the start of the system, and if an assembly you requested in one of your packages is already without OpenWrap knowing about it, I refuse to start the application with a big fat error message.
 
And being in the GAC requires being strongly-signed. When you strongly sign, fusion refuses to bind to any new version of an assembly without you explicitly asking for it with a publisher publicy, which has to be in the GAC too.
 
And most open-source projects are eighter unsigned, or don't respect the versioning rules at all (updating AssemblyVersion instead of AssemblyFileVersion).
 
Overall, a big mess to stay well away from.
 
 
Seb

---

Date: Wed, 27 Jan 2010 14:29:30 +0000

Subject: Re: [horn-development] So, about that gac....

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

[Dave Newman]

Thanks for the quick answers guys, I think package management ala horn is the biggest unsolved problem in .net right now. I can definitely see the problems you're outlining here with the gac. It looks like it's biggest advantage is the ability for me to reference log4net 2.2 and nhib 2.1 which references log4net 2.0. With the current approach horn would need to rebuild nhib 2.1 with log4net 2.2 right?

I'm just thinking that if I release a library and I do all my testing on log4net 2.0 and someone recompiles it to reference log4net 2.2 that might break things. But I guess the only options for the dev using my library are referencing 2 different versions of log4net in the gac, or recompiling all your dependencies to reference the same version right?

Thanks, Dave

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[Paul Cowan]

I have often wondered if ILMerge is not something we could utilise more.

The only way I have ever been able to resolve references is to rebuild your stack by building from the source.

I honestly cannot see any other way round the mayhem that exists.

I have recently started thinking that having a stack (like I do) with so many dependencies is bad practice as it is difficult to maintain.

The next new .NET project I do, I am really going to make a point of having a stack that does not depend too much on each other.

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

2010/1/27 Dave Newman <ddang...@gmail.com>

[Dave Newman]

Maybe there needs to be a way of specifying "internal" vs "external" dependencies. All internal dependencies get ILMerged and marked as internal so that the types don't bleed out of the library. External dependencies are not ILMerged and must be the same version if shared between libraries or the app itself.

Example: I have a testing library called Shouldly which currently depends on NUnit 2.5.1 and Rhino 3.6

Both Rhino and NUnit will be used directly by Shouldly consumers and so will be external dependencies. Any consumer must reference the same versions of NUnit and Rhino as Shouldly does (which may require recompiling shouldly)

Now I want to use ManagedStackExplorer 1.0

Noone outside my library needs to be exposed so I'd mark that as an internal dependency and it would be ILMerged into my library and marked as internal.

Consumers of Shouldly could reference ManagedStackExplorer 1.5 fine without namespace collisions.

So would "internal" and "external" dependencies be a good idea for horn to manage?

[Paul Cowan]

I think you would need to do some testing to see if it worked first

On Feb 10, 2010 1:01 AM, "Dave Newman" <ddang...@gmail.com> wrote:

Maybe there needs to be a way of specifying "internal" vs "external" dependencies. All internal dependencies get ILMerged and marked as internal so that the types don't bleed out of the library. External dependencies are not ILMerged and must be the same version if shared between libraries or the app itself.

Example: I have a testing library called Shouldly which currently depends on NUnit 2.5.1 and Rhino 3.6

Both Rhino and NUnit will be used directly by Shouldly consumers and so will be external dependencies. Any consumer must reference the same versions of NUnit and Rhino as Shouldly does (which may require recompiling shouldly)

Now I want to use ManagedStackExplorer 1.0

Noone outside my library needs to be exposed so I'd mark that as an internal dependency and it would be ILMerged into my library and marked as internal.

Consumers of Shouldly could reference ManagedStackExplorer 1.5 fine without namespace collisions.

So would "internal" and "external" dependencies be a good idea for horn to manage?

On Thu, Jan 28, 2010 at 10:10 AM, Paul Cowan <dag...@scotalt.net> wrote: > > I have often wondered...