VB.NET Assembly Compatability

  • Thread starter Thread starter Nak
  • Start date Start date
N

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.
 
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: AssemblyFileVersion("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
 
Hi Carlos,

Excellent! Cheers.

Nick.

Carlos J. Quintero said:
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: AssemblyFileVersion("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
Click to expand...
 
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"?>
<configuration>
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="mysharedassembly"
publicKeyToken="mysharedassemblykeytoken" />
<bindingRedirect oldVersion="1.0.0.0-1.0.99999.99999"
newVersion="currentversion" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

So now I can keep compatability while retaining automatic versioning.

Nick.
 
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
 
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...
Click to expand...

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.
 
By the way, it's good to see you in this group, I remember using your
MZ-Tools for VB6, valuable asset that was!
Click to expand...

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 AsssemblyVersion
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
 
Back
Top