.NET DLL "Hell"

  • Thread starter Thread starter Pawe³
  • Start date Start date
P

Pawe³

Hi!
My other problem: We are building a large system for just a few customers.
So we made bug fixes and improvements frequently. We have many .dll's and
some plug-in framework.
The problem is that, when some component references another, within its
manifest referenced .dll is given with its full version number, with
revision and build numbers. So when this .dll is changed to newer version,
all the others must be recompiled all together.
Some kind of solution would be to mark a .dll with fixed version number, but
this is not good at all. We need the version information, and version
numbers must changed to make proper updates.
We have some fixed framework, and if we fix a bug, we just want to place a
newer version of component, and all of rest .dll's should work. Especially
that our customers wrote their own plug-ins and we dont want then to
recompile their code.

How to accomplish this?.. It would be nice, if within the .dll manifest we
can refer to other .dll with partialy given version, like 1.1.*.* , or
1.*.*.* - so when no crucial interfaces are broken, we can maintain big
version number.

Thanks for any info and help.
Paul
 
You have to nail down those assembly versions because of the references, but
you can use file version to identify different assemblies (using
AssemblyFileVersion). I'd recommend that you always increment
AssemblyFileVersion in new versions anyway because it's the file version
that determines whether an existing file gets replaced by a new one during
an install (outside of the GAC).
 
Thanks!
And can AssemblyFileVersion be "autoincremented" by VS ?.. like "1.0.*" ?..

Phil Wilson said:
You have to nail down those assembly versions because of the references,
but
you can use file version to identify different assemblies (using
AssemblyFileVersion). I'd recommend that you always increment
AssemblyFileVersion in new versions anyway because it's the file version
that determines whether an existing file gets replaced by a new one during
an install (outside of the GAC).
--
Phil Wilson [MVP Windows Installer]
----
Pawe³ said:
Hi!
My other problem: We are building a large system for just a few
customers.
So we made bug fixes and improvements frequently. We have many .dll's and
some plug-in framework.
The problem is that, when some component references another, within its
manifest referenced .dll is given with its full version number, with
revision and build numbers. So when this .dll is changed to newer
version,
all the others must be recompiled all together.
Some kind of solution would be to mark a .dll with fixed version number, but
this is not good at all. We need the version information, and version
numbers must changed to make proper updates.
We have some fixed framework, and if we fix a bug, we just want to place
a
newer version of component, and all of rest .dll's should work.
Especially
that our customers wrote their own plug-ins and we dont want then to
recompile their code.

How to accomplish this?.. It would be nice, if within the .dll manifest
we
can refer to other .dll with partialy given version, like 1.1.*.* , or
1.*.*.* - so when no crucial interfaces are broken, we can maintain big
version number.

Thanks for any info and help.
Paul
Click to expand...
Click to expand...
 
Doesn't look like it. It gives an error like "warning CS1607: Assembly
generation -- The version '1.*.*.0' specified for the 'file version' is not
in the normal 'major.minor.build.revision' format" and ignores it.
--
Phil Wilson [MVP Windows Installer]
----
Pawe³ said:
Thanks!
And can AssemblyFileVersion be "autoincremented" by VS ?.. like "1.0.*" ?..

Phil Wilson said:
You have to nail down those assembly versions because of the references,
but
you can use file version to identify different assemblies (using
AssemblyFileVersion). I'd recommend that you always increment
AssemblyFileVersion in new versions anyway because it's the file version
that determines whether an existing file gets replaced by a new one during
an install (outside of the GAC).
--
Phil Wilson [MVP Windows Installer]
----
Pawe³ said:
Hi!
My other problem: We are building a large system for just a few
customers.
So we made bug fixes and improvements frequently. We have many .dll's and
some plug-in framework.
The problem is that, when some component references another, within its
manifest referenced .dll is given with its full version number, with
revision and build numbers. So when this .dll is changed to newer
version,
all the others must be recompiled all together.
Some kind of solution would be to mark a .dll with fixed version
Click to expand...
number,
but
this is not good at all. We need the version information, and version
numbers must changed to make proper updates.
We have some fixed framework, and if we fix a bug, we just want to place
a
newer version of component, and all of rest .dll's should work.
Especially
that our customers wrote their own plug-ins and we dont want then to
recompile their code.

How to accomplish this?.. It would be nice, if within the .dll manifest
we
can refer to other .dll with partialy given version, like 1.1.*.* , or
1.*.*.* - so when no crucial interfaces are broken, we can maintain big
version number.

Thanks for any info and help.
Paul
Click to expand...
Click to expand...
Click to expand...
 
Hi Pawe,

Did you take a look at versioning policies ? I think that those policies
can help you to solve your issue.
If you have any more questions, please feel free to contact me.

Regards,
Bart
 
Pawe,
Have you considered a publisher policy? A pub policy is a special
type of DLL that is placed in the GAC, it will contain compatibility
statements for different versions of the same assembly. In other
words you can put a blanket statement saying all assemblies compiled
against ver 1.1.0.1 of a particular assembly should use ver. 1.1.0.3.
This will affect all assemblies on the machine regardless if original
dll was private or installed in the GAC. If you simply include a
publisher policy and install it in the GAC with each fix this should
take care of your issue. You could also do nearly the same thing
(administratively) in the machine.config using the .net config tool in
the control panel and configure binding for the assembly.

Note: I believe the first 2 parts of the ver# need to be same. i.e.
cannot redirect ver 1.1.* to 1.2.*

Cecil Howell
MCSD, MCT
 
I'm ancticpiating similar problems....

I am expecting to be able to fix them using the information in the MSDN .NET
Framework Developers Guide entitled "Redirecting Assembly Versions"

Cheers
Stewart
 
Back
Top