What's the point of the GAC?

[Lecture Snoddddgrass]

I know this is a very newbie thing to ask, but...

What's the point of the Global Assembly Cache? It reminds me of the
c:\winnt\system32 directory from my C++ days... just a big confusing jumble
of shared DLLs. This made sense in the "old days" because hard disk space
was more expensive so people didn't want redundant DLLs all over the
place... But what's the point of such a repository in the .NET world?

Thanks,

Michael Jackson

[Jon Skeet [C# MVP]]

Lecture Snoddddgrass <ma***@hamburg.fry> wrote:

I know this is a very newbie thing to ask, but...

What's the point of the Global Assembly Cache? It reminds me of the
c:\winnt\system32 directory from my C++ days... just a big confusing jumble
of shared DLLs. This made sense in the "old days" because hard disk space
was more expensive so people didn't want redundant DLLs all over the
place... But what's the point of such a repository in the .NET world?

The difference is that assemblies in the GAC are versioned. While it
makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.
Instead, you just have the GAC with versioned assemblies, so you (in
theory) get around a lot of DLL hell without every app being huge.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Lecture Snoddddgrass]

> The difference is that assemblies in the GAC are versioned. While it

makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.

True, but mscorlib.dll and System.dll are .NET runtime DLLs -- part of
the platform itself. I can see why the GAC would be useful for framework
DLLs... but why would I as a developer want to any of *my* app's DLLs in the
user's GAC?

David

[Klaus H. Probst]

You wouldn't, unless you're building infrastructure-level components used by
more than one application on the box.
--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/

"Lecture Snoddddgrass" <ma***@hamburg.fry> wrote in message
news:ew**************@TK2MSFTNGP10.phx.gbl...

The difference is that assemblies in the GAC are versioned. While it
makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.
True, but mscorlib.dll and System.dll are .NET runtime DLLs -- part of
the platform itself. I can see why the GAC would be useful for framework
DLLs... but why would I as a developer want to any of *my* app's DLLs in

the user's GAC?

David

[Klaus H. Probst]

You wouldn't, unless you're building infrastructure-level components used by
more than one application on the box.
--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/

"Lecture Snoddddgrass" <ma***@hamburg.fry> wrote in message
news:ew**************@TK2MSFTNGP10.phx.gbl...

The difference is that assemblies in the GAC are versioned. While it
makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.
True, but mscorlib.dll and System.dll are .NET runtime DLLs -- part of
the platform itself. I can see why the GAC would be useful for framework
DLLs... but why would I as a developer want to any of *my* app's DLLs in

the user's GAC?

David

[Jon Skeet [C# MVP]]

Lecture Snoddddgrass <ma***@hamburg.fry> wrote:

The difference is that assemblies in the GAC are versioned. While it
makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.

True, but mscorlib.dll and System.dll are .NET runtime DLLs -- part of
the platform itself. I can see why the GAC would be useful for framework
DLLs... but why would I as a developer want to any of *my* app's DLLs in the
user's GAC?

For a normal app, you wouldn't want any of *your* code in the GAC. If
you were writing component libraries, however, you might - and as an
application writer, you might want to use other DLLs which are in the
GAC. (For instance, you could have an installer which checked which of
the libraries you needed were already installed, and only downloaded
the ones which weren't already on the user's system.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Lecture Snoddddgrass <ma***@hamburg.fry> wrote:

The difference is that assemblies in the GAC are versioned. While it
makes sense for two different applications to want to use two different
versions of the same assembly, there's no point in every application
carrying its own version of mscorlib.dll, System.dll etc around.

True, but mscorlib.dll and System.dll are .NET runtime DLLs -- part of
the platform itself. I can see why the GAC would be useful for framework
DLLs... but why would I as a developer want to any of *my* app's DLLs in the
user's GAC?

For a normal app, you wouldn't want any of *your* code in the GAC. If
you were writing component libraries, however, you might - and as an
application writer, you might want to use other DLLs which are in the
GAC. (For instance, you could have an installer which checked which of
the libraries you needed were already installed, and only downloaded
the ones which weren't already on the user's system.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too