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.

<DIV>&quot;zak&quot; &lt;***@discussions.microsoft.com&gt; wrote in message
suite of products that have a number of shared assemblies. During
In .NET increment the AssemblyVersion when compatibility has been broken.
Increment only the AssemblyFileVersion when compatibility is maintained.

David

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





Show quoteHide quote

zak wrote:
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.

<DIV>&quot;zak&quot; &lt;***@discussions.microsoft.com&gt; wrote in message
Question is how do I know when compatibility has been broken in order for
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

gradient titlebar in vbdotnet
Print the RichTextBox
Help Clearing data in MaskEditBox Control
dumb question
IIF referencing both conditional parts regardless of condition?
Parsing XML
How to return value in Combobox
Updating Files
Compiled HTML helpfile does not work when application is installed
Naming convention of Variables