473,322 Members | 1,781 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Remoting version compatibility

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

Jan 16 '07 #1
8 3473
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...
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

Jan 16 '07 #2
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...
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
Jan 16 '07 #3
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.googleg roups.com...
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

Jan 16 '07 #4
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" <sh***@ashlen.net.auwrote in message
news:ef**************@TK2MSFTNGP02.phx.gbl...
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
>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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.google groups.com...
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


Jan 17 '07 #5
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" <sh***@ashlen.net.auwrote in message
news:ef**************@TK2MSFTNGP02.phx.gbl...
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.googleg roups.com...
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

Jan 17 '07 #6
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.
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.
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 ?
Dll hell all over again :) You should avoid that if possible.

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

"schaf" <sc***@2wire.chwrote in message
news:11*********************@s34g2000cwa.googlegro ups.com...
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" <sh***@ashlen.net.auwrote in message
news:ef**************@TK2MSFTNGP02.phx.gbl...
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.google groups.com...
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


Jan 17 '07 #7
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.

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 ?

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

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

"schaf" <sc***@2wire.chwrote in message
news:11*********************@s34g2000cwa.googlegro ups.com...
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" <sh***@ashlen.net.auwrote in message
news:ef**************@TK2MSFTNGP02.phx.gbl...
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.googleg roups.com...
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
Jan 17 '07 #8
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" <sc***@2wire.chwrote in message
news:11*********************@v45g2000cwv.googlegro ups.com...
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.

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 ?

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

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

"schaf" <sc***@2wire.chwrote in message
news:11*********************@s34g2000cwa.googlegr oups.com...
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" <sh***@ashlen.net.auwrote in message
news:ef**************@TK2MSFTNGP02.phx.gbl...
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" <sc***@2wire.chwrote in message
news:11*********************@38g2000cwa.googlegrou ps.com...
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/lib...23(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.

<formatterElement (Template)
http://msdn2.microsoft.com/en-us/lib...ys(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" <sc***@2wire.chwrote in message
news:11**********************@s34g2000cwa.google groups.com...
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



Jan 18 '07 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

15
by: anders | last post by:
Hi! I have a config file that looks like this: <?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode="SingleCall"...
5
by: mayamorning123 | last post by:
A comparison among six VSS remote tools including SourceOffSite , SourceAnyWhere, VSS Connect, SourceXT, VSS Remoting, VSS.NET To view the full article, please visit...
0
by: bettervssremoting | last post by:
To view the full article, please visit http://www.BetterVssRemoting.com Better VSS Remote Access Tool including SourceOffSite, SourceAnyWhere and VSS Remoting This article makes a detailed...
0
by: Martijn Damen | last post by:
Hi, At the moment I am trying to develop an application that uses another app over .net remoting and having some problems with it (ok, that is ofcourse why I am here), hope somebody can shine a...
5
by: LGHummel | last post by:
I'm trying to host a remoting app in IIS and am getting the following error: Failed to execute the request because the ASP.NET process identity does not have read permissions to the global...
4
by: Sharon | last post by:
Hi, I'm using the remoting, and I have a remoting object that has a public event that other processes should register to it. But when the client process is registering to the remote event, it...
5
by: Lambuz | last post by:
First of all, is it possible usign .NET remoting feature inside a .NET applet loaded into a tag object inside an HTML page ? <OBJECT id="myID" height="150" width="300"...
0
by: schaf | last post by:
Hi NG! I have a question about the versioning in .NET Remoting. I have an application with version 1 (I will call it A1) and a Service with version 1 (S1). S1 provides function calls to...
2
by: erbilkonuk | last post by:
Hi, I am very new to .NET Remoting and I try to run a simple program to subscribe to an event raised by Remoting Class. The Remoting Server initiates an instance of Remoting Class as Singleton /...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.