"neerajb@noida.nospamhcltech.com"
<neerajbnoidanospamhcltechcom@discussions.microsoft.com>'s
wild thoughts were released on Mon, 21 Nov 2005 04:03:03
-0800 bearing the following fruit:
>Hi
>
[quoted text clipped - 3 lines]
>
>What should i do?I want to maintain the Binary compatibility
Maintain compatability then. The issue is that the exe you
compile referencing the new dll will fail if it is installed
on a PC that still has the old DLL. Avoiding this can be
difficult.
If you break compatability then existing exes referencing
the old dll can still run (side be side if need be) with
exes referencing the new dll. This is probably the prefered
method.
Jan Hyde (VB MVP)

Signature
Foresight: Sage's Saga (J. A. Mc)
[Abolish the TV Licence - http://www.tvlicensing.biz/]
Wendell Buckner - 22 Nov 2005 16:09 GMT
If you have other executables that are dependent on this DLL then I would
not "break" the DLL... I would create a new method with the desired
additional parameters that I needed... If you only have one client for the
DLL then I don't see any problem with "breaking" the DLL... I personally
don't "break" DLL's anymore because I have so many different clients
dependent on the DLL's that I create that it's more important for me to
maintain backward compatibility...
In my development phase I set a DLL to either no compatibility or project
compatibility until a DLL is released then it always set to binary
compatibility...
> "neerajb@noida.nospamhcltech.com"
> <neerajbnoidanospamhcltechcom@discussions.microsoft.com>'s
[quoted text clipped - 20 lines]
>
> Jan Hyde (VB MVP)