| Groups | Blog | Home |
dotnet sdk : Deploying Assemblies to the GAC
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!! -- Brian R.
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 Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
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. [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> 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 > > Get Secure! - www.microsoft.com/security > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi
I will research the issue and get you a reply ASAP. Thanks for your understanding! Best regards, Perter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
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. [quoted text, click to view] "Brian R." <8B2H4R_N9G5M3S7@noemail.nospam> wrote in message news:B46A448A-4D8F-4EFF-9054-F2224A5B9E4C@microsoft.com... > 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. > > ""Peter Huang" [MSFT]" wrote: > >> 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 >> >> Get Secure! - www.microsoft.com/security >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >>
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. [quoted text, click to view] "David Levine" wrote:
> 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. > > > > "Brian R." <8B2H4R_N9G5M3S7@noemail.nospam> wrote in message > news:B46A448A-4D8F-4EFF-9054-F2224A5B9E4C@microsoft.com... > > 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. > > > > ""Peter Huang" [MSFT]" wrote: > > > >> 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 > >> > >> Get Secure! - www.microsoft.com/security > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >
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. [quoted text, click to view] "Brian R." <8B2H4R_N9G5M3S7@noemail.nospam> wrote in message news:8CD1AC31-B03B-4CBD-8989-08024F7FE61D@microsoft.com... > 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. > > "David Levine" wrote: > >> 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. >> >> >> >> "Brian R." <8B2H4R_N9G5M3S7@noemail.nospam> wrote in message >> news:B46A448A-4D8F-4EFF-9054-F2224A5B9E4C@microsoft.com... >> > 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. >> > >> > ""Peter Huang" [MSFT]" wrote: >> > >> >> 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 >> >> >> >> Get Secure! - www.microsoft.com/security >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> >> >> >> >> >>
<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 - 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 *** Sent via Developersdex http://www.developersdex.com ***
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 Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
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. [quoted text, click to view] "Ravichandran J.V." <jvravichandran@yahoo.com> wrote in message news:%2368znOM6EHA.1300@TK2MSFTNGP14.phx.gbl... > <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 > - 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 > > *** Sent via Developersdex http://www.developersdex.com *** > Don't just participate in USENET...get rewarded for it!
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |