Binary Compatibility in .NET

[Guest]

In Visual Basic 6.0, there was a setting for DLL's that would prevent a
developer from breaking binary compatibility of a DLL by changing a function
name, parameters, etc. Warnings would appear at compile time.

Is there any such thing in .NET? I can't seem to find the same type of
setting, but I do want a way to prevent developers from changing signatures
of functions.

Thanks,
Dave P.

 

[Phill. W]

In Visual Basic 6.0, there was a setting for DLL's that would prevent a
developer from breaking binary compatibility of a DLL by changing a
function name, parameters, etc. Warnings would appear at compile time.

Is there any such thing in .NET?

Guess what? There isn't!
(At least not that I've found, after a /lot/ of digging).

VB.Net will compile just whatever you tell it to, and doesn't give a
d*** that you might have just redefined every single method!

Interfaces go /some/ way to protecting against this; you publish (and
fix) the Interface; other Developers implement them. The down side
is that if you actually need to /change/ the Interface, you either have
to get into Assembly Versioning, or you have to rebuild absolutely
*everything* that implements the Interface against the new one.

The only other way /I've/ found to do this is to write "exerciser" classes
for each "main" class; these access every property, method, constructor,
etc. in the "main" class. If you [accidentally] change a method, this class
no longer compiles. It's not pretty and /far/ from error-free, but it's the
"best" I've come up with thus far.

Someone; *please* tell me this feature is coming back in VS'2005...

HTH,
Phill W.

 

[Guest]

Thanks Phil. That's pretty much what I expected.

I'm looking at an application that was converted from Centura/SQL Windows to
VB.NET. Unfortunately, this was an "outsourcing" effort, and the goal was to
do a straight port. No enhancements. No rewrites to take advantage of .NET
architecture. Because of this, we're in for some extra work. We've thought
about using interfaces, but now that the code is done, it will take some
reverse engineering. And you're right - to change the interface will take
some work.

The exerciser code would do it, but you've nailed that one too - not pretty,
and lots of work.

That old "binary compatibility" checkbox in VB6 did the trick. I'm with
you. I hope something like that comes back in VS 2005.

In Visual Basic 6.0, there was a setting for DLL's that would prevent a
developer from breaking binary compatibility of a DLL by changing a
function name, parameters, etc. Warnings would appear at compile time.

Is there any such thing in .NET?

Guess what? There isn't!
(At least not that I've found, after a /lot/ of digging).

VB.Net will compile just whatever you tell it to, and doesn't give a
d*** that you might have just redefined every single method!

Interfaces go /some/ way to protecting against this; you publish (and
fix) the Interface; other Developers implement them. The down side
is that if you actually need to /change/ the Interface, you either have
to get into Assembly Versioning, or you have to rebuild absolutely
*everything* that implements the Interface against the new one.

The only other way /I've/ found to do this is to write "exerciser" classes
for each "main" class; these access every property, method, constructor,
etc. in the "main" class. If you [accidentally] change a method, this class
no longer compiles. It's not pretty and /far/ from error-free, but it's the
"best" I've come up with thus far.

Someone; *please* tell me this feature is coming back in VS'2005...

HTH,
Phill W.