 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / September 2007ProgID in .NET?
As many of you know probably you can use ProgIDs in COM to instantiate COM objects. The ProgID has the form Project.ClassName.Version. Thanks to version it is possible to instantiate COM objects from different versions of the same library. I wonder now if this is possible in .NET, too? When a class from a .NET assembly is instantiated its namespace and class name are used. Now if there is a new version of the .NET assembly you obviously have name ambiguity as namespace and class name are the same. It doesn't seem like it is possible to reference two versions of the same assembly if namespace and class names are the same? Or is there any way of specifying in code from which assembly the class should be instantiated? Boris Humm... You mean you would like use at the same time two different versions from the same application ? IMO you could explain what you are trying to do as someone could have a better suggestion than trying to do that... > As many of you know probably you can use ProgIDs in COM to instantiate COM > objects. The ProgID has the form Project.ClassName.Version. Thanks to [quoted text clipped - 9 lines] > > Boris On Fri, 14 Sep 2007 12:10:21 +0300, <"//www.chez.com/scribe/>"> wrote: > Humm... You mean you would like use at the same time two different > versions > from the same application ? Yes, exactly. > IMO you could explain what you are trying to do as someone could have a > better suggestion than trying to do that... In fact it's not me but a customer who wants to do that. They want to upgrade to a current version of our software but have lots of files which they tested and use with the old version. As they can't test all of the files with the current software version now and upgrade to the latest version in one step they want to use both versions of our software so they can move files from the old to the new version gradually. I proposed already to use two processes but for some reason that's something they don't want to do. At least they are still looking for a solution where they could use the old and the new version of our assembly in one process - something which was possible in COM as far as I can tell but doesn't seem to be possible anymore in .NET? Boris > [...] But why in the same process ? Can't they just use either the old version of the application or the new one at a particular given time ? I'm not sure what would be the best solution but you could perhaps try : - to include the version number in the namespace. This way you can reference whatever version(s) you wish. You could use an alias for the using statement so that you can compile each application with the "current" namespace and the "previous" namespace without having to change anything in the source code with each new version. - you could dynamically load an assembly but I'm not sure if this would work + it would be likely cumbersome to write code in this context and it would be likely much more changes than above - see if the using statement could use a fully qualified name included (don't think so) - if this is a file format issue or whatever else i could be perhaps also pal,ned ahead (for example have the last versino be able to load/save olld versiobn files but stille xpose the same modell) Perhaps someone else that tried to do that will be able to help. Sorry for the poor help. Good luck -- Patrice > On Fri, 14 Sep 2007 12:10:21 +0300, <"//www.chez.com/scribe/>"> wrote: > [quoted text clipped - 22 lines] > >> [...] Based on the thread, here is some info that might help you. 1. If you sign assemblies, you can specify version for an application in the config. This will allow your vendor to test the new version before flipping. 2. If you need to work two versions at one time, you can do that, via .NET libs that deal with Reflection, etc., but I would try to avoid this approach as much as possible. 3. You can also add a SOA layer to allow multiple version to be contacted via "services" (WCF or web/Remoting). This adds a small bit of latency, but allows you to mix and match by tayloring specific calls to a specific version of the library #1 is for testing and moving to a new version #2 is for solutions that cannot be set up with SOA endpoints #3 is the most flexible, but with great flexibility comes some latency :-)  SignatureGregory A. Beamer MVP, MCP: +I, SE, SD, DBA ************************************************* | Think outside the box! ************************************************* > As many of you know probably you can use ProgIDs in COM to instantiate COM > objects. The ProgID has the form Project.ClassName.Version. Thanks to [quoted text clipped - 9 lines] > > Boris .NET COM registration can be version dependent. http://msdn2.microsoft.com/en-us/library/zy736xtk(VS.71).aspx so typically clients that don't specify a version in the ProgId get the latest, otherwise clients that do care get the specific one they want. There's no requirement in late binding clients to specify a version in the ProgId. SignaturePhil Wilson [MVP Windows Installer] > As many of you know probably you can use ProgIDs in COM to instantiate COM > objects. The ProgID has the form Project.ClassName.Version. Thanks to [quoted text clipped - 9 lines] > > Boris Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.