Ok, Im confused, someone please clear things up for me. I know this may seem
like a stupid question.

I built a DLL that is to be used by all of our applications to perform
routine tasks. When the discussion came up about weather or not to store this
DLL in the GAC or in the individual projects, I had suggested the GAC. My
thought was that IF an update needs to take place, we wouldn’t have to update
the bin folder of every application. Instead we would simply uninstall the
old assembly from the GAC and install the newer version.

Now Im finding out that you cant reference the GAC, that you still would
need to have the DLL in a local directory and set the do not copy local
option. This would only work assuming that you development server drive
letters and paths match the production server

This to me defeats the purpose and maybe I don’t understand. If I cant
reference the GAC then, it means I would need to rebuild the project on the
Production server as well as the Development server because (in our case),
the driver letters and folder paths don’t match. So what may exist in C:\My
Assembles on our development box surely wont exist on the production box
unless I’m allow to create the path on the production box. Unfortunately our
production sites do not go to the C: drive. What’s the purpose of the GAC if
you cant reference it and still required to reference a copy of the DLL
outside the GAC

"MR E" <(E-Mail Removed)> wrote in message
news:A6E35C97-7294-45DD-BCEE-(E-Mail Removed)...
> Ok, Im confused, someone please clear things up for me. I know this may
> seem
> like a stupid question.
>
> I built a DLL that is to be used by all of our applications to perform
> routine tasks. When the discussion came up about weather or not to store
> this
> DLL in the GAC or in the individual projects, I had suggested the GAC. My
> thought was that IF an update needs to take place, we wouldn’t have to
> update
> the bin folder of every application. Instead we would simply uninstall the
> old assembly from the GAC and install the newer version.
>
> Now Im finding out that you cant reference the GAC, that you still would
> need to have the DLL in a local directory and set the do not copy local
> option. This would only work assuming that you development server drive
> letters and paths match the production server
>
> This to me defeats the purpose and maybe I don’t understand. If I cant
> reference the GAC then, it means I would need to rebuild the project on
> the
> Production server as well as the Development server because (in our case),
> the driver letters and folder paths don’t match. So what may exist in
> C:\My
> Assembles on our development box surely wont exist on the production box
> unless I’m allow to create the path on the production box. Unfortunately
> our
> production sites do not go to the C: drive. What’s the purpose of the GAC
> if
> you cant reference it and still required to reference a copy of the DLL
> outside the GAC
>

MR E,

You should be able to reference the GAC. I'm not quite sure what the
problem is on your end that prevents you from referencing the items from the
GAC. If what I think your problem is is accurate, and correct me if I'm
wrong, you think that since on your developer machine, you can't load and
reference the assemblies in the GAC because they are not listed in the .Net
components, and you still have to reference them from your installation
folders, then you are partially correct. Hmm, I don't think I can explain
it perfectly so lets see if I can get some links for you...

Code Project Link:
http://www.codeproject.com/KB/dotnet/demystifygac.aspx
(for more specific explanation, read this code project document, specially
under Popular Misconceptions).


As a side note because I couldn't find a document on it, on your developers
machine, you need the assembly that is installed in the gac to be installed
elsewhere so you can reference it. At runtime, the .Net Framework
automatically refers to the GAC'ed assembly if installed. The framework
will attempt to locate the referenced assembly in the application's bin
folder, if not present it will look in the GAC (I believe that is the
order). There are other locations that the framework will look for the
assemblies as well, and those places are documented in the MSDN Library
documentation. So, what this means is, on the production and testing
servers, your application does not need the assembly to be in it's BIN
directory if it's installed in the GAC...but, the assembly reference on the
machine where the application was built must match (same assembly signature)
the assembly that is installed in the GAC on the servers.


Hope that makes sense...

HTH,
Mythran

Thanks for your help. I finally realized how it works just before reading
your response. I knew you could reference the GAC, but what I couldn’t get
was why the DLL didn’t show up in the Add Reference box after adding it to
the GAC and why in the world I still needed the physical outside of the GAC
to reference. It seems to me anything in the GAC should show up in the Add
Reference and no need for the physical file itself.

I added the folder to my Windows Registry Assembly list to get it to show
up. I also had our network team set it up so that all of our custom
assemblies are in one shared location accessible to all the programmers and
to the apps themselves. I know a lot of developers frown on using the GAC but
when u got dozens apps across multiple servers, using the GAC is still easier
then keeping up with individual copies in the bin folders.


"Mythran" wrote:

>
>
> "MR E" <(E-Mail Removed)> wrote in message
> news:A6E35C97-7294-45DD-BCEE-(E-Mail Removed)...
> > Ok, Im confused, someone please clear things up for me. I know this may
> > seem
> > like a stupid question.
> >
> > I built a DLL that is to be used by all of our applications to perform
> > routine tasks. When the discussion came up about weather or not to store
> > this
> > DLL in the GAC or in the individual projects, I had suggested the GAC. My
> > thought was that IF an update needs to take place, we wouldn’t have to
> > update
> > the bin folder of every application. Instead we would simply uninstall the
> > old assembly from the GAC and install the newer version.
> >
> > Now Im finding out that you cant reference the GAC, that you still would
> > need to have the DLL in a local directory and set the do not copy local
> > option. This would only work assuming that you development server drive
> > letters and paths match the production server
> >
> > This to me defeats the purpose and maybe I don’t understand. If I cant
> > reference the GAC then, it means I would need to rebuild the project on
> > the
> > Production server as well as the Development server because (in our case),
> > the driver letters and folder paths don’t match. So what may exist in
> > C:\My
> > Assembles on our development box surely wont exist on the production box
> > unless I’m allow to create the path on the production box. Unfortunately
> > our
> > production sites do not go to the C: drive. What’s the purpose of the GAC
> > if
> > you cant reference it and still required to reference a copy of the DLL
> > outside the GAC
> >
>
> MR E,
>
> You should be able to reference the GAC. I'm not quite sure what the
> problem is on your end that prevents you from referencing the items from the
> GAC. If what I think your problem is is accurate, and correct me if I'm
> wrong, you think that since on your developer machine, you can't load and
> reference the assemblies in the GAC because they are not listed in the .Net
> components, and you still have to reference them from your installation
> folders, then you are partially correct. Hmm, I don't think I can explain
> it perfectly so lets see if I can get some links for you...
>
> Code Project Link:
> http://www.codeproject.com/KB/dotnet/demystifygac.aspx
> (for more specific explanation, read this code project document, specially
> under Popular Misconceptions).
>
>
> As a side note because I couldn't find a document on it, on your developers
> machine, you need the assembly that is installed in the gac to be installed
> elsewhere so you can reference it. At runtime, the .Net Framework
> automatically refers to the GAC'ed assembly if installed. The framework
> will attempt to locate the referenced assembly in the application's bin
> folder, if not present it will look in the GAC (I believe that is the
> order). There are other locations that the framework will look for the
> assemblies as well, and those places are documented in the MSDN Library
> documentation. So, what this means is, on the production and testing
> servers, your application does not need the assembly to be in it's BIN
> directory if it's installed in the GAC...but, the assembly reference on the
> machine where the application was built must match (same assembly signature)
> the assembly that is installed in the GAC on the servers.
>
>
> Hope that makes sense...
>
> HTH,
> Mythran
>
>

Let me qualify my previous statement before I get jumped on by others in the
list LOL

I know a lot of developers frown on using the GAC ... (when its used for
custom developed assemblies)


"MR E" wrote:

> Thanks for your help. I finally realized how it works just before reading
> your response. I knew you could reference the GAC, but what I couldn’t get
> was why the DLL didn’t show up in the Add Reference box after adding it to
> the GAC and why in the world I still needed the physical outside of the GAC
> to reference. It seems to me anything in the GAC should show up in the Add
> Reference and no need for the physical file itself.
>
> I added the folder to my Windows Registry Assembly list to get it to show
> up. I also had our network team set it up so that all of our custom
> assemblies are in one shared location accessible to all the programmers and
> to the apps themselves. I know a lot of developers frown on using the GAC but
> when u got dozens apps across multiple servers, using the GAC is still easier
> then keeping up with individual copies in the bin folders.
>
>
> "Mythran" wrote:
>
> >
> >
> > "MR E" <(E-Mail Removed)> wrote in message
> > news:A6E35C97-7294-45DD-BCEE-(E-Mail Removed)...
> > > Ok, Im confused, someone please clear things up for me. I know this may
> > > seem
> > > like a stupid question.
> > >
> > > I built a DLL that is to be used by all of our applications to perform
> > > routine tasks. When the discussion came up about weather or not to store
> > > this
> > > DLL in the GAC or in the individual projects, I had suggested the GAC. My
> > > thought was that IF an update needs to take place, we wouldn’t have to
> > > update
> > > the bin folder of every application. Instead we would simply uninstall the
> > > old assembly from the GAC and install the newer version.
> > >
> > > Now Im finding out that you cant reference the GAC, that you still would
> > > need to have the DLL in a local directory and set the do not copy local
> > > option. This would only work assuming that you development server drive
> > > letters and paths match the production server
> > >
> > > This to me defeats the purpose and maybe I don’t understand. If I cant
> > > reference the GAC then, it means I would need to rebuild the project on
> > > the
> > > Production server as well as the Development server because (in our case),
> > > the driver letters and folder paths don’t match. So what may exist in
> > > C:\My
> > > Assembles on our development box surely wont exist on the production box
> > > unless I’m allow to create the path on the production box. Unfortunately
> > > our
> > > production sites do not go to the C: drive. What’s the purpose of the GAC
> > > if
> > > you cant reference it and still required to reference a copy of the DLL
> > > outside the GAC
> > >
> >
> > MR E,
> >
> > You should be able to reference the GAC. I'm not quite sure what the
> > problem is on your end that prevents you from referencing the items from the
> > GAC. If what I think your problem is is accurate, and correct me if I'm
> > wrong, you think that since on your developer machine, you can't load and
> > reference the assemblies in the GAC because they are not listed in the .Net
> > components, and you still have to reference them from your installation
> > folders, then you are partially correct. Hmm, I don't think I can explain
> > it perfectly so lets see if I can get some links for you...
> >
> > Code Project Link:
> > http://www.codeproject.com/KB/dotnet/demystifygac.aspx
> > (for more specific explanation, read this code project document, specially
> > under Popular Misconceptions).
> >
> >
> > As a side note because I couldn't find a document on it, on your developers
> > machine, you need the assembly that is installed in the gac to be installed
> > elsewhere so you can reference it. At runtime, the .Net Framework
> > automatically refers to the GAC'ed assembly if installed. The framework
> > will attempt to locate the referenced assembly in the application's bin
> > folder, if not present it will look in the GAC (I believe that is the
> > order). There are other locations that the framework will look for the
> > assemblies as well, and those places are documented in the MSDN Library
> > documentation. So, what this means is, on the production and testing
> > servers, your application does not need the assembly to be in it's BIN
> > directory if it's installed in the GAC...but, the assembly reference on the
> > machine where the application was built must match (same assembly signature)
> > the assembly that is installed in the GAC on the servers.
> >
> >
> > Hope that makes sense...
> >
> > HTH,
> > Mythran
> >
> >

A point I'll make here is that the GAC is really intended as a deployment
choice, not a repository for assemblies that you want to reference at
development time. So development tools generally don't refer to assemblies
in the GAC, they refer to SDK-installed assemblies.

For shared assemblies belonging to a company (non-Microsoft) the development
versions of assemblies are typically not the one deployed in production.
apps (usually because people are developing using later versions). In
addition, many shared assemblies are installed as part of a much larger
product install that developers typically don't want on the dev machine. I
wouldn't want to install my company's products on my dev box just so I could
reference assemblies from them that happen to be installed to the GAC.
--
Phil Wilson
Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972


"MR E" <(E-Mail Removed)> wrote in message
news:88EDD31D-BD72-4F6E-AF36-(E-Mail Removed)...
> Thanks for your help. I finally realized how it works just before reading
> your response. I knew you could reference the GAC, but what I couldn't get
> was why the DLL didn't show up in the Add Reference box after adding it to
> the GAC and why in the world I still needed the physical outside of the
> GAC
> to reference. It seems to me anything in the GAC should show up in the Add
> Reference and no need for the physical file itself.
>
> I added the folder to my Windows Registry Assembly list to get it to show
> up. I also had our network team set it up so that all of our custom
> assemblies are in one shared location accessible to all the programmers
> and
> to the apps themselves. I know a lot of developers frown on using the GAC
> but
> when u got dozens apps across multiple servers, using the GAC is still
> easier
> then keeping up with individual copies in the bin folders.
>
>
> "Mythran" wrote:
>
>>
>>
>> "MR E" <(E-Mail Removed)> wrote in message
>> news:A6E35C97-7294-45DD-BCEE-(E-Mail Removed)...
>> > Ok, Im confused, someone please clear things up for me. I know this may
>> > seem
>> > like a stupid question.
>> >
>> > I built a DLL that is to be used by all of our applications to perform
>> > routine tasks. When the discussion came up about weather or not to
>> > store
>> > this
>> > DLL in the GAC or in the individual projects, I had suggested the GAC.
>> > My
>> > thought was that IF an update needs to take place, we wouldn't have to
>> > update
>> > the bin folder of every application. Instead we would simply uninstall
>> > the
>> > old assembly from the GAC and install the newer version.
>> >
>> > Now Im finding out that you cant reference the GAC, that you still
>> > would
>> > need to have the DLL in a local directory and set the do not copy local
>> > option. This would only work assuming that you development server drive
>> > letters and paths match the production server
>> >
>> > This to me defeats the purpose and maybe I don't understand. If I cant
>> > reference the GAC then, it means I would need to rebuild the project on
>> > the
>> > Production server as well as the Development server because (in our
>> > case),
>> > the driver letters and folder paths don't match. So what may exist in
>> > C:\My
>> > Assembles on our development box surely wont exist on the production
>> > box
>> > unless I'm allow to create the path on the production box.
>> > Unfortunately
>> > our
>> > production sites do not go to the C: drive. What's the purpose of the
>> > GAC
>> > if
>> > you cant reference it and still required to reference a copy of the DLL
>> > outside the GAC
>> >
>>
>> MR E,
>>
>> You should be able to reference the GAC. I'm not quite sure what the
>> problem is on your end that prevents you from referencing the items from
>> the
>> GAC. If what I think your problem is is accurate, and correct me if I'm
>> wrong, you think that since on your developer machine, you can't load and
>> reference the assemblies in the GAC because they are not listed in the
>> .Net
>> components, and you still have to reference them from your installation
>> folders, then you are partially correct. Hmm, I don't think I can
>> explain
>> it perfectly so lets see if I can get some links for you...
>>
>> Code Project Link:
>> http://www.codeproject.com/KB/dotnet/demystifygac.aspx
>> (for more specific explanation, read this code project document,
>> specially
>> under Popular Misconceptions).
>>
>>
>> As a side note because I couldn't find a document on it, on your
>> developers
>> machine, you need the assembly that is installed in the gac to be
>> installed
>> elsewhere so you can reference it. At runtime, the .Net Framework
>> automatically refers to the GAC'ed assembly if installed. The framework
>> will attempt to locate the referenced assembly in the application's bin
>> folder, if not present it will look in the GAC (I believe that is the
>> order). There are other locations that the framework will look for the
>> assemblies as well, and those places are documented in the MSDN Library
>> documentation. So, what this means is, on the production and testing
>> servers, your application does not need the assembly to be in it's BIN
>> directory if it's installed in the GAC...but, the assembly reference on
>> the
>> machine where the application was built must match (same assembly
>> signature)
>> the assembly that is installed in the GAC on the servers.
>>
>>
>> Hope that makes sense...
>>
>> HTH,
>> Mythran
>>
>>

> I added the folder to my Windows Registry Assembly list to get it to show
> up
no no no, undo what you did. Gac assemblies show up under the reference tab.
If it doesn't show, it's because it isn't in there. You can verify that is
in there by using explorer to navigate to the windows\assembly folder. Or
you can unregister the gac'd assembly using gacutil -u (I think) and then
register it again. Look through you referenced assemblies for the name of
the assembly, it will be there.

>I also had our network team set it up so that all of our custom
> assemblies are in one shared location accessible to all the programmers
> and
> to the apps themselves.

Bad. That's an unnecessary security risk because it is probably a shared
drive. There's also a performance hit with reading assemblies from a shared
or mapped drive. Gac'd assemblies provide that function for you and the
search order for assemblies starts at the gac to reduce performance issues.
Your initial thoughts about using the GAC are correct, you need to follow
through and implement it properly.
--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?
http://msmvps.com/blogs/alvin/Default.aspx
-------------------------------------------------------


"MR E" <(E-Mail Removed)> wrote in message
news:88EDD31D-BD72-4F6E-AF36-(E-Mail Removed)...
> Thanks for your help. I finally realized how it works just before reading
> your response. I knew you could reference the GAC, but what I couldn’t get
> was why the DLL didn’t show up in the Add Reference box after adding it to
> the GAC and why in the world I still needed the physical outside of the
> GAC
> to reference. It seems to me anything in the GAC should show up in the Add
> Reference and no need for the physical file itself.
>
> I added the folder to my Windows Registry Assembly list to get it to show
> up. I also had our network team set it up so that all of our custom
> assemblies are in one shared location accessible to all the programmers
> and
> to the apps themselves. I know a lot of developers frown on using the GAC
> but
> when u got dozens apps across multiple servers, using the GAC is still
> easier
> then keeping up with individual copies in the bin folders.
>
>
> "Mythran" wrote:
>
>>
>>
>> "MR E" <(E-Mail Removed)> wrote in message
>> news:A6E35C97-7294-45DD-BCEE-(E-Mail Removed)...
>> > Ok, Im confused, someone please clear things up for me. I know this may
>> > seem
>> > like a stupid question.
>> >
>> > I built a DLL that is to be used by all of our applications to perform
>> > routine tasks. When the discussion came up about weather or not to
>> > store
>> > this
>> > DLL in the GAC or in the individual projects, I had suggested the GAC.
>> > My
>> > thought was that IF an update needs to take place, we wouldn’t have to
>> > update
>> > the bin folder of every application. Instead we would simply uninstall
>> > the
>> > old assembly from the GAC and install the newer version.
>> >
>> > Now Im finding out that you cant reference the GAC, that you still
>> > would
>> > need to have the DLL in a local directory and set the do not copy local
>> > option. This would only work assuming that you development server drive
>> > letters and paths match the production server
>> >
>> > This to me defeats the purpose and maybe I don’t understand. If I cant
>> > reference the GAC then, it means I would need to rebuild the project on
>> > the
>> > Production server as well as the Development server because (in our
>> > case),
>> > the driver letters and folder paths don’t match. So what may exist in
>> > C:\My
>> > Assembles on our development box surely wont exist on the production
>> > box
>> > unless I’m allow to create the path on the production box.
>> > Unfortunately
>> > our
>> > production sites do not go to the C: drive. What’s the purpose of the
>> > GAC
>> > if
>> > you cant reference it and still required to reference a copy of the DLL
>> > outside the GAC
>> >
>>
>> MR E,
>>
>> You should be able to reference the GAC. I'm not quite sure what the
>> problem is on your end that prevents you from referencing the items from
>> the
>> GAC. If what I think your problem is is accurate, and correct me if I'm
>> wrong, you think that since on your developer machine, you can't load and
>> reference the assemblies in the GAC because they are not listed in the
>> .Net
>> components, and you still have to reference them from your installation
>> folders, then you are partially correct. Hmm, I don't think I can
>> explain
>> it perfectly so lets see if I can get some links for you...
>>
>> Code Project Link:
>> http://www.codeproject.com/KB/dotnet/demystifygac.aspx
>> (for more specific explanation, read this code project document,
>> specially
>> under Popular Misconceptions).
>>
>>
>> As a side note because I couldn't find a document on it, on your
>> developers
>> machine, you need the assembly that is installed in the gac to be
>> installed
>> elsewhere so you can reference it. At runtime, the .Net Framework
>> automatically refers to the GAC'ed assembly if installed. The framework
>> will attempt to locate the referenced assembly in the application's bin
>> folder, if not present it will look in the GAC (I believe that is the
>> order). There are other locations that the framework will look for the
>> assemblies as well, and those places are documented in the MSDN Library
>> documentation. So, what this means is, on the production and testing
>> servers, your application does not need the assembly to be in it's BIN
>> directory if it's installed in the GAC...but, the assembly reference on
>> the
>> machine where the application was built must match (same assembly
>> signature)
>> the assembly that is installed in the GAC on the servers.
>>
>>
>> Hope that makes sense...
>>
>> HTH,
>> Mythran
>>
>>