Making Local Assemblies of different versions Coexist

[Mart Rogers]

We have a situation where we have decided (in an attempt to keep things
simple) to stick to local assemblies rather than global ones.
However we now have the following situation looming

AssyA depends on AssyB depends on AssyD version 1
AssyA depends on AssyC depends on AssyD version 2

Obviously we cannot copy both versions of AssyD to the AssyA's bin
directory. Is the only sensible way around this (rather than going the GAC
route) to name the Assemblies by version number (e.g. AssyD001 andAssyD002).

How much of a development pain is the GAC route - all that key generation
stuff seems overkill for our 'local' libraries.

Many Thanks.

[SR]

Hi
I dont think that u need to rename the assemblies. In
fact if i remember right, if the name of an assembly is
changed after it was compiled, then it will throw an
exception.

Do note that ".Net by default looks for the same version
of the assembly even if a new version is available. So i
think if u use the structure properly you can achieve
this."

so you can achieve what you want by

Build the AssemblyB with Version X of AssemblyD
Build the AssemblyC with Version Y of AssemblyD
1)Place the different versions of Assembly D in the
different subdirectories of the bin folder with the
version name as the sub-directory name.

2) Then use the CodeBase Element in the Config file to
specify the File Path for each version of Assembly D

When ur app is run, Assembly B will search with Version X
of AssemblyD( coz that was how it was built) and the code
base will ensure that it gets the version X

As Assembly C was built with Version Y of Assembly D,
this Version Y will be searched and again code base will
ensure that the correct version is got
Check out the links

General Notes on Assembly Location :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconhowruntimelocatesassemblies.asp

Locating the Assembly through Codebases :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconstep4locatingassemblythroughcodebaseso
rprobing.asp

How to Specify Code Base :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/cpgenref/html/gngrfcodebase.asp
regards,

sr

-----Original Message-----
We have a situation where we have decided (in an attempt to keep thingssimple) to stick to local assemblies rather than global ones.However we now have the following situation looming

AssyA depends on AssyB depends on AssyD version 1
AssyA depends on AssyC depends on AssyD version 2

Obviously we cannot copy both versions of AssyD to the AssyA's bindirectory. Is the only sensible way around this (rather than going the GACroute) to name the Assemblies by version number (e.g. AssyD001 andAssyD002).
How much of a development pain is the GAC route - all that key generationstuff seems overkill for our 'local' libraries.

Many Thanks.

.

[Suzanne Cook [MS]]

The version is always checked if both (a) the assembly reference included
the version and (b) the assembly is strongly named. It doesn't matter for
that whether the assembly is in the GAC or elsewhere.

If you intend to only change the version number, and not the rest of the
assembly identity, you need to strongly name it or else use something
besides just the Load context. Otherwise, the version is not part of the
assembly identity, and you'll only get one version loaded and used by both
AssemblyB and AssemblyC.

Plus, as you noticed, compiling against two versions of the same assembly
isn't supported by compilers that I know of yet.

So, my #1 recommendation is to take a hard look at your app and try to make
it use only one version of AssemblyD. Then, have just that one copy in the
ApplicationBase. If that's just not possible, you may want to consider
changing the assembly identity (the simple name or culture for non-strongly
named assemblies, or the simple name/version/public key token/culture for
strongly named assemblies).

Suzanne Cook
My .NET CLR Loader blog: http://blogs.gotdotnet.com/suzcook/
--
Please do not respond directly to this alias. This alias is for newsgroup
purposes only. This posting is provided "AS IS" with no warranties, and
confers no rights.

"Mart Rogers" <ma*********@dev.null> wrote in message
news:be**********@titan.btinternet.com...

"SR" <rs*****@hotmail.com> wrote in message
news:0a****************************@phx.gbl...

Hi
I dont think that u need to rename the assemblies. In
fact if i remember right, if the name of an assembly is
changed after it was compiled, then it will throw an
exception.
Indeed, I intended that the name of the assembly would include it version
from the start.

Do note that ".Net by default looks for the same version
of the assembly even if a new version is available. So i
think if u use the structure properly you can achieve
this."

I have read confusing information on this. The dependent version number

is stored in the manifest of the parent assembly it is true, but articles on
the MS site seem to imply that 'version checking does not apply unless an
assembly is in the GAC' - what is your view on this? Does the runtime use
the version number from the manifest for local assembly dependencies?

so you can achieve what you want by

Build the AssemblyB with Version X of AssemblyD
Build the AssemblyC with Version Y of AssemblyD

The problem is that I cannot build. Initially I get a 'cannot copy

assembly d because you have two versions with the same name' message. When I switch Copy Local to false in the references from Assembly B & C (to D) I then get :

The dependency AssemblyD could not be found
The dependency AssemblyD could not be found

So I cannot get in a position to try the codebase technique out (at runtime) because I cannot overcome the compilation name clash.
Any comments gratefully accepted.

1)Place the different versions of Assembly D in the
different subdirectories of the bin folder with the
version name as the sub-directory name.

2) Then use the CodeBase Element in the Config file to
specify the File Path for each version of Assembly D

When ur app is run, Assembly B will search with Version X
of AssemblyD( coz that was how it was built) and the code
base will ensure that it gets the version X

As Assembly C was built with Version Y of Assembly D,
this Version Y will be searched and again code base will
ensure that the correct version is got
Check out the links

General Notes on Assembly Location :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconhowruntimelocatesassemblies.asp

Locating the Assembly through Codebases :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconstep4locatingassemblythroughcodebaseso
rprobing.asp

How to Specify Code Base :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/cpgenref/html/gngrfcodebase.asp
regards,

sr

-----Original Message-----
We have a situation where we have decided (in an attempt

to keep things

simple) to stick to local assemblies rather than global

ones.

However we now have the following situation looming

AssyA depends on AssyB depends on AssyD version 1
AssyA depends on AssyC depends on AssyD version 2

Obviously we cannot copy both versions of AssyD to the

AssyA's bin

directory. Is the only sensible way around this (rather

than going the GAC

route) to name the Assemblies by version number (e.g.

AssyD001 andAssyD002).

How much of a development pain is the GAC route - all

that key generation

stuff seems overkill for our 'local' libraries.

Many Thanks.

.

[Mart Rogers]

"Suzanne Cook [MS]" <su*****@online.microsoft.com> wrote in message
news:OY*************@TK2MSFTNGP11.phx.gbl...

The version is always checked if both (a) the assembly reference included
the version and (b) the assembly is strongly named. It doesn't matter for
that whether the assembly is in the GAC or elsewhere.
Thanks - my confusion arose because I understood that if an assembly stores
the version of its references in its manifest then it can use this version
info to determine what to load. This is not true. It appears that all
referencing assemblies do seem to store this version info in their manifest
(even weakly named ones) but it just does not get used unless the whole of
the strong name is present.

If you intend to only change the version number, and not the rest of the
assembly identity, you need to strongly name it or else use something
besides just the Load context. Otherwise, the version is not part of the
assembly identity, and you'll only get one version loaded and used by both
AssemblyB and AssemblyC.

Plus, as you noticed, compiling against two versions of the same assembly
isn't supported by compilers that I know of yet.

So, my #1 recommendation is to take a hard look at your app and try to make it use only one version of AssemblyD. Then, have just that one copy in the ApplicationBase. If that's just not possible, you may want to consider
changing the assembly identity (the simple name or culture for non-strongly named assemblies, or the simple name/version/public key token/culture for
strongly named assemblies).

Suzanne Cook
My .NET CLR Loader blog: http://blogs.gotdotnet.com/suzcook/
--
Please do not respond directly to this alias. This alias is for newsgroup
purposes only. This posting is provided "AS IS" with no warranties, and
confers no rights.

"Mart Rogers" <ma*********@dev.null> wrote in message
news:be**********@titan.btinternet.com...

"SR" <rs*****@hotmail.com> wrote in message
news:0a****************************@phx.gbl...

Hi
I dont think that u need to rename the assemblies. In
fact if i remember right, if the name of an assembly is
changed after it was compiled, then it will throw an
exception.

Indeed, I intended that the name of the assembly would include it version from the start.

Do note that ".Net by default looks for the same version
of the assembly even if a new version is available. So i
think if u use the structure properly you can achieve
this."

I have read confusing information on this. The dependent version number

is

stored in the manifest of the parent assembly it is true, but articles on the MS site seem to imply that 'version checking does not apply unless an assembly is in the GAC' - what is your view on this? Does the runtime use the version number from the manifest for local assembly dependencies?

so you can achieve what you want by

Build the AssemblyB with Version X of AssemblyD
Build the AssemblyC with Version Y of AssemblyD

The problem is that I cannot build. Initially I get a 'cannot copy

assembly

d because you have two versions with the same name' message. When I

switch

Copy Local to false in the references from Assembly B & C (to D) I then

get

:

The dependency AssemblyD could not be found
The dependency AssemblyD could not be found

So I cannot get in a position to try the codebase technique out (at

runtime)

because I cannot overcome the compilation name clash.
Any comments gratefully accepted.

1)Place the different versions of Assembly D in the
different subdirectories of the bin folder with the
version name as the sub-directory name.

2) Then use the CodeBase Element in the Config file to
specify the File Path for each version of Assembly D

When ur app is run, Assembly B will search with Version X
of AssemblyD( coz that was how it was built) and the code
base will ensure that it gets the version X

As Assembly C was built with Version Y of Assembly D,
this Version Y will be searched and again code base will
ensure that the correct version is got
Check out the links

General Notes on Assembly Location :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconhowruntimelocatesassemblies.asp

Locating the Assembly through Codebases :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-
us/cpguide/html/cpconstep4locatingassemblythroughcodebaseso
rprobing.asp

How to Specify Code Base :
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/cpgenref/html/gngrfcodebase.asp
regards,

sr
>-----Original Message-----
>We have a situation where we have decided (in an attempt
to keep things
>simple) to stick to local assemblies rather than global
ones.
>However we now have the following situation looming
>
>AssyA depends on AssyB depends on AssyD version 1
>AssyA depends on AssyC depends on AssyD version 2
>
>Obviously we cannot copy both versions of AssyD to the
AssyA's bin
>directory. Is the only sensible way around this (rather
than going the GAC
>route) to name the Assemblies by version number (e.g.
AssyD001 andAssyD002).
>
>How much of a development pain is the GAC route - all
that key generation
>stuff seems overkill for our 'local' libraries.
>
>Many Thanks.
>
>
>
>.
>