Assembly versioning and product updates

[Dathon]

I have an application that is comprised of multiple dll's and exe's, all with
strong names. Let's say that all of these applications use a utility library
Utility.dll, and let's say the version of Utility.dll is 1.0.0.0.

I then make a small change to the Utility library, which I want to push out
to uses in the form of a patch. Since it's a minor change, I increment the
version of the Utility assembly to 1.0.0.1.

What I'd like to do is simply push out a fresh copy of Utility.dll.
However, because everything is strong-named, none of the other assemblies
that depend on Utility.dll will accept it, because their manifests all say
they depend on version 1.0.0.0. So instead of pushing out a single file, I
have to push out the whole darn bag o' bits.

Is there some way I can specify that I only want the .NET dependency checker
to look at the major and minor rev in the assembly version number, so that I
can push out minor fixes without needing to push out everything?

[Kevin Yu [MSFT]]

Hi,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to assemblies reference to
newer build of you assembly instead of the old one. If there is any
misunderstandin g, please feel free to let me know.

As far as I know, if your project reference to an assembly which is not
available, the .NET framework will look for the nearest version. Also you
could add some settings in app.config file to make some version to be the
default version your assembly references. For example:

<configuratio n>
<runtime>
<assemblyBindin g xmlns="urn:sche mas-microsoft-com:asm.v1">
<dependentAssem bly>
<assemblyIdenti ty name="MyAssembl y2" culture="neutra l"
publicKeyToken= "307041694a9959 78"/>
<codeBase version="1.0.15 24.23149"
href="FILE://C:/Myassemblies/MyAssembly2.dll "/>
</dependentAssemb ly>
</assemblyBinding >
</runtime>
</configuration>

For more information, you can try to check the following link:

http://support.microsoft.com/default...b;en-us;837908

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi,

You can also try Assembly Versions Redirection. Please check the following
links:

http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconassemblyve rsionredirectio n.asp

http://msdn.microsoft.com/library/de...us/cpgenref/ht
ml/gngrfAssemblyId entity.asp

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Richard Grimes [MVP]]

Dathon wrote:

I then make a small change to the Utility library, which I want to
push out to uses in the form of a patch. Since it's a minor change,
I increment the version of the Utility assembly to 1.0.0.1.

What I'd like to do is simply push out a fresh copy of Utility.dll.
However, because everything is strong-named, none of the other
assemblies that depend on Utility.dll will accept it, because their
manifests all say they depend on version 1.0.0.0. So instead of
pushing out a single file, I have to push out the whole darn bag o'
bits.
Yup, that's the way its designed to work!
Is there some way I can specify that I only want the .NET dependency
checker to look at the major and minor rev in the assembly version
number, so that I can push out minor fixes without needing to push
out everything?

Well, sort of. If the utility.dll assembly is installed in the GAC you can
install a publisher policy file into the GAC which will redirect all
requests for 1.0.0.0 to 1.0.0.1 for all applications. Publisher policy files
are really only intended for critical changes like security updates. See
http://www.grimes.demon.co.uk/workshops/fusWSSix.htm for details.

For individual applications you can redirect versions through the
application's config file
(http://www.grimes.demon.co.uk/workshops/fusWSThree.htm).

However, the intended way to update assemblies is as you say to "push out
the whole darn bag o' bits"

Richard
--
www.richardgrimes.com
my email ev******@zicf.b et is encrypted with ROT13 (www.rot13.org)