ProgID in .NET?

[Boris]

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

 

[Patrice]

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...

 

[Boris]

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

[...]

 

[Patrice]

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

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
rocess - something which was possible in COM as far as I can tell but
doesn't seem to be possible anymore in .NET?

Boris

[...]

 

[Cowboy \(Gregory A. Beamer\)]

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


--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************

 

[Phil Wilson]

..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.