I'm pretty sure you're out of luck and that things just won't work the way you're wanting. The GAC is there for a reason - so people can bind to your assembly no matter where they are. Probing path configuration changes in the client won't work as they require subdirectories and not absolute directories. The best you can do without the GAC is let them Assembly.Load() your assembly from the location you installed it into.
We have a development platform we sell and we let customers reference our assemblies. We have 3 main assemblies (let's call them A, B and C) used everywhere and that comprises our SDK. We have 3 applications that use A, B and C and they bind to said assemblies from the GAC (so they don't have private copies). In a merge module we put the A, B and C into the GAC /and/ we put them in an SDK folder in the program files directory. Putting a duplicate copy in the program files directory lets our customers reference them easily. In addition we put an entry in the registry so that Visual Studio will pick up our SDK and put it in the Add Reference listbox (HKLM\Software\Microsoft\.NETFramework\AssemblyFolders). This has worked perfectly for us (and other people, we didn't invent this formula) and it accomplishes everything we need. When you install a new version you can just use publisher policy in the GAC on your backwards-compatible assemblies and make sure that any assembly bindings get forwarded to the correct version. To go back to what you are wanting, you can go the COM route, but you still need the GAC to support it (and the Activator.CreateComInstanceFrom method). The /codebase option just tells the .NET runtime /where/ the registered .NET assembly is, it doesn't change the way assembly binding and probing works. So you can't just /codebase your COM assemblies because they still need to know where to find their referenced assemblies (private path to the running application OR in the GAC). Adam.. > -----Original Message----- > 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). =================================== 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
