VB.NET Assembly Compatability

[Nak]

Hi there,

I was wondering if anyone knew of a way to maintain compatability with
assemblies providing the interfaces remains the same? At the moment if I
re-compile an assembly without actually changing an interface it breaks
compatability, forcing all of my consuming assemblies to need recompiling.
I know this could be done with VB6, what about .NET?

Nick.

[Carlos J. Quintero [.NET MVP]]

If you are sure that you are not breaking compability (VS.NET, on the
contrary to VB6, does not offer yet a tool to verify this), you need to keep
the value of the AssemblyVersion attribute of the AssemblyInfo.vb file,
because by default it is changed on each build:

<Assembly: AssemblyVersion ("1.0.*")>

So, change it to, say:

<Assembly: AssemblyVersion ("1.0.0.0")>

and don´t change it until you break compatibility.

You should also add another attribute that is not added by default:

<Assembly: AssemblyFileVer sion("1.0.0.5") >

which is the classic Win32 file version (shown in Windows Explorer), not the
assembly version (shown in GAC viewer), and you change this on each build,
to be able to distinguish each build now that the assembly version is the
same (if ommited, the assembly file version is set to the assembly version).

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Hi there,

I was wondering if anyone knew of a way to maintain compatability with
assemblies providing the interfaces remains the same? At the moment if I
re-compile an assembly without actually changing an interface it breaks
compatability, forcing all of my consuming assemblies to need recompiling.
I know this could be done with VB6, what about .NET?

Nick.

[Nak]

Hi Carlos,

Excellent! Cheers.

Nick.

"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAM sogecable.com> wrote in
message news:O$******** ******@TK2MSFTN GP14.phx.gbl...

If you are sure that you are not breaking compability (VS.NET, on the
contrary to VB6, does not offer yet a tool to verify this), you need to
keep the value of the AssemblyVersion attribute of the AssemblyInfo.vb
file, because by default it is changed on each build:

<Assembly: AssemblyVersion ("1.0.*")>

So, change it to, say:

<Assembly: AssemblyVersion ("1.0.0.0")>

and don´t change it until you break compatibility.

You should also add another attribute that is not added by default:

<Assembly: AssemblyFileVer sion("1.0.0.5") >

which is the classic Win32 file version (shown in Windows Explorer), not
the assembly version (shown in GAC viewer), and you change this on each
build, to be able to distinguish each build now that the assembly version
is the same (if ommited, the assembly file version is set to the assembly
version).

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Hi there,

I was wondering if anyone knew of a way to maintain compatability with
assemblies providing the interfaces remains the same? At the moment if I
re-compile an assembly without actually changing an interface it breaks
compatability, forcing all of my consuming assemblies to need
recompiling. I know this could be done with VB6, what about .NET?

Nick.

[Nak]

Hi there,

Thinking more about this solution it doesn't seem as nice as I had first
thought. I would like to keep automatic versioning as I've relied on it for
quite a while now, and actually remembering to change the version number
when an interface changes will bound to be too risky for me. So I hunted
around some more and found that the app config file can solve this issue,

<?xml version="1.0"?>
<configuratio n>
<runtime>
<assemblyBindin g
xmlns="urn:sche mas-microsoft-com:asm.v1">
<dependentAssem bly>
<assemblyIdenti ty name="myshareda ssembly"
publicKeyToken= "mysharedassemb lykeytoken" />
<bindingRedirec t oldVersion="1.0 .0.0-1.0.99999.99999 "
newVersion="cur rentversion" />
</dependentAssemb ly>
</assemblyBinding >
</runtime>
</configuration>

So now I can keep compatability while retaining automatic versioning.

Nick.

"Nak" <[e-mail]> wrote in message
news:O%******** ********@TK2MSF TNGP11.phx.gbl. ..

Hi Carlos,

Excellent! Cheers.

Nick.

"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAM sogecable.com> wrote in
message news:O$******** ******@TK2MSFTN GP14.phx.gbl...

If you are sure that you are not breaking compability (VS.NET, on the
contrary to VB6, does not offer yet a tool to verify this), you need to
keep the value of the AssemblyVersion attribute of the AssemblyInfo.vb
file, because by default it is changed on each build:

<Assembly: AssemblyVersion ("1.0.*")>

So, change it to, say:

<Assembly: AssemblyVersion ("1.0.0.0")>

and don´t change it until you break compatibility.

You should also add another attribute that is not added by default:

<Assembly: AssemblyFileVer sion("1.0.0.5") >

which is the classic Win32 file version (shown in Windows Explorer), not
the assembly version (shown in GAC viewer), and you change this on each
build, to be able to distinguish each build now that the assembly version
is the same (if ommited, the assembly file version is set to the assembly
version).

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

Hi there,

I was wondering if anyone knew of a way to maintain compatability
with assemblies providing the interfaces remains the same? At the
moment if I re-compile an assembly without actually changing an
interface it breaks compatability, forcing all of my consuming
assemblies to need recompiling. I know this could be done with VB6, what
about .NET?

Nick.

[Carlos J. Quintero [.NET MVP]]

If you have the control over the apps that call your assembly that approach
will work too, but there are scenarios where you don´t know or control all
the applications that call your assembly, so you would use the other
approach in those scenarios...

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Hi there,

Thinking more about this solution it doesn't seem as nice as I had
first thought. I would like to keep automatic versioning as I've relied
on it for quite a while now, and actually remembering to change the
version number when an interface changes will bound to be too risky for
me. So I hunted around some more and found that the app config file can
solve this issue,

<?xml version="1.0"?>
<configuratio n>
<runtime>
<assemblyBindin g
xmlns="urn:sche mas-microsoft-com:asm.v1">
<dependentAssem bly>
<assemblyIdenti ty name="myshareda ssembly"
publicKeyToken= "mysharedassemb lykeytoken" />
<bindingRedirec t oldVersion="1.0 .0.0-1.0.99999.99999 "
newVersion="cur rentversion" />
</dependentAssemb ly>
</assemblyBinding >
</runtime>
</configuration>

So now I can keep compatability while retaining automatic versioning.

Nick.

[Nak]

Hi there Carlos,

If you have the control over the apps that call your assembly that
approach will work too, but there are scenarios where you don´t know or
control all the applications that call your assembly, so you would use the
other approach in those scenarios...
ACK and appreciated. But I'm just using it to control plugins to help
prevent them from having to be recompiled every time my application
framework changes.

Probably in hindsight I would have drastically modified the way my
Framework is structured but unfortunately at the moment I need to assure
that the plug-ins will at least attempt to run. Maybe I could also check
what version they are compiled against and give the user the ability to only
use 100% upto-date plug-ins but maybe this gives a little too much control!

By the way, it's good to see you in this group, I remember using your
MZ-Tools for VB6, valuable asset that was!

Nick.

"Carlos J. Quintero [.NET MVP]" <ca*****@NOSPAM sogecable.com> wrote in
message news:Of******** ******@tk2msftn gp13.phx.gbl...

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Hi there,

Thinking more about this solution it doesn't seem as nice as I had
first thought. I would like to keep automatic versioning as I've relied
on it for quite a while now, and actually remembering to change the
version number when an interface changes will bound to be too risky for
me. So I hunted around some more and found that the app config file can
solve this issue,

<?xml version="1.0"?>
<configuratio n>
<runtime>
<assemblyBindin g
xmlns="urn:sche mas-microsoft-com:asm.v1">
<dependentAssem bly>
<assemblyIdenti ty name="myshareda ssembly"
publicKeyToken= "mysharedassemb lykeytoken" />
<bindingRedirec t oldVersion="1.0 .0.0-1.0.99999.99999 "
newVersion="cur rentversion" />
</dependentAssemb ly>
</assemblyBinding >
</runtime>
</configuration>

So now I can keep compatability while retaining automatic versioning.

Nick.

[Carlos J. Quintero [.NET MVP]]

"Nak" <[e-mail]> escribió en el mensaje
news:%2******** ********@TK2MSF TNGP10.phx.gbl. ..

By the way, it's good to see you in this group, I remember using your
MZ-Tools for VB6, valuable asset that was!

I have spent the last 3 years or so in forums and newsgroups about .NET
add-ins, and I became MVP for that, I will try to spend more time in general
..NET groups. Now you have MZ-Tools 4.0 for VS.NET, no longer free but quite
cheap, if you want to take a look. I remember that I had the same problem
that you because now the mztools4.dll assembly exposes its API to plug-ins
to provide operation extensions (yeah, plug-ins for a plug-in of VS.NET !)
and since mztools4.dll is not an exe, it can not use a config file, so I
have to use the approach that I suggested, keeping the AsssemblyVersio n
constant while maintaining backwards compatibility.

--

Carlos J. Quintero

MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com