1

I'm wondering about .NET's defined behaviour as regards the resolution of dependencies on specific versions of assemblies. As an example, I have a dependency on DataAccess.SQLite, which depends on System.Data.SQLite 1.0.66.0. My installed version of System.Data.SQLite, however, is 1.0.77.0. I've found that Visual Studio 2010 will automatically inject an app.config directive to bind the System.Data.SQLite dependency to 1.0.77.0:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.Data.SQLite" publicKeyToken="db937bc2d44ff139" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.77.0" newVersion="1.0.77.0"/>
  </dependentAssembly>
</assemblyBinding>

But, even if I remove this directive, the dependency on System.Data.SQLite 1.0.66.0 is apparently resolved to 1.0.77.0. Is this the defined behaviour for .NET dependency resolution?

I have had it happen in an ASP.NET MVC 3 project that .NET was unable to resolve the dependency as version 1.0.66.0 was not found, which is mainly why I'm asking.

aknuds1
  • 65,625
  • 67
  • 195
  • 317
  • Wouldn't **System.Data.SQLite** be a Microsoft compiled assembly? I would simply update your dependency to the newer version of the dll, if you want to use Visual Studio 2010, otherwise you have to supply a local version of the older dll. – Security Hound Dec 13 '11 at 14:14
  • @Ramhound System.Data.SQLite is a 3rd party dependency installed by NuGet. DataAccess.SQLite is also 3rd party so I don't control which version of SQLite it depends on. Besides, if you read my question, you'll see that the dependency is in fact resolved against the newer SQLite version, so it works out. – aknuds1 Dec 13 '11 at 14:27
  • @aknuds1, would you be able to define what you are doing which results in .net 'apparently resolving to 1.0.77.0'? I am curious because this sounds like odd behaviour. Whatever is requesting the DLL at runtime should be asking for a specific version, and I would not expect the runtime to substitute this version with another. However, if you are using something like NHibernate, and you use xml to configure System.Data.SQLite as a driver DLL, then perhaps the 1.0.77.0 version is declared here - hence more information required. – Adam Jan 11 '12 at 02:16
  • @Adam As I recall, I used CheckAsm to inspect the dependencies of a simple console program dependent on DataAccess.SQLite. The latter's dependency on System.Data.SQLite 1.0.66.0 was resolved to 1.0.77.0. Also, the program ran without problems even though System.Data.SQLite 1.0.66.0 was not installed. – aknuds1 Jan 11 '12 at 10:56
  • So CheckAsm reported DataAccess.SQLite -> System.Data.SQLite-1.0.66.0, but when you ran the application it happily substituted it with 1.0.77.0? And this is what you mean by 'it resolved'? Sounds odd - this is what I would do - configure the Fusion Log Viewer (ProgFiles\Microsoft SDKs\Windows\vX.X\bin\FUSLOGVW.exe to report bind failures - then run your application again. Then you can use FUSLOGVW to look at all the failures. Find the one pertaining to System.Data.SQLite. It should say something like 'looking for 1.0.66.0, not found' - then it will report what it did to locate a substitute. – Adam Jan 17 '12 at 00:26
  • @Adam I think CheckAsm also showed that DataAccess.SQLite's dependency on System.Data.SQLite 1.0.66.0 was resolved to System.Data.SQLite 1.0.77.0, which is the installed version. From what I recall, in all cases, the .NET runtime would resolve System.Data.SQLite 1.0.66.0 to the installed version, i.e. 1.0.77.0. By resolution, I mean which assembly the dependency resolves against. – aknuds1 Jan 17 '12 at 09:49

0 Answers0