[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

How will .NET versioning affect my remoting application?

mdb

10/29/2004 5:02:00 PM

I'm writing a client/server distributed application that will have many
clients talking back to one central server. If in the future, I need to
make a change to the client or server code, and the .NET assembly version
changes, will this break the remoting even if none of the remoting calls
change?

Obviously, I'm asking about the situation where there are different
versions of the clients out there. Its clear to me that if I upgrade all
clients and the server to the same version then things will be ok.

I guess what I'm really asking is what's the best practice for handling
this sort of thing... How can I upgrade clients 1 and 2 to version 1.1
while leaving clients 3 and 4 at version 1.0, and still have all clients be
able to talk to the version 1.0 or 1.1 server (assuming the remoting calls
don't change.)

And I guess while I'm at it, if anyone could make some suggestions about
how to handle it when the remoting calls do change, that would be much
appreciated!

-mdb
5 Answers

Robert Jordan

10/29/2004 5:38:00 PM

0

mdb wrote:

> I'm writing a client/server distributed application that will have many
> clients talking back to one central server. If in the future, I need to
> make a change to the client or server code, and the .NET assembly version
> changes, will this break the remoting even if none of the remoting calls
> change?

I understood from your previous posts that you're already using
(or planing to use) a shared interface assembly.

As far you don't change that assembly no version problems are
expected, unless you break the semantics, of course ;-)

The evolution of the shared interface should be done
in new shared assemblies:

// api.dll (base shared assembly, version 1)
public interface IAPI {
}

// api2.dll (version 2)
// inherits from IAPI
public interface IAPI2 : IAPI {
}

// api3.dll (version 3)
// inherits from IAPI2
public interface IAPI3 : IAPI2 {
}

....

bye
Rob

mdb

11/2/2004 4:00:00 PM

0

Robert Jordan <robertj@gmx.net> wrote in
news:cltv6m$bnp$00$1@news.t-online.com:

> mdb wrote:
>
>> I'm writing a client/server distributed application that will have
>> many clients talking back to one central server. If in the future, I
>> need to make a change to the client or server code, and the .NET
>> assembly version changes, will this break the remoting even if none
>> of the remoting calls change?
>
> I understood from your previous posts that you're already using
> (or planing to use) a shared interface assembly.
>
> As far you don't change that assembly no version problems are
> expected, unless you break the semantics, of course ;-)

OK I tested this and apparently, different assembly version numbers don't
cause any problem at all?? I am able to successfully connect to a server
with different assembly versions than what I have on the client... I
thought I had read somewhere that different assembly versions would cause
problems. Do the problems only crop up when there are different function
or class definitions?

-mdb

Ken Kolda

11/2/2004 4:26:00 PM

0

If you are not using strongly-signed assemblies then differing version
numbers will not make a difference. That said, if the interface of the
object changes, then obviously that can cause problems.

Ken


"mdb" <m_b_r_a_y@c_t_i_u_s_a__d0t__com> wrote in message
news:Xns95956FE2AD345mbrayctiusacom@207.46.248.16...
> Robert Jordan <robertj@gmx.net> wrote in
> news:cltv6m$bnp$00$1@news.t-online.com:
>
> > mdb wrote:
> >
> >> I'm writing a client/server distributed application that will have
> >> many clients talking back to one central server. If in the future, I
> >> need to make a change to the client or server code, and the .NET
> >> assembly version changes, will this break the remoting even if none
> >> of the remoting calls change?
> >
> > I understood from your previous posts that you're already using
> > (or planing to use) a shared interface assembly.
> >
> > As far you don't change that assembly no version problems are
> > expected, unless you break the semantics, of course ;-)
>
> OK I tested this and apparently, different assembly version numbers don't
> cause any problem at all?? I am able to successfully connect to a server
> with different assembly versions than what I have on the client... I
> thought I had read somewhere that different assembly versions would cause
> problems. Do the problems only crop up when there are different function
> or class definitions?
>
> -mdb

mdb

11/2/2004 5:45:00 PM

0

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in
news:eL6UDjPwEHA.2976@tk2msftngp13.phx.gbl:

> If you are not using strongly-signed assemblies then differing version
> numbers will not make a difference. That said, if the interface of the
> object changes, then obviously that can cause problems.

But only if the function signatures change, right? In other words, if I
add functionality to the server by ONLY adding new functions, and not
changing existing functions, then it shouldn't prevent older clients from
connecting and using the functions they know about, right?

-mdb

Ken Kolda

11/2/2004 6:48:00 PM

0

Yes, I believe that should work as you expect. I'd experiment to verify
though.

Ken


"mdb" <m_b_r_a_y@c_t_i_u_s_a__d0t__com> wrote in message
news:Xns959581B5E5713mbrayctiusacom@207.46.248.16...
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in
> news:eL6UDjPwEHA.2976@tk2msftngp13.phx.gbl:
>
> > If you are not using strongly-signed assemblies then differing version
> > numbers will not make a difference. That said, if the interface of the
> > object changes, then obviously that can cause problems.
>
> But only if the function signatures change, right? In other words, if I
> add functionality to the server by ONLY adding new functions, and not
> changing existing functions, then it shouldn't prevent older clients from
> connecting and using the functions they know about, right?
>
> -mdb