Does version numbers matter for private assemblies?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

The CLR loader does not check version numbers when loading a referenced private assembly, at least this is wha
Microsoft claims (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorials/html/Binding_Policy.asp)

However, I am experiencing a strange behaviour:
I deploy all my assemblies in a private path
In my initial deployment assembly A(version 6.0.0.1) references assembly B(version 6.0.0.1) and everything works fine
If I deploy assembly B(version 7.0.0.1) without rebuilding assembly A, I get a TypeLoadException

This is even stranger
Assembly A(version 6.0.0.1) also references private assembly C(version 1.0.0.1)
If I deploy assembly C(version 1.1.0.1) without rebuilding assembly A, I also get a TypeLoadException

So, does the CLR loader check version numbers or not; How can I override this behaviour (bindingRedirect will not work because these are private assemblies)

Thanks in advance
 
On the CF compatibility is preserved only for dlls where the revision has
changed... In other words when you update a dll make sure that the
major.minor.build numbers are the same as what the EXE was compiled
against...

Note this behaviour is also true for satellite assemblies...

Unfortunately, as far as I know, there is no way to override this
behaviour...

Cheers
Daniel


Strider said:
The CLR loader does not check version numbers when loading a referenced
Click to expand...
private assembly, at least this is what
Microsoft claims (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorial
s/html/Binding_Policy.asp).

However, I am experiencing a strange behaviour:
I deploy all my assemblies in a private path.
In my initial deployment assembly A(version 6.0.0.1) references assembly
Click to expand...
B(version 6.0.0.1) and everything works fine.
If I deploy assembly B(version 7.0.0.1) without rebuilding assembly A, I get a TypeLoadException.

This is even stranger:
Assembly A(version 6.0.0.1) also references private assembly C(version 1.0.0.1).
If I deploy assembly C(version 1.1.0.1) without rebuilding assembly A, I also get a TypeLoadException.

So, does the CLR loader check version numbers or not; How can I override
Click to expand...
this behaviour (bindingRedirect will not work because these are private
assemblies).
 
Here is a copy of previously posted message to this newsgroup:

------------------------------------------------------------------------
On Compact Framework, there is no configurable policy.

On the Desktop Framework, as you are obviously aware, it is possible to
configure policy for individual applications (or to set system wide
settings) such that applications compiled against one version of an
assembly will run against different versions of the same assembly.

Do give developers the same benefit on Compact Framework, a certain level
of policy has been "hard coded".

Version numbers are a four part construct in .NET Frameworks, consisting of
Major.Minor.Build.Revision. On the Compact Framework, assemblies that
differ only in revision are considered compatible. Therefore, if you're
wanting to replace a single component in your project, you should make
changes only to its revision.

It's important to note that, by default, Visual Studio sets both the Build
and the Revision on assemblies. To change this behavior, you can edit the
file "AssemblyInfo.cs", which is automatically added to your C# project,
and change the line:
[assembly: AssemblyVersion("1.0.*")] to
[assembly: AssemblyVersion("1.0.0.0")]

Jeremy Hance
NET Compact Framework
------------------------------------------------------------------------


Pavel Treskunov
.NET Compact Framework
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Thread-Topic: Does version numbers matter for private assemblies?
thread-index: AcRBpYja+EoynW9OTWWiDbZYmXdN9A==
X-WN-Post: microsoft.public.dotnet.framework.compactframework
From: "=?Utf-8?B?U3RyaWRlcg==?=" <[email protected]>
Subject: Does version numbers matter for private assemblies?
Date: Mon, 24 May 2004 08:41:09 -0700
Lines: 15
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
Path: cpmsftngxa10.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:53834
NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

The CLR loader does not check version numbers when loading a referenced
Click to expand...
private assembly, at least this is what
Microsoft claims
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorial
s/html/Binding_Policy.asp).

However, I am experiencing a strange behaviour:
I deploy all my assemblies in a private path.
In my initial deployment assembly A(version 6.0.0.1) references assembly
B(version 6.0.0.1) and everything works fine.
If I deploy assembly B(version 7.0.0.1) without rebuilding assembly A, I
get a TypeLoadException.

This is even stranger:
Assembly A(version 6.0.0.1) also references private assembly C(version
1.0.0.1).
If I deploy assembly C(version 1.1.0.1) without rebuilding assembly A, I
also get a TypeLoadException.

So, does the CLR loader check version numbers or not; How can I override
this behaviour (bindingRedirect will not work because these are private
assemblies).

Thanks in advance
 
The bindingRedirect attribute does works for private assemblies. Make
sure to use public key token in assemblyIdentity element. That you can
get using sn -t your.dll. If that doesn't work, get it after puting
DLL from GAC (right click on DLL in GAC to see its publick key token.
Assembly name in assemblyIdentity is same as DLL name without DLL
extention by default.




Regards,
Shital.
http://www.ShitalShah.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ernest Hemingway, when asked what was the most frightening thing he
ever encountered, answered: "A blank sheet of paper."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Here is a copy of previously posted message to this newsgroup:

------------------------------------------------------------------------
On Compact Framework, there is no configurable policy.

On the Desktop Framework, as you are obviously aware, it is possible to
configure policy for individual applications (or to set system wide
settings) such that applications compiled against one version of an
assembly will run against different versions of the same assembly.

Do give developers the same benefit on Compact Framework, a certain level
of policy has been "hard coded".

Version numbers are a four part construct in .NET Frameworks, consisting of
Major.Minor.Build.Revision. On the Compact Framework, assemblies that
differ only in revision are considered compatible. Therefore, if you're
wanting to replace a single component in your project, you should make
changes only to its revision.

It's important to note that, by default, Visual Studio sets both the Build
and the Revision on assemblies. To change this behavior, you can edit the
file "AssemblyInfo.cs", which is automatically added to your C# project,
and change the line:
[assembly: AssemblyVersion("1.0.*")] to
[assembly: AssemblyVersion("1.0.0.0")]

Jeremy Hance
NET Compact Framework
------------------------------------------------------------------------


Pavel Treskunov
.NET Compact Framework
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Thread-Topic: Does version numbers matter for private assemblies?
thread-index: AcRBpYja+EoynW9OTWWiDbZYmXdN9A==
X-WN-Post: microsoft.public.dotnet.framework.compactframework
From: "=?Utf-8?B?U3RyaWRlcg==?=" <[email protected]>
Subject: Does version numbers matter for private assemblies?
Date: Mon, 24 May 2004 08:41:09 -0700
Lines: 15
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
Path: cpmsftngxa10.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:53834
NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

The CLR loader does not check version numbers when loading a referenced
Click to expand...
private assembly, at least this is what
Microsoft claims
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptutorial
s/html/Binding_Policy.asp).

However, I am experiencing a strange behaviour:
I deploy all my assemblies in a private path.
In my initial deployment assembly A(version 6.0.0.1) references assembly
B(version 6.0.0.1) and everything works fine.
If I deploy assembly B(version 7.0.0.1) without rebuilding assembly A, I
get a TypeLoadException.

This is even stranger:
Assembly A(version 6.0.0.1) also references private assembly C(version
1.0.0.1).
If I deploy assembly C(version 1.1.0.1) without rebuilding assembly A, I
also get a TypeLoadException.

So, does the CLR loader check version numbers or not; How can I override
this behaviour (bindingRedirect will not work because these are private
assemblies).

Thanks in advance
Click to expand...
 
Back
Top