[MonoDevelop] [PATCH] GAC references from real GAC

[Todd Berman]

On Sat, 2005-08-13 at 02:06 +0300, Mart Roosmaa wrote:
> On 13/08/05, Todd Berman <tberman at off.net> wrote:
> > Unfortunately, we *are* searching for globally installed assemblies
> > properly. People will just have to deal with it and add pc files and
> > whatnot in order for MonoDevelop users to be able to build against it.
> 
> This part I cannot understand, even if I try really hard. Can you
> please bring out the advantages of using GAC and .pc files together
> and naming it as "GAC References"?

Maybe the name is not perfect, but thats not what you patch changed.

> I'd understand if you wanted to use packages as references and would
> add another type of references. But why combine them?

Because the GAC is not a valid referencable target for compiling. It is
not how the compiler works. mcs does not load assemblies out of the GAC.
mcs loads assemblies via a path to a file (as does csc). This is to
provide completely repeatable builds.

> And as they are combined, how are you planning to implement 2.0
> support? (or let developers use any another version of some assembly
> in the GAC?)

We already do, look at gtk-sharp and gtk-sharp-2.0.

You can select either reference depending on your needs. This is because
gtk# 1.0 and 2.0 are properly installed mono libraries.

As far as supporting a 2.0 profile, that is immaterial to this
discussion, as the version of the runtime you are targetting depends on
the mscorlib you chose to reference. So if you are referencing a .NET
1.1 profile mscorlib, you have NO CHOICE but to reference .NET 1.1
profile System.Web, you *CAN NOT* chose the 2.0 System.Web. And
vice-versa. So yes, right now, you can't use MD to build an app against
the 2.0 profile, but that is not a design issue with the way we handle
"GAC" References.

> At the moment you are locking the user in to use one and only one
> version of some assembly (probably the latest then). And adding that
> extra .pc file on all computers (if using MD in some bigger project
> with many developers) decreases development time.
> 

No, not at all.

In fact, there is exactly 0 decrease in developer time, just a general
increase in developer awareness.

If I am working with a team of developers, and we are going to use some
random version of some random library, like, for example, Mono.Cecil.
Instead of putting that assembly into the GAC, we include a private copy
of the assembly, and link against it via the Assemblies tab, not the GAC
tab.

The GAC tab is for referencing *properly* installed libraries. Some
library you just gacutil -i'd is *NOT* properly installed.

> In short: I would just like a better description of why is GAC and .pc
> combined is better than GAC and .pc separately?
> 

We will never support loading assemblies directly out of the GAC,
because it is a thin veneer over a developer awareness issue. By making
it 'easy' for developers to gacutil -i MyRandomCoolThing.dll we start
adding a lot of issues including:

Requiring MyRandomCoolThing.dll to be strong named. The issue this
causes, is now that dll needs to be properly API compat. So when
MyRandomCoolThing gets another cool feature, the API version needs to
change, and then the strong name changes. This means that your
developers and users need a new version of MyRandomCoolThing.dll. That
is what decreases developer time.

However, if you just include a private copy of MyRandomCoolThing.dll,
there are no API versioning promises, and therefor absolutely no issues.

Is this explanation clear enough, or is there anything that needs more
explaining?

--Todd