Hi Michael,
Thanks for your posting. As for the changing search path(for assembly at
runtime) of the .net applicaiton, I think this can be done by using the
.net framework's assembly binding and redirection mechanism.
Generally, when the .net application find a certain type's not loaded and
then it'll try loading the type's host assembly. This will be divided into
two steps, assembly resolving and assemly locating:
1. The runtime checking which assembly should load, the assmebly's base
name, version, culture, publickeytoken ...
2. Try follow the locating steps to locate the actual assembly file.
And the locating steps will follow the following sequence:
1) GAC
2) CODEBASE setting (in config file)
3) file probing( appbase and sub probing folders)
So the codebase setting is the one you can make use of , first make sure
your assembly is strong-named
and then you can specify a URL path for each version of your assembly in
your application config file. Below is the <codebase> configure element's
reference in MSDN:
#<codeBase> Element
http://msdn.microsoft.com/library/en-us/cpgenref/html/gngrfCodeBase.asp?fram
e=true
#note that since the GAC checking is before codebase, if there is also the
same one in GAC, the GAC one will be used first.
In addition, ASP.NET dosn't support strong-named assembly in private bin
path and we recommend that you'd better put strong-named assemly in GAC for
asp.net applciations.
Thanks.
Regards,
Steven Cheng
Microsoft Online Support
Get Secure!
www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)