This isn't really a remoting question, but I'll bite. Whenever you change an
interface, you require all referenced code to be recompiled. A definite
breaking change. But it appears that what you need to do will be a breaking
change anyhow, so it doesn't matter. I would just start fresh; it doesn't
appear that you would gain anything by the new interface extending the old
one. I would also make a couple suggestions:
Your interface's methods take an amazing number of parameters, which isn't
the best thing. You might want to create a simple class (or struct) that
contains the data you need to pass and have the interface's methods accept an
object of that type as its sole parameter. Put the implementation of this
object in a different assembly from the interface to allow you to more easily
change what information is kept in that object without disturbing the
interface.
You might also consider having your interface take an IDictionary object as
its sole parameter. Your callers can define whatever key value pairs they
want to pass via the interface. You lose type safety, but you gain extreme
flexibility for the types of data passed.
[quoted text, click to view] "Rick" wrote:
> Let me preface my question by stating that I'm a remoting newbie...
> I've inherited a project that the first version was designed and coded
> by an outside consulting company. I've been asked to make some changes
> [snip]
> I've got a client and a server that implement a common interface:
> > The requested change will require an additional field in the Activity
> object (int FileType). Is the best solution to create a new assembly
> with a new interface and a new Activity object, inheriting from the
> old? The odd thing (to me) about this is, if I inherit the old
> interface in the new one, I still have to implement the old methods in
> the new client. I understand the server would need the old
> implmentation for backwards compatibility.
>
> Hope this makes sense....
>
> ANY suggestions would be greatly appreciated!!
>