|
|
You're in the
dotnet clr
group:Use GAC or not?
dotnet clr:
You have to be sure that you want to share your component across the machine if you are going to add it to the GAC. Once an assembly is in the GAC, it's accessible by any other managed application, even coming from untrusted zones. The assembly you are adding to the GAC has to be strongly named signed and it will run with full-trust, so you have to be sure you are not doing something like asserting a permission without been sure you need to do that. Since the assembly is strongly named, there are no issues with installing and uninstalling it from the gac. You can even have multiple versions of the same assembly at the same time stored in the GAC. So, the bottom line is: if this is a shared component, the GAC is the right place for it but you have to be careful. Note: The component will be available to partially trusted code only if you put set the APTCA attribute. Thanks, Marcelo [quoted text, click to view] "Paul" <paul@dmaxx.com> wrote in message news:%23nE1tFabDHA.2580@TK2MSFTNGP12.phx.gbl... > Does anyone have recommendations on whether or not to use the Global > Assembly Cache? > Currently; we're installing a single DLL that can be used by one or more of > our applications (VB6 via interop and VB.NET). > Not sure what the GAC buys us. > Seems there may be issues trying to uninstall/install when a new version of > the DLL comes out. > > regards, > > - Paul - > > >
Does anyone have recommendations on whether or not to use the Global
Assembly Cache? Currently; we're installing a single DLL that can be used by one or more of our applications (VB6 via interop and VB.NET). Not sure what the GAC buys us. Seems there may be issues trying to uninstall/install when a new version of the DLL comes out. regards, - Paul -
When you say share the component across the machine, do you mean allow
different users that log on to the computer to access the DLL? If so, then YES. Whichever user runs our application needs to be able to invoke the DLL functions that those apps need. The assembly is strongly named but as of yet, does not have any code signing. We plan on signing up with VeriSign to get a proper signature. Are there any issues with not having code signing now but adding it later and updating the assembly if it's loaded in the GAC? If we want partially trusted code to access the assembly you're suggesting that we set the APTCA attribute. What constitutes trusted code? partially trusted code? Per the docs: "Strong-named assemblies must be explicitly enabled to be used by partially trusted code. Developers must now declare which strong-named assemblies are designed for use by partially trusted code. Without this explicit declaration, the caller must have full trust to use the code. This change ensures that developers will never unknowingly expose functionality that is not properly secured for use by partially trusted callers. Note that this change applies only to assemblies that have been assigned a strong name. " We have VB6 applications that will be calling thru the interop layer to get to the VB.NET DLL. Are these apps considered trusted? Partially? How can they be made [partially] trusted? Does it matter which user runs the VB6 apps that then call the .,NET assembly? If code isn't trusted, what will result in the call to the DLL? Will I simply get a "Can't create object" error? Or, is it more obscure in order to hide the fact that the calling app isn't trusted? There's a lot of room here for open-ended discussions. I'm trying to frame specific questions to help focus my thoughts. I appreciate any input you have. I want our entry into the .NET world to be a successful one. thanks, - Paul - [quoted text, click to view] "Marcelo Birnbach [MS]" <mbirnbac@online.microsoft.com> wrote in message news:eepTxDbbDHA.1272@TK2MSFTNGP12.phx.gbl... > Hi Paul, > > You have to be sure that you want to share your component across the machine > if you are going to add it to the GAC. Once an assembly is in the GAC, it's > accessible by any other managed application, even coming from untrusted > zones. > > The assembly you are adding to the GAC has to be strongly named signed and > it will run with full-trust, so you have to be sure you are not doing > something like asserting a permission without been sure you need to do that. > > Since the assembly is strongly named, there are no issues with installing > and uninstalling it from the gac. You can even have multiple versions of the > same assembly at the same time stored in the GAC. > > So, the bottom line is: if this is a shared component, the GAC is the right > place for it but you have to be careful. > > Note: The component will be available to partially trusted code only if you > put set the APTCA attribute. > > Thanks, > Marcelo > > "Paul" <paul@dmaxx.com> wrote in message > news:%23nE1tFabDHA.2580@TK2MSFTNGP12.phx.gbl... > > Does anyone have recommendations on whether or not to use the Global > > Assembly Cache? > > Currently; we're installing a single DLL that can be used by one or more > of > > our applications (VB6 via interop and VB.NET). > > Not sure what the GAC buys us. > > Seems there may be issues trying to uninstall/install when a new version > of > > the DLL comes out. > > > > regards, > > > > - Paul - > > > > > > > >
I'm already installing into the \Program Files\Common Files\<my company
shared>\< my application> directory. I assume this is analogous to " put into that applications common directory. ", right? "make available to everyone goes in the GAC" - for now, only our company's applications reference the assembly. But we have a service that runs under a specific Windows account and client applications that run under the user's Windows account. So, in one sense, we need everyone to have access to the assembly. Or, am I mis-undersranding and you really mean other applications. One day, we may publish this or a subsequent assembly to be used by customer-written applications. Would that then required GAC? thanks, - Paul - [quoted text, click to view] "Daniel Fisher" <danfi@online.microsoft.com> wrote in message news:%23q51PokbDHA.2356@cpmsftngxa06.phx.gbl... > > The general rule that groups I have been involved with have used is that > only components that you want to make available to everyone goes in the > GAC. This is usefull if you multiple applications will need to use this > component. Components shared only within a product or product group could > be put into that applications common directory. > > Remember that putting an assembly in the GAC requires a strong names and > may not buy you anything for your time and effort of installing them in the > GAC. > > Daniel Fisher > Natural User Interface Platform (Authoring) > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm > > -------------------- > >>From: "Paul" <paul@dmaxx.com> > >>Subject: Use GAC or not? > >>Date: Thu, 28 Aug 2003 15:23:00 -0500 > >>Lines: 14 > >>X-Priority: 3 > >>X-MSMail-Priority: Normal > >>X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 > >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 > >>Message-ID: <#nE1tFabDHA.2580@TK2MSFTNGP12.phx.gbl> > >>Newsgroups: microsoft.public.dotnet.framework.clr > >>NNTP-Posting-Host: 216.1.120.166 > >>Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl > >>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:7790 > >>X-Tomcat-NG: microsoft.public.dotnet.framework.clr > >> > >>Does anyone have recommendations on whether or not to use the Global > >>Assembly Cache? > >>Currently; we're installing a single DLL that can be used by one or more > of > >>our applications (VB6 via interop and VB.NET). > >>Not sure what the GAC buys us. > >>Seems there may be issues trying to uninstall/install when a new version > of > >>the DLL comes out. > >> > >>regards, > >> > >> - Paul - > >> > >> > >> > >> > >
Putting the assembly in the GAC allows you to single-instance the assembly
so that if it is shared across multiple applications, you don't have to drop them into each individual app directory. This can add up to substantial disk space savings if your assembly is used by many applications. You should only add APTCA if you expect that your assembly can be callable from partial-trust code. For example, if you navigate to a HREF EXE (or run some other code off the internet), do you expect that your code should be callable from that code or not? If you only need to have your code callable from apps running off the local machine, you don't need APTCA. -- This posting is provided "AS IS" with no warranties, and confers no rights. http://blogs.gotdotnet.com/alanshi [quoted text, click to view] "Paul" <paul@dmaxx.com> wrote in message news:uMPAJOfbDHA.652@tk2msftngp13.phx.gbl... > When you say share the component across the machine, do you mean allow > different users that log on to the computer to access the DLL? > If so, then YES. > Whichever user runs our application needs to be able to invoke the DLL > functions that those apps need. > > The assembly is strongly named but as of yet, does not have any code > signing. > We plan on signing up with VeriSign to get a proper signature. > Are there any issues with not having code signing now but adding it later > and updating the assembly if it's loaded in the GAC? > > If we want partially trusted code to access the assembly you're suggesting > that we set the APTCA attribute. > What constitutes trusted code? partially trusted code? > Per the docs: > > "Strong-named assemblies must be explicitly enabled to be used by > partially trusted code. > > Developers must now declare which strong-named assemblies are designed > for use by partially trusted code. > > Without this explicit declaration, the caller must have full trust to > use the code. This change ensures that developers > > will never unknowingly expose functionality that is not properly > secured for use by partially trusted callers. > > Note that this change applies only to assemblies that have been > assigned a strong name. " > > > We have VB6 applications that will be calling thru the interop layer to get > to the VB.NET DLL. > Are these apps considered trusted? Partially? How can they be made > [partially] trusted? > Does it matter which user runs the VB6 apps that then call the .,NET > assembly? > If code isn't trusted, what will result in the call to the DLL? Will I > simply get a "Can't create object" error? Or, is it more obscure in order > to hide the fact that the calling app isn't trusted? > > There's a lot of room here for open-ended discussions. > I'm trying to frame specific questions to help focus my thoughts. > I appreciate any input you have. I want our entry into the .NET world to > be a successful one. > > thanks, > > - Paul - > > > > > > > > "Marcelo Birnbach [MS]" <mbirnbac@online.microsoft.com> wrote in message > news:eepTxDbbDHA.1272@TK2MSFTNGP12.phx.gbl... > > Hi Paul, > > > > You have to be sure that you want to share your component across the > machine > > if you are going to add it to the GAC. Once an assembly is in the GAC, > it's > > accessible by any other managed application, even coming from untrusted > > zones. > > > > The assembly you are adding to the GAC has to be strongly named signed and > > it will run with full-trust, so you have to be sure you are not doing > > something like asserting a permission without been sure you need to do > that. > > > > Since the assembly is strongly named, there are no issues with installing > > and uninstalling it from the gac. You can even have multiple versions of > the > > same assembly at the same time stored in the GAC. > > > > So, the bottom line is: if this is a shared component, the GAC is the > right > > place for it but you have to be careful. > > > > Note: The component will be available to partially trusted code only if > you > > put set the APTCA attribute. > > > > Thanks, > > Marcelo > > > > "Paul" <paul@dmaxx.com> wrote in message > > news:%23nE1tFabDHA.2580@TK2MSFTNGP12.phx.gbl... > > > Does anyone have recommendations on whether or not to use the Global > > > Assembly Cache? > > > Currently; we're installing a single DLL that can be used by one or more > > of > > > our applications (VB6 via interop and VB.NET). > > > Not sure what the GAC buys us. > > > Seems there may be issues trying to uninstall/install when a new version > > of > > > the DLL comes out. > > > > > > regards, > > > > > > - Paul - > > > > > > > > > > > > > > >
The general rule that groups I have been involved with have used is that only components that you want to make available to everyone goes in the GAC. This is usefull if you multiple applications will need to use this component. Components shared only within a product or product group could be put into that applications common directory. Remember that putting an assembly in the GAC requires a strong names and may not buy you anything for your time and effort of installing them in the GAC. Daniel Fisher Natural User Interface Platform (Authoring) -- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm -------------------- [quoted text, click to view] >>From: "Paul" <paul@dmaxx.com> >>Subject: Use GAC or not? >>Date: Thu, 28 Aug 2003 15:23:00 -0500 >>Lines: 14 >>X-Priority: 3 >>X-MSMail-Priority: Normal >>X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 >>Message-ID: <#nE1tFabDHA.2580@TK2MSFTNGP12.phx.gbl> >>Newsgroups: microsoft.public.dotnet.framework.clr >>NNTP-Posting-Host: 216.1.120.166 >>Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl >>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:7790 >>X-Tomcat-NG: microsoft.public.dotnet.framework.clr >> >>Does anyone have recommendations on whether or not to use the Global >>Assembly Cache? >>Currently; we're installing a single DLL that can be used by one or more of >>our applications (VB6 via interop and VB.NET). >>Not sure what the GAC buys us. >>Seems there may be issues trying to uninstall/install when a new version of >>the DLL comes out. >> >>regards, >> >> - Paul - >> >> >> >>
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 |