I have to agree with J. Merrill on this one. What is the exact reason of not wanting to put your assembly in the GAC?
I too was under the impression that you wanted to specify a location on a networked drive somewhere but if you are putting the assembly local anyway what's the issue. To answer your question from yesterday, you can place Publisher Policy information in each clients machine.config as opposed to each app.config. Actually the <codebase> will only work "stand alone" if it's placed in the machine.config. If you place it in the app.config you must redirect your assembly in order for the CLR to even look at the <codebase> you specify. <quote source="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpg uide/html/cpconspecifyingassemblyslocation.asp"> You can use the <codeBase> element only in machine configuration or publisher policy files that also redirect the assembly version. When the runtime determines which assembly version to use, it applies the code base setting from the file that determines the version. If no code base is indicated, the runtime probes for the assembly in the normal way. For details, see How the Runtime Locates Assemblies. </quote> However, I would not bother with a publisher policy if I were installing the assembly local I would just put it in the GAC. HTH Brandon -----Original Message----- From: J. Merrill [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 6:28 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Trying to avoid the GAC using the /codebase option At 04:23 PM 1/8/2004, Claus Brod wrote >Brandon Manchester wrote: >>In your client's app.config file you can add an <assemblyBinding> >>section that can specify things like binding redirects (for >>versioning), codebases, and probing information. > >True, but that would require changes in the config files of all >clients, wouldn't it? Our application doesn't necessarily know all its >clients, so it can't patch their config files automatically. The other >alternative would be to have users modify the client config files, but >most users will never understand the XML syntax, and don't want to fool >around with config files anyway. Another alternative is to have the >client's installation programs search for our app and modify the client >config file accordingly. > >All of those schemes break when we install a new version of our app or >just move the existing installation. > >For these reasons, we were really looking for some way to a) advertise >the fact that our app's assembly is publicly available on the system >and >b) tell everybody that the code is not in the GAC, but, for instance, >at C:\Program Files\whatever\.... this way, the information about the >actual location of our assembly is recorded in only one place, making >it much easier to keep it in sync with reality (uninstallation, >installation of new versions etc etc). > >Thanks! > > Claus When you said you didn't want to install into the GAC, I had assumed that you wanted to leave the assemblies on a publicly available network drive. If you're going to put them on each user's C: drive, what's the advantage to putting it in c:\program files\whatever\ rather than in the GAC? I can't believe it's the pain of putting a strong name on the assemblies... If you do that, "the information about the actual location of the assembly is recorded in only one place" -- it's in the GAC. If you put it in the GAC, you can have multiple versions installed at once. (Testers often think that's useful, if not a requirement for whatever deployment solution you come up with.) What's so scary about the GAC? J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com Notice of Confidentiality: This transmission is intended only for the use of the individual or entity named above. It may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. Further, disclosure of this information may be specifically prohibited under state or Federal law. If you are not the intended recipient, or the employee or agent of the recipient responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
