Deploying Assemblies to the GAC

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Brian R. - 20 Dec 2004 22:27 GMT

I examined the GAC on my machine and noticed that assemblies that are not
native images always show a codebase entry in their properties display. If I
use gacutil to install my assembly into the GAC, do I still need to have it
sitting around on disk? Is the act of putting the assembly into the GAC (via
gacutil /i) essentially copying the assembly contents (IL/Metadata) into the
GAC area?

I noticed that all GAC'd assemblies (excluding native images) have a
codebase path. Does this mean that they exist in two places on the machine?
Development references in VS.NET ref the GAC file, so what is the need of the
codebased entry?

THANKS!!

Signature

Brian R.

Reply to this Message

"Peter Huang" [MSFT] - 21 Dec 2004 07:13 GMT

Hi

Yes, except the one copy in the GAC, we still need another copy in the disk
for develop purpose.
When we compiled our project, e.g.it is a window forms application it will
need the system.windows.forms.dll, when we compiled the project, the IDE
will refer to the D:\windows\Microsoft.NET\Framework\<version>\

You may make a test, if you move the system.windows.forms.dll to another
path, the IDE can not compile the project again.

I think the codebase is for information usage, it just tell us where did we
install it into GAC.

If you still have any concern, please feel free to post here.

Best regards,

Perter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Brian R. - 21 Dec 2004 19:25 GMT

Thanks for your reply. I did read that the copy was for dev purposes in a
book, but the reason I ask is because the VS environment is not consistent.

When I GAC my assembly and then add a reference to it in a dev C# project,
the properties for that reference point back to the GAC path, not the
location where I GAC'd it from. There is a codebase path in the GAC
properties, but it doesn't reference my development one?

It does note the non GAC version of the MS 'System' assembly references
though? Is it hard coded into the VS environment to look for System
assemblies in a non GAC location?

What I am getting at is that it looks like I could easily deploy to teh GAC
and delete the files from disk because VS references teh GAC located file,
not the disk one.

> Hi
>
[quoted text clipped - 19 lines]
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

"Peter Huang" [MSFT] - 22 Dec 2004 04:44 GMT

Hi

I will research the issue and get you a reply ASAP.
Thanks for your understanding!

Best regards,

Perter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

"Peter Huang" [MSFT] - 23 Dec 2004 02:22 GMT

Hi

The copies outside the GAC are technically unnecessary. The theory is that
compilers use them from there so that users are not required to point to
files inside the GAC, by path. Basically the if you do not need to
reference the assembly, we do not need the other copy, the copy in the GAC
is enough.

Best regards,

Perter Huang
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

David Levine - 22 Dec 2004 11:56 GMT

In general, once an assembly is added to the GAC it does not need to keep
any other copies around in the local file system. For many assemblies this
folder is at %Windir%\assembly\GAC\<assemblyName>\<Version_PublicKey>, where
<assemblyName> is the simple display name, and <Version_PublicKey> is a
combination of the version and public key token of the strong name. The
original location of the assembly is no longer used, and those files should
be able to be deleted after it has been installed. You should be able to
delete the local files after adding it to the GAC to prove this. Also, many
assemblies in the GAC do not even have a codebase set.

The codebase may point to where the file was originally located before
installation, but this is not necessarily where the fusion layer looks when
resolving a reference to the GAC. If you examine the location property this
should show the actual path where the assembly is located in the GAC.

> Thanks for your reply. I did read that the copy was for dev purposes in a
> book, but the reason I ask is because the VS environment is not
[quoted text clipped - 41 lines]
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.

Reply to this Message

Brian R. - 22 Dec 2004 16:51 GMT

On my machine the only assemblies that do not have a GAC properties
'codebase' entry are the NGen'd native assemblies. All other 'IL/JIT-able'
assemblies contain a codebase.

I figured the disk copy was not needed once it was GAC'd, I just wanted to
clear up the difference between the way VS.NET references System vs Non
system GAC'd assemblies. Curious why MS ones are processed differently as
far as the link to the location on disk.

> In general, once an assembly is added to the GAC it does not need to keep
> any other copies around in the local file system. For many assemblies this
[quoted text clipped - 56 lines]
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.

Reply to this Message

David Levine - 22 Dec 2004 19:05 GMT

The answers to your questions are scattered around at MSDN and at these
sites:

http://weblogs.asp.net/suzcook
http://weblogs.asp.net/junfeng/
http://weblogs.asp.net/alanshi

I know I've read about this but I don't remember exactly where.

> On my machine the only assemblies that do not have a GAC properties
> 'codebase' entry are the NGen'd native assemblies. All other
[quoted text clipped - 78 lines]
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.

Reply to this Message

Ravichandran J.V. - 23 Dec 2004 07:47 GMT

<codeBase> is part of the .Net probing schema where the CLR first looks
into the BIN folder then the GAC and finally, if the assembly is not
found, downloads the assembly from the url mentioned in the codebase.

with regards,

J.V.Ravichandran

Signature

- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

Reply to this Message

David Levine - 23 Dec 2004 11:09 GMT

That is not correct. There is nothing in the CLR that hardcodes it to look
into a BIN directory, and it does not look there first. The BIN directory is
an artifact of running under IIS (and perhaps other web hosts) - binaries
are looked for in this directory only because the hosting process explicitly
added this subdirectory to the list of private bin paths to be probed. You
can verify this by looking at the properties of the appdomain the web
service is running in - you will find "BIN" as the value of the
PrivateBinPath property.

> <codeBase> is part of the .Net probing schema where the CLR first looks
> into the BIN folder then the GAC and finally, if the assembly is not
[quoted text clipped - 17 lines]
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!

Reply to this Message

Deploying Assemblies to the GAC

Free Magazines