You're right - I'd completely forgotten about /ir. That flag does cause gacutil.exe to record the original installed-from location (apparently in the __AssemblyInfo__.ini file in the directory where the assembly is placed in the GAC tree). That's why I said "that I know of", which implies for "of course, that doesn't mean it doesn't exist" :-).
That said, I still don't know of an API for extracting that information programmatically, even if you could guarantee that you only went looking for that information from assemblies you know were installed using /ir. Of course, you could always just parse it out of the ini file yourself, but that presumes the use of a lot of undoc'd information. Seems like fusion.dll should make that information available somewhere, so it's worth a look. CreateInstallReferenceEnum looks particularly interesting... -Mike DevelopMentor http://staff.develop.com/woodring > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of > John St. Clair > Sent: Tuesday, February 18, 2003 12:07 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Original CodeBase from GAC assembly > > > Mike, > > I thought that's what gacutil -ir and gacutil -ur were for. > If I'm wrong > -- which is probably the case, would you mind explaining the point of > the FILEPATH reference? > > John > > John St. Clair > Prosjekt- og teamleder > Reaktor AS > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]] On Behalf Of > Mike Woodring > (DevelopMentor) > Sent: 18. februar 2003 19:08 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Original CodeBase from GAC assembly > > > The issue is that when you install an assembly into the GAC, no record > is made anywhere (that I know of) as to where the assembly originally > came from. In fact, the original dll need not exist anymore (can be > deleted, or as in the case of assemblies installed into the gac from > removable media such as CDs). > > The CodeBase and Location properties are only different when the > assembly resolver arrives at a decision to download an assembly from > off-host (such as in a smart client or whenever codeBase redirects are > used in configuration files). In this situation, the > assembly resolver > identifies the "CodeBase" from whence a DLL should be loaded > as being X, > and then, if the CodeBase is off-host, downloads the bits for the > assembly to the temporary download cache in the local file system > ("Location"). In these situations, you can inspect either > the CodeBase > or Location properties for a given assembly depending on what you're > trying to determine (where it originally came from versus where it's > sitting in the local file system right now). > > But for assemblies installed in the GAC, no record is kept of the > original where-it-was-at-the-time-it-was-installed location. > So as for > what support the runtime might already have built-in, you're > out of luck > if that's what you need to know and will have to pursue rollowing your > own solution (ex: a custom GAC installer that records the original > installed-from location in some location to be consulted later; like a > config file, the registry, etc. > > -Mike > DevelopMentor > http://staff.develop.com/woodring > > > > -----Original Message----- > > From: Moderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED]] On Behalf Of James > > Crowley > > Sent: Tuesday, February 18, 2003 9:43 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Original CodeBase from GAC assembly > > > > > > Try > > > > Assembly.GetExecutingAssembly().Location > > > > Instead. According to msdn docs this is > > > > ~~ > > The location of the loaded file that contains the manifest. If the > > loaded file was shadow-copied, the Location is that of the > file before > > > being shadow-copied. > > ~~ > > > > Alternatively, > > > > System.Reflection.Assembly.GetAssembly(typeof(whatever)).CodeBase; > > > > Should work. > > > > ~ James Crowley > > >
