|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Dynamic assembly version loading1. 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 --------------------------------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. --------------------------------------------------------------------------- It is my pleasure to be of any assistance. inline
""Wei-Dong XU [MSFT]"" <v-w***@online.microsoft.com> wrote in message Show quote news:uRzvWgZQGHA.5536@TK2MSFTNGXA03.phx.gbl... This is true only if the type defined in assembly 2 is not used in the > > 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. 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. Show quote > This does not answer the OP's question. There really is no direct means of > 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. > 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 The OP also asked...> AppDomain.CurrentDomain method to obtain the Default AppDomain reference > using this method. 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. |
|||||||||||||||||||||||