3

We have application built against .NET 2.0 on machine with .NET 2.0 SP1 installed. The application references some standard .NET assemblies included in .NET SP1 (i.e. System.Xml.dll).

If we run this application on computer with .net 2.0 RTM, the application runs fine, it even uses System.Xml.dll assembly. But when it tries to use method that doesn't exist in 2.0 RTM, but exists in 2.0 SP1 the application throws MethodNotFoundException.

My question is : How does the runtime resolve System.Xml.dll at all?

The assemblies versions differs in revision number (but the major, minor and build parts are equals). That means that 2.0 RTM and 2.0 SP1 assemblies are different in terms of assembly binding process. The runtime should try to find System.Xml.dll 2.0.50727.1378, but it only finds 2.0.50727.42. Then assembly binding process should fail because there can't be any Publisher policy or redirection in Machine.config. But binding works fine. How can it be?

Another one question which follows of the problem described above.

We can't force all our clients to install .NET 2.0 SP1 on their computers. If we ship System.Xml.dll from .NET 2.0 SP1, how can we force our application to use System.Xml.dll shipped with our application?

Update 1: Looks like System.Xml.dll version is 2.0.0.0, not 2.0.50727.x. That describes why the Runtime successfully resolves it. But the second question still applies: Can we ship System.Xml.dll from SP1 with our application and force our application to use it?

Dmitrii Lobanov
  • 4,897
  • 1
  • 33
  • 50
  • The problem of having clients with 2.0 RTM appeared some time ago. We have to chose whether we rewrite our application using only 2.0 RTM functionality, or we can just fix something shipping 2.0 SP1 assemblies. Now the problem is only with `System.Xml.dll` and it looks like it would be much easier to ship assembly from SP1 rather then rewriting our application. – Dmitrii Lobanov Mar 21 '11 at 10:25

2 Answers2

1

If there is no acceptable answers I'll post my own. Hope it helps somebody.

The first question was how does runtime resolves assemblies from service pack.

I've investigated a little more and have read some articles. I mistakenly have taken a look at AssemblyFileVersion instead of AssemblyVersion. For assemblies in .NET 2.0 SP AssemblyFileVersion is 2.0.50727.1378, and for assemblies from .NET 2.0 RTM it's 2.0.50727.42. Yes, they are different, but it is AssemblyFileVersion, not AssemblyVersion. And assembly binding process uses AssemblyVersion only. But AssemblyVersion is 2.0.0.0 for .NET 2.0 RTM and .NET SPx either. So RTM and SPx assemblies are identical in terms of assembly binding process.

I'm still interested why MS hadn't shipped service pack's assemblies with incremented AssemblyVersion? They could ship SP's assemblies with corresponding Publisher policies to redirect assembly binding from RTM to SP. And if clients would like to use RTM versions of assemblies, they can ignore publisher policy for particular assemblies. Actually, I think that MS refused to go that way because it would be a total mess if client start to ignore publisher policies on some assemblies and don't ignore on others. Than BCL's assemblies couldn't rely on each other, the whole BCL would become inconsistent.

The second question was about the possibility to ship .NET 2.0 SP1 assemblies with our product and to redirect assembly binding from RTM assembly to SP's assembly.

The short answer is "no, it is not possible". But there are 2 possible solutions, but they are quite lame and can be of use only under strict circumstances and in general they are not applicable at all.

The first solution is to disasm CLR assembly and then build it again but with our public key, or we can omit strong-signing at all. Now we will be able to reference this RTM assembly rather than SP's assembly from GAC.

The second solution is to replace RTM's assembly in GAC with SP's assembly using the gacutil tool. The /f (force) option must be used.

Both of these two solutions are very lame. Please, don't use them. In general they can't be used due to some dependencies between assemblies.

Conclusion

In our product we downgraded our product so it could work on .NET 2.0 RTM. But we still use some functionality even from .NET 3.x (linq-to-objects, Action, Func). We just ship some of the 3.x assemblies with our product, e.g. System.Core.dll. Mostly we have no problems with this approach. But we also had to decline using Linq-to-Xml because of some unsolvable problems.

Dmitrii Lobanov
  • 4,897
  • 1
  • 33
  • 50
0

.NET versionings are only enforced for strong-named assemblies.

You cannot (and should not) expect a program to run correctly on RTM version when it is compiled using SP1. It may run correctly, but it may also fail in mysterious ways.

Stephen Chung
  • 14,497
  • 1
  • 35
  • 48
  • `System.Xml.dll` IS strong-named assembly, it resides it GAC. – Dmitrii Lobanov Mar 21 '11 at 10:19
  • Not quite the same for standard assemblies. I believe you have to "op-in" to use strong-name. Otherwise, if all .NET standard assemblies are fixed in version, when you compile a program with RTM, it may not run on computers with SP1, SP2 or SP3 installed. – Stephen Chung Mar 21 '11 at 10:26
  • 1
    Well, for that case there's a thing called `Publisher policy`, when MS ships service pack it can add redirection to new assemblies. That what `publisher policy` is intended for, I suppose. – Dmitrii Lobanov Mar 21 '11 at 10:37