binary compatibility support for .NET assembly

[someone]

Suppose that I have a class in an assembly that is delivered to the user,
what can I do to change the class so that it doesn't break the
binary compatibility? That is, user application can run with recompiling
and relinking.

I know that if I define an interface, and only expose the interface but not
the class which implments the interface, I can add a data member to the
class without breaking the binary compatibility. If the class itself,
rather than the interface is exposed to user, can I still add a data member
to the class without breaking the binary compatibility? What are other
restrictions that won't break the binary compatibility?

In pure C++, adding a data member to a class that is exposed to the user
will break compatibility.

Thanks.

[someone]

Re: binary compatibility support for .NET assembly

[color=blue]
> Suppose that I have a class in an assembly that is delivered to the user,
> what can I do to change the class so that it doesn't break the
> binary compatibility? That is, user application can run with recompiling
> and relinking.[/color]

A mistake: 'with' should be 'without'.

[shreeman-]

RE:-binary compatibility support for .NET assembly

hi
when you are speaking about com and binary
compatibility.A dding an interface only generates a new iid
and does not break the binary compatibility as new version
can use the new features(class with new iid included)
where as the older version still works with their older
version.The compatibility breaks only when you changes the
signatures or remove some interfaces etc.


But with .Net you need not to depend on registry .The only
thing you remember is how are you handling the versioning
and whether you are using private or shared
assemblies.Ther efore you need not have to be worried about
binary compatibility at all because in .net multiple
version can run side by side and even you can specify
which client or application will use which version of the
components.


hope that this helps
shreeman
sndshreeman@red iffmail.com

[color=blue]
>-----Original Message-----
>Suppose that I have a class in an assembly that is[/color]
delivered to the user,[color=blue]
>what can I do to change the class so that it doesn't[/color]
break the[color=blue]
>binary compatibility? That is, user application can run[/color]
with recompiling[color=blue]
>and relinking.
>
>I know that if I define an interface, and only expose the[/color]
interface but not[color=blue]
>the class which implments the interface, I can add a data[/color]
member to the[color=blue]
>class without breaking the binary compatibility. If the[/color]
class itself,[color=blue]
>rather than the interface is exposed to user, can I still[/color]
add a data member[color=blue]
>to the class without breaking the binary compatibility?[/color]
What are other[color=blue]
>restrictions that won't break the binary compatibility?
>
>In pure C++, adding a data member to a class that is[/color]
exposed to the user[color=blue]
>will break compatibility.
>
>Thanks.
>
>
>.
>[/color]

[Niki Estner]

Re: binary compatibility support for .NET assembly

"someone" <somone@somewhe re.com> wrote in
news:%23aWVQdCd EHA.3632@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> Suppose that I have a class in an assembly that is delivered to the user,
> what can I do to change the class so that it doesn't break the
> binary compatibility? That is, user application can run with recompiling
> and relinking.[/color]

..net applications are just-in-time compiled; There is no "linker". The kind
of tasks that used to be done by the linker are done at runtime (by the JIT)
anyway.
[color=blue]
> I know that if I define an interface, and only expose the interface but[/color]
not[color=blue]
> the class which implments the interface, I can add a data member to the
> class without breaking the binary compatibility. If the class itself,
> rather than the interface is exposed to user, can I still add a data[/color]
member[color=blue]
> to the class without breaking the binary compatibility?[/color]

Yes.
[color=blue]
> What are other restrictions that won't break the binary compatibility?[/color]

Don't remove methods, make them private or change their signature if they
are used by the client. You'll get a "MissingMethodE xception" if the JIT
can't find a method that's called in your code.
[color=blue]
> In pure C++, adding a data member to a class that is exposed to the user
> will break compatibility.[/color]

Yep. There are ways around this, but they usually require some work.
That's one of the reasons why .net was invented.

Niki

[Niki Estner]

Re: binary compatibility support for .NET assembly

"Niki Estner" <niki.estner@cu be.net> wrote in
news:ez9YT%23Id EHA.3216@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> "someone" <somone@somewhe re.com> wrote in
> news:%23aWVQdCd EHA.3632@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > Suppose that I have a class in an assembly that is delivered to the[/color][/color]
user,[color=blue][color=green]
> > what can I do to change the class so that it doesn't break the
> > binary compatibility? That is, user application can run with[/color][/color]
recompiling[color=blue][color=green]
> > and relinking.[/color]
>
> .net applications are just-in-time compiled; There is no "linker". The[/color]
kind[color=blue]
> of tasks that used to be done by the linker are done at runtime (by the[/color]
JIT)[color=blue]
> anyway.[/color]

Sorry, that wasn't 100% correct: There is a linker (al.exe) that fuses
modules and resources, but it is rarely used, at least not in a usual
VS-build cycle.

Niki

[someone]

Re: binary compatibility support for .NET assembly

What about enumeration constants defined? if their value is changed, I
assume that the binary compatibility is broken. I know that this is true in
C++.

"Niki Estner" <niki.estner@cu be.net> wrote in message
news:ez9YT%23Id EHA.3216@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> "someone" <somone@somewhe re.com> wrote in
> news:%23aWVQdCd EHA.3632@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > Suppose that I have a class in an assembly that is delivered to the[/color][/color]
user,[color=blue][color=green]
> > what can I do to change the class so that it doesn't break the
> > binary compatibility? That is, user application can run with[/color][/color]
recompiling[color=blue][color=green]
> > and relinking.[/color]
>
> .net applications are just-in-time compiled; There is no "linker". The[/color]
kind[color=blue]
> of tasks that used to be done by the linker are done at runtime (by the[/color]
JIT)[color=blue]
> anyway.
>[color=green]
> > I know that if I define an interface, and only expose the interface but[/color]
> not[color=green]
> > the class which implments the interface, I can add a data member to the
> > class without breaking the binary compatibility. If the class itself,
> > rather than the interface is exposed to user, can I still add a data[/color]
> member[color=green]
> > to the class without breaking the binary compatibility?[/color]
>
> Yes.
>[color=green]
> > What are other restrictions that won't break the binary compatibility?[/color]
>
> Don't remove methods, make them private or change their signature if they
> are used by the client. You'll get a "MissingMethodE xception" if the JIT
> can't find a method that's called in your code.
>[color=green]
> > In pure C++, adding a data member to a class that is exposed to the user
> > will break compatibility.[/color]
>
> Yep. There are ways around this, but they usually require some work.
> That's one of the reasons why .net was invented.
>
> Niki
>
>[/color]

[Niki Estner]

Re: binary compatibility support for .NET assembly

I'm sorry, my first reply was definitely too short; Unfortunately I didn't
find any good article on the subject; So, here's a short list of things I
that came to my mind right now; In general
- You may safely change default values of data members
- You may safely change all private/internal fields of a class/struct
- You may usually add properties or methods to an existing class or struct
(this only hurts the client if it derives a class from that class, and
happens to add a property/method with the same signature)
- You may usually add data members and events to a class or struct, unless
you use binary serialization in your clients (the binary layout changes with
new data members)
- Removing, renaming or changing the type/signature of public/protected
properties/data members/events/methods can cause clients to crash (however
unlike C++ you'll get something like a "MethodNotFound Exception", and no
memory will be overwritten) if (and only if) the client uses that member
- Removing an interface or changing the base class may hurt clients, if the
client casts to that class/interface
- Changing static constants/enums causes clients to break (didn't think of
that before your post)

Of course this list isn't complete, and there are may still be some cases
where even these rules don't work (e.g. if the client tries to invoke a
non-existing method using late-binding; If you add that method, the client
will behave differently). But I hope that this at least gives you a rough
sketch of what is done at compile-time, and what is done at run-time.

In general, if you expect an assembly to change often, using interfaces for
communication is not a bad idea.

Niki

"someone" <somone@somewhe re.com> wrote in
news:eryQiPLdEH A.3572@TK2MSFTN GP10.phx.gbl...[color=blue]
> What about enumeration constants defined? if their value is changed, I
> assume that the binary compatibility is broken. I know that this is true[/color]
in[color=blue]
> C++.
>
> "Niki Estner" <niki.estner@cu be.net> wrote in message
> news:ez9YT%23Id EHA.3216@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > "someone" <somone@somewhe re.com> wrote in
> > news:%23aWVQdCd EHA.3632@TK2MSF TNGP11.phx.gbl. ..[color=darkred]
> > > Suppose that I have a class in an assembly that is delivered to the[/color][/color]
> user,[color=green][color=darkred]
> > > what can I do to change the class so that it doesn't break the
> > > binary compatibility? That is, user application can run with[/color][/color]
> recompiling[color=green][color=darkred]
> > > and relinking.[/color]
> >
> > .net applications are just-in-time compiled; There is no "linker". The[/color]
> kind[color=green]
> > of tasks that used to be done by the linker are done at runtime (by the[/color]
> JIT)[color=green]
> > anyway.
> >[color=darkred]
> > > I know that if I define an interface, and only expose the interface[/color][/color][/color]
but[color=blue][color=green]
> > not[color=darkred]
> > > the class which implments the interface, I can add a data member to[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > class without breaking the binary compatibility. If the class itself,
> > > rather than the interface is exposed to user, can I still add a data[/color]
> > member[color=darkred]
> > > to the class without breaking the binary compatibility?[/color]
> >
> > Yes.
> >[color=darkred]
> > > What are other restrictions that won't break the binary compatibility?[/color]
> >
> > Don't remove methods, make them private or change their signature if[/color][/color]
they[color=blue][color=green]
> > are used by the client. You'll get a "MissingMethodE xception" if the JIT
> > can't find a method that's called in your code.
> >[color=darkred]
> > > In pure C++, adding a data member to a class that is exposed to the[/color][/color][/color]
user[color=blue][color=green][color=darkred]
> > > will break compatibility.[/color]
> >
> > Yep. There are ways around this, but they usually require some work.
> > That's one of the reasons why .net was invented.
> >
> > Niki
> >
> >[/color]
>
>[/color]