.NET how to check binary compatability

[Guest]

we have a suite of products that have a number of shared assemblies. During
development and support the shared assemblies code will change . I want to
control the versioning, so if the code chnages are binary compatable ( i.e
interfaces have not changed) then we can retain the same version number for
the assembly and just
change the hot fix number in the assembly. But how do I know that binary
compatability has been maintained to confidently do this.

In VB6 we had the ability to verify components by using binary compatability
checks in the VB6 project

I can't find anything similar in .NET to allow me to verify code changes
have not changed the interfaces, there is a lot about how good .NET is at
managing versions of assemblies in the GAC , but I can't see anything that
will at least warn me that the interfaces have changed without rebuilding
all the
applications and assemblies that are dependant on the modified code.

The question arose when we we were trying to determine what is the best way
to deploy the assemblies. One camp says put everything in a single BIN
directory another camp says have a bin for each product duplicating the
DLL's.

 

[David Browne]

<DIV>&quot;zak&quot; &lt;[email protected]&gt; wrote in message

development and support the shared assemblies code will change . I want to
control the versioning, so if the code chnages are binary compatable ( i.e
interfaces have not changed) then we can retain the same version number
for
the assembly and just
change the hot fix number in the assembly. But how do I know that binary
compatability has been maintained to confidently do this.

In VB6 we had the ability to verify components by using binary
compatability
checks in the VB6 project
. . .

In .NET increment the AssemblyVersion when compatibility has been broken.
Increment only the AssemblyFileVersion when compatibility is maintained.

David

 

[Guest]

My Question is how do I know when compatibility has been broken in order for
me to do this.

 

[Tom Shelton]

My Question is how do I know when compatibility has been broken in order for
me to do this.

zak - it seems to me one way you could know is to setup a testing
mechanism (nunit maybe?). When you create a new version of the dll,
you could run it through the test suite - if it is still compatible
then your tests should succed, otherwise you'll get exceptions, etc.

Just a thought.

 

[David Browne]

<DIV>&quot;zak&quot; &lt;[email protected]&gt; wrote in message

me to do this.

I think that's a programmer task. You could examine the public types and
see if any types, methods or arguments have been removed. But this wouldn't
catch behavioral changes that should require recompilation. Moreover you
may choose to not change the AssemblyVersion on a particular change in order
to enable seamless deployment of a non-breaking fix to an important client.

David