Dynamic assembly version loading

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Here is the scenario I want to achieve...

1. An assembly is created "on-the-fly" using the CodeDom compiler.
2. This assembly is then used by a running application.
3. At some point in time the "on-the-fly" assembly changes and is
recompiled. Thus we have on-the-fly version 2.
4. My questions are:

a. What is the best way to introduce the version 2 assembly and not
interrupt the existing instances of types created using version 1? An
AppDomain? A custom designed load and CreateInstance procedure?
b. Is there any way to determine how many instances of version 1 types are
in existence? Another way to say that is how can I automatically determine
whether the version 1 Assembly is still in use by a caller.
c. Assuming that version 2 types have only new methods and properties, i.e.
none of version 1 methods and properties are deleted, is it possible for the
two versions' Assemblies to co-exist? In other words just start using the new
version and let the old become dormant as time elapses?

Your thoughts are appreciated...
 
Hi John,

Thanks for the posting!

I reply each of your two questions below:
a. "What is the best way to introduce the version 2 assembly and not
interrupt ...? "
After one Assembly is loaded, it is precisely to say it is loaded into one
AppDomain. Each process running .Net application will have one defualt
AppDomain to execute the Main method of our application. So if we load one
dynamic assembly, it is loaded into the defualt AppDomain by default.

Since you are going to call the two versions of the dynamic assembly, I
assume the class name may be duplicated. If so, when we are going to create
one new class after loading the second assembly, runtime will not know
explicitly which class should be used to create the new instance.

So the best suggestion for this question is: at the version2 assembly,
please grant the class with new name or use different namespace to define
the class. Then the caller code will not be confused to instantiate which
class.

The 2nd suggestion:
If your scenario permits the AppDomain and you are not going to change the
dynamic assembly name, please load the version 2 assembly into another
AppDomain. Since each AppDomain maintains its own loaded assemblies (we can
simply to say so), the version 2 will not cause any confusion with the
version 1 because they are loaded into different AppDomain.

In addition, at current .Net runtime, if one assembly is loaded into the
AppDomain, we will not unload the assembly unless the AppDomain is
unloaded.

b. "Is there any way to determine how many instances of version 1 types are
in existence"
We can use the Assembly.GetAssembly method to obtain the version 1
assembly. We only need to pass the object of the type in version 1 to this
method and it will return the version 1 assembly. Another way is that we
can call the AppDomain.GetAssemblies() method to obtain the assemblies
loaded into this AppDomain. Then enumerate the result array to locate the
Version 1 assembly.

If you load the version 1 Assembly at the default AppDomain, we can use
AppDomain.CurrentDomain method to obtain the Default AppDomain reference
using this method.

Please feel free to let me know if you have any further question on this
issue.

Have a nice day!

Best Regards,
Wei-Dong XU
Microsoft Support
 
inline

"Wei-Dong XU [MSFT]" said:
Hi John,

Thanks for the posting!

I reply each of your two questions below:
a. "What is the best way to introduce the version 2 assembly and not
interrupt ...? "
After one Assembly is loaded, it is precisely to say it is loaded into one
AppDomain. Each process running .Net application will have one defualt
AppDomain to execute the Main method of our application. So if we load one
dynamic assembly, it is loaded into the defualt AppDomain by default.

Since you are going to call the two versions of the dynamic assembly, I
assume the class name may be duplicated. If so, when we are going to
create
one new class after loading the second assembly, runtime will not know
explicitly which class should be used to create the new instance.

So the best suggestion for this question is: at the version2 assembly,
please grant the class with new name or use different namespace to define
the class. Then the caller code will not be confused to instantiate which
class.

The 2nd suggestion:
If your scenario permits the AppDomain and you are not going to change the
dynamic assembly name, please load the version 2 assembly into another
AppDomain. Since each AppDomain maintains its own loaded assemblies (we
can
simply to say so), the version 2 will not cause any confusion with the
version 1 because they are loaded into different AppDomain.
Click to expand...

This is true only if the type defined in assembly 2 is not used in the
default appdomain. If the type is used in the default appdomain then the
assembly the type is defined in is loaded into both appdomains. Basically,
any appdomain that uses the type must have the type's assembly loaded into
it.

In addition, at current .Net runtime, if one assembly is loaded into the
AppDomain, we will not unload the assembly unless the AppDomain is
unloaded.

b. "Is there any way to determine how many instances of version 1 types
are
in existence"
We can use the Assembly.GetAssembly method to obtain the version 1
assembly. We only need to pass the object of the type in version 1 to this
method and it will return the version 1 assembly. Another way is that we
can call the AppDomain.GetAssemblies() method to obtain the assemblies
loaded into this AppDomain. Then enumerate the result array to locate the
Version 1 assembly.
Click to expand...

This does not answer the OP's question. There really is no direct means of
determining if an instance of a type is referenced anywhere in the running
code - this is what the GC does when it performs a garbge collection.
If you load the version 1 Assembly at the default AppDomain, we can use
AppDomain.CurrentDomain method to obtain the Default AppDomain reference
using this method.
Click to expand...

The OP also asked...
c. Assuming that version 2 types have only new methods and properties, i.e.
none of version 1 methods and properties are deleted, is it possible for the
two versions' Assemblies to co-exist? In other words just start using the
new
version and let the old become dormant as time elapses?

Yes, but not directly. Very different techniques need to be used then simply
loading an assembly and directly referencing the types within it.

One immediate problem is that it is not possible to have an assembly with
the same filename as another at the same location, so it needs to either be
unquely named or be in different directories.


There was a talk at last years PDC that got into the issue of addins - Jim
Miller and Tom Quinn gave it, and here's a link to it. It goes into some of
the issues the OP raised. Here are some links
http://commnet.microsoftpdc.com/content/downloads.aspx
http://216.55.183.63/pdc2005/slides/FUN309_Miller.ppt
http://blogs.msdn.com/jackg/archive/2005/09/15/468068.aspx
http://blogs.msdn.com/TQ/

The presentation does a good job of explaining the issues and their
recommended solutions.
 
Back
Top