Remoting version compatibility

  • Thread starter Thread starter schaf
  • Start date Start date
S

schaf

Hi Ng!
My application (version 1 a1) communicates with a service (version 1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different <wellknown>
entries in my app.config ? one for the old one and one for the new one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work ?

Thanks for hints
 
Hi,

Try telling the remoting framework to exclude version information completely
by setting "includeVersions" to false (works for binary and soap formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);
 
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!



Hi,

Try telling the remoting framework to exclude version information completely
by setting "includeVersions" to false (works for binary and soap formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi Ng!
My application (version 1 a1) communicates with a service (version 1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different <wellknown>
entries in my app.config ? one for the old one and one for the new one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work ?

Thanks for hints
Click to expand...
Click to expand...
 
This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is giving you
the cast error.

HTH.
--
With Regards
Shailen Sukul
..Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
schaf said:
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!



Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi Ng!
My application (version 1 a1) communicates with a service (version 1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different <wellknown>
entries in my app.config ? one for the old one and one for the new one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work ?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Hi,

I agree with Shailen. This will only work if the interfaces are the same,
but in different versions of the assembly. If the types are different then
you won't be able to do it by simply telling remoting to ignore the version
information. .NET isn't like COM in that sense.

Sorry for any confusion.

--
Dave Sexton
http://davesexton.com/blog

Shailen Sukul said:
This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is giving you
the cast error.

HTH.
--
With Regards
Shailen Sukul
.Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
schaf said:
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!



Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

Hi Ng!
My application (version 1 a1) communicates with a service (version 1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different
<wellknown>
entries in my app.config ? one for the old one and one for the new one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work ?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Hi Dave, Hi Shailen!

Thanks for your response and help!
Do I understand it the right way? I have to create a new interface for
the new properties and then I have to implement this in the remote
object. in a2 I have to use the old interface ! If this is right, then
it is exactly what I do.
Dave as you wrote I created a new version of my assembly. In a2 I just
have a reference to this new assembly, because I thought my new
interface is derived from the old one and therefore I can use the old
one to communicate with the old service s1. Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?

Thanks

PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.


Hi,

I agree with Shailen. This will only work if the interfaces are the same,
but in different versions of the assembly. If the types are different then
you won't be able to do it by simply telling remoting to ignore the version
information. .NET isn't like COM in that sense.

Sorry for any confusion.

--
Dave Sexton
http://davesexton.com/blog

Shailen Sukul said:
This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is giving you
the cast error.

HTH.
--
With Regards
Shailen Sukul
.Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
schaf said:
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!




Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

Hi Ng!
My application (version 1 a1) communicates with a service (version 1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different
<wellknown>
entries in my app.config ? one for the old one and one for the new one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work ?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Hi,
Do I understand it the right way? I have to create a new interface for
the new properties and then I have to implement this in the remote
object. in a2 I have to use the old interface ! If this is right, then
it is exactly what I do.
Dave as you wrote I created a new version of my assembly. In a2 I just
have a reference to this new assembly, because I thought my new
interface is derived from the old one and therefore I can use the old
one to communicate with the old service s1.
Click to expand...

But you wrote in your OP that you're getting an InvalidCastException, which
I assume is because you are returning the old interface and attempting to
cast it to the new interface, correct? That cannot be done if the service
returns an object that doesn't implement the new interface.

There isn't any value in creating a new interface if it can't be used, of
course, so calling an old service with a new interface is pointless anyway.

If, on the other hand, you are trying to call a new service with an old
interface, that should work setting the includeVersions property to false,
AFAIK.
PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.
Click to expand...

How does the demo differ from the real problem?
Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?
Click to expand...

Dll hell all over again :) You should avoid that if possible.

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi Dave, Hi Shailen!

Thanks for your response and help!
Do I understand it the right way? I have to create a new interface for
the new properties and then I have to implement this in the remote
object. in a2 I have to use the old interface ! If this is right, then
it is exactly what I do.
Dave as you wrote I created a new version of my assembly. In a2 I just
have a reference to this new assembly, because I thought my new
interface is derived from the old one and therefore I can use the old
one to communicate with the old service s1. Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?

Thanks

PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.


Hi,

I agree with Shailen. This will only work if the interfaces are the
same,
but in different versions of the assembly. If the types are different
then
you won't be able to do it by simply telling remoting to ignore the
version
information. .NET isn't like COM in that sense.

Sorry for any confusion.

--
Dave Sexton
http://davesexton.com/blog

Shailen Sukul said:
This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is giving
you
the cast error.

HTH.
--
With Regards
Shailen Sukul
.Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is
installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I
create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!




Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

Hi Ng!
My application (version 1 a1) communicates with a service (version
1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in
a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different
<wellknown>
entries in my app.config ? one for the old one and one for the new
one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work
?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Hi!

Yes I get an InvalidCastException, you are right. It is difficult to
describe the problem, and the code is to long...
So I try to explain what I did (pseudo-code) (the Server.exe only
registers the service):

Old version V1 (SharedV1.dll) :

public interface I1 { string Version {get;}}
public class RO : I1, MarshalByRef{...}

Old version V1 (ClientV1.exe, reference to SharedV1.dll):
Use of I1.Version....

New Version V2 (SharedV2.dll):
public interface I1 { string Version {get;}}
public interface I2 : I1 { string Name {get;}}
public class RO : I2, MarshalByRef {.....}

New Version V2 (ClientV2.exe):
I1 myI1 = new RO(); //Original with the Activator.GetObject implemented
if (myI1.Version = "2") {
I2 myI2 = myI1 as I2;
use of I2.Name;
}

All assemblies are strong named.
I get the InvalidCastException as soon as I run my ClientV2 against the
serverV1 whit (SharedV1). I thought I can test the version over the I1,
but I get the exception when I call a function on the TransparentProxy.

During my tests I determined, that I'm able use this code if I do not
change the version in the assembly of SharedV2. So I guess my problem
is the strong naming, but only includeVersions="false" does not help.
I have read (MSDN .NEt Remoting versioning) that the version is defined
by the server on SAO. Therefore it should be better to define a new
assembly if Interface changes are needed. What do you about that ?

I will try a solution at weekend.
Thanks and Regards.
Marcel

But you wrote in your OP that you're getting an InvalidCastException, which
I assume is because you are returning the old interface and attempting to
cast it to the new interface, correct? That cannot be done if the service
returns an object that doesn't implement the new interface.

There isn't any value in creating a new interface if it can't be used, of
course, so calling an old service with a new interface is pointless anyway.

If, on the other hand, you are trying to call a new service with an old
interface, that should work setting the includeVersions property to false,
AFAIK.
PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.
Click to expand...

How does the demo differ from the real problem?
Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?
Click to expand...

Dll hell all over again :) You should avoid that if possible.

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi Dave, Hi Shailen!

Thanks for your response and help!
Do I understand it the right way? I have to create a new interface for
the new properties and then I have to implement this in the remote
object. in a2 I have to use the old interface ! If this is right, then
it is exactly what I do.
Dave as you wrote I created a new version of my assembly. In a2 I just
have a reference to this new assembly, because I thought my new
interface is derived from the old one and therefore I can use the old
one to communicate with the old service s1. Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?

Thanks

PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.


Hi,

I agree with Shailen. This will only work if the interfaces are the
same,
but in different versions of the assembly. If the types are different
then
you won't be able to do it by simply telling remoting to ignore the
version
information. .NET isn't like COM in that sense.

Sorry for any confusion.

--
Dave Sexton
http://davesexton.com/blog

This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is giving
you
the cast error.

HTH.
--
With Regards
Shailen Sukul
.Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is
installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a new
version of my service (s2 but the same dll and exe name). Then I
create
my new client with a reference to the new remote object dll. But if I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof the
remote object) requests IRo.Version, it should work, or not ?

Please help!




Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

Hi Ng!
My application (version 1 a1) communicates with a service (version
1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented in
a
new interface, which derive from the old one to ensure that an old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is this
because of the strong naming ? Do I have to add 2 different
<wellknown>
entries in my app.config ? one for the old one and one for the new
one
?

Maybe it is very important to know, that the service assemblies are
installed in the application\bin and not in the GAC. Does this work
?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Hi,

I'm not sure why you're getting an InvalidCastException. If the old service
doesn't reference the new shared assembly then the cast using the "as"
operator should just return null, not throw an exception.

The design seems poor anyway, especially since you're using the as operator
after checking the Version property. Versioning interfaces like we did in
COM seems a bit outdated. You could just update the actual interface itself
by adding the new property, Name (and lose the Version property), then
compile the assembly with an updated AssemblyVersion attribute. This way,
the framework will handle the binding for you or you can control the binding
using binding redirection between different versions of your assembly. In
that case, make sure your client assembly is installed in the GAC (you'll
have to create a client proxy assembly that your .exe can reference). As
far as the remoting framework is concerned in that case, it should see the
type as being the same if you set includeVersions to false, since the only
thing that differs between the interfaces is the assembly version.

HTH

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi!

Yes I get an InvalidCastException, you are right. It is difficult to
describe the problem, and the code is to long...
So I try to explain what I did (pseudo-code) (the Server.exe only
registers the service):

Old version V1 (SharedV1.dll) :

public interface I1 { string Version {get;}}
public class RO : I1, MarshalByRef{...}

Old version V1 (ClientV1.exe, reference to SharedV1.dll):
Use of I1.Version....

New Version V2 (SharedV2.dll):
public interface I1 { string Version {get;}}
public interface I2 : I1 { string Name {get;}}
public class RO : I2, MarshalByRef {.....}

New Version V2 (ClientV2.exe):
I1 myI1 = new RO(); //Original with the Activator.GetObject implemented
if (myI1.Version = "2") {
I2 myI2 = myI1 as I2;
use of I2.Name;
}

All assemblies are strong named.
I get the InvalidCastException as soon as I run my ClientV2 against the
serverV1 whit (SharedV1). I thought I can test the version over the I1,
but I get the exception when I call a function on the TransparentProxy.

During my tests I determined, that I'm able use this code if I do not
change the version in the assembly of SharedV2. So I guess my problem
is the strong naming, but only includeVersions="false" does not help.
I have read (MSDN .NEt Remoting versioning) that the version is defined
by the server on SAO. Therefore it should be better to define a new
assembly if Interface changes are needed. What do you about that ?

I will try a solution at weekend.
Thanks and Regards.
Marcel

But you wrote in your OP that you're getting an InvalidCastException,
which
I assume is because you are returning the old interface and attempting to
cast it to the new interface, correct? That cannot be done if the
service
returns an object that doesn't implement the new interface.

There isn't any value in creating a new interface if it can't be used, of
course, so calling an old service with a new interface is pointless
anyway.

If, on the other hand, you are trying to call a new service with an old
interface, that should work setting the includeVersions property to
false,
AFAIK.
PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.
Click to expand...

How does the demo differ from the real problem?
Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?
Click to expand...

Dll hell all over again :) You should avoid that if possible.

--
Dave Sexton
http://davesexton.com/blog

schaf said:
Hi Dave, Hi Shailen!

Thanks for your response and help!
Do I understand it the right way? I have to create a new interface for
the new properties and then I have to implement this in the remote
object. in a2 I have to use the old interface ! If this is right, then
it is exactly what I do.
Dave as you wrote I created a new version of my assembly. In a2 I just
have a reference to this new assembly, because I thought my new
interface is derived from the old one and therefore I can use the old
one to communicate with the old service s1. Or do I have to add the new
and the old assembly as a reference in the new a2 to ensure the
communication with s1 and s2 ?

Thanks

PS: I have written the same problem in a demo project and there it
works...I'm reallt confused.



Hi,

I agree with Shailen. This will only work if the interfaces are the
same,
but in different versions of the assembly. If the types are different
then
you won't be able to do it by simply telling remoting to ignore the
version
information. .NET isn't like COM in that sense.

Sorry for any confusion.

--
Dave Sexton
http://davesexton.com/blog

This error does not seem to be related to remoting.
If a2 calls the old service s1, then it must use the old interface.
I am presuming that you are using the new interface hence it is
giving
you
the cast error.

HTH.
--
With Regards
Shailen Sukul
.Net Architect
(MCPD: Ent Apps, MCSD.Net MCSD MCAD)
Ashlen Consulting Services
http://www.ashlen.net.au
Hi Dave

Thanks for your answer, but it seams not to work.
I have the problem, that the version 1 of the service (s1) is
installed
in the app\bin dir.
After adding the new interfaces to the remote objects i created a
new
version of my service (s2 but the same dll and exe name). Then I
create
my new client with a reference to the new remote object dll. But if
I
now run my app against the old service (with the old version of the
remote object) i allways get this error.

In the old remote object I had a property 'Version' in the
interface
IRo.
In the new remote object I have a IRoV2 which derive from IRo and
implements the additional property 'Name'.

So if my new client (which was compiled with the second versionof
the
remote object) requests IRo.Version, it should work, or not ?

Please help!




Hi,

Try telling the remoting framework to exclude version information
completely
by setting "includeVersions" to false (works for binary and soap
formatters
on server and client sinks):

Channel Sink Properties
http://msdn2.microsoft.com/en-us/library/bb187423(VS.80).aspx

The "includeVersions" property can be set using a dictionary of
properties
when constructing the formatter provider, programmatically or via
the
application's configuration file.

<formatter> Element (Template)
http://msdn2.microsoft.com/en-us/library/ezf9wcys(VS.80).aspx

Here's setting the property programmatically on the client-side:

IDictionary props = new Hashtable();
props["includeVersions"] = "false";

BinaryClientFormatterSinkProvider clientSinkProvider =
new BinaryClientFormatterSinkProvider(props);

TcpChannel channel = new TcpChannel(null,
clientSinkProvider, null);

--
Dave Sexton
http://davesexton.com/blog

Hi Ng!
My application (version 1 a1) communicates with a service
(version
1
s1). Now I would like to update the service and create a service
version 2 (s2). The new function calls within s2 are implemented
in
a
new interface, which derive from the old one to ensure that an
old
version of my application (a1) still works with s2.
If i run my new version of the application a2 with s1 I get a
InvalidCastException (Return argument has an invalid type). Is
this
because of the strong naming ? Do I have to add 2 different
<wellknown>
entries in my app.config ? one for the old one and one for the
new
one
?

Maybe it is very important to know, that the service assemblies
are
installed in the application\bin and not in the GAC. Does this
work
?

Thanks for hints
Click to expand...
Click to expand...
Click to expand...
 
Back
Top