After much testing and research, I know much more about probing and config files etc... However, I have yet to resolve my problem.

If I understand this correctly, I should be able to go into an application's config file and redirect a reference it has to an object from version 1.0.0.4 to 1.0.0.5, both of which reside in the GAC (and nowhere else). Version 1.0.0.4 Points to my PRD SQL Server while version 1.0.0.0 points to my DEV SQL Server.

The client in my case is a Web Service, and the config file is Web.Config at the application level in the applications directory (under IIS). The entry in the file is:

    <compilation defaultLanguage="vb" debug="true">
       <assemblies>
            <add assembly="ent_GlobalInfo, Version=1.0.0.5,      
            Culture=neutral, PublicKeyToken=80fea8cb55f2d3a7"/>
       </assemblies>
    </compilation>

I can change the Version= from '1.0.0.4' to '1.0.0.5' and vice versa with zero affect. It should redirect the Web Service reference to the object of the same name but differing versions and switch between saving to PRD and DEV databases, which it does not. The difference between the two versions within the referenced object is the connection string used to connect to the DB.

None of my tests have revealed any dynamic ability to redirect references. I want to simply use the easiest and highest lvl solution at this point so I can concentrate on more pressing issues of my software. One day I will delve into Reflection, and even the other config file options (like the Publisher Policies etc) but right now I have no incentive as the first step (app level config) simply doesn't work.

I also had trouble with the Server containing cached objects of same version that did not release until the Server was rebooted. This means if you recompile ObjectX with the same version that had previously been found and loaded by the Server, it will simply use the cached object and your changes have no affect. MSDN even alludes to this under 'ASP.NET Configuration' (I am using a Web Service after all):

At run time, ASP.NET uses the configuration information provided by the Web.config files in a hierarchical virtual directory structure to compute a collection of configuration settings for each unique URL resource. The resulting configuration settings are then cached for all subsequent requests to a resource. Note that inheritance is defined by the incoming request path (the URL), not the file system paths to the resources on disk (the physical paths).

This just doesn't appear to be a solution for dll hell...

Any further help is appreciated.

Brian Burke.