Aadith Ramia
Aadith Ramia

Reputation: 10339

Unable to migrate from Unity 2.0 to Unity 2.1.505.0

I have an application written using Unity 2.0 and I am trying to migrate to version 2.1.505.0. I changed the reference in the project to point to the DLL corresponding to the newer version. When I build the solution, it goes through fine. However, when I try to run the application, it gives me a FileNotfoundException:

Stack Trace: 

[FileLoadException: Could not load file or assembly 'Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   InsightsService.WebApi.WebApiApplication.Application_Start() in E:\tfs\DisplayApps\Services\InsightsBps\Dev\source\InsightsService.WebApi\Global.asax.cs:30

[HttpException (0x80004005): Could not load file or assembly 'Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +12863325
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +175
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +304
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +404
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +475

[HttpException (0x80004005): Could not load file or assembly 'Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +12880068
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +159
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +12721257

I checked web.config and could not find any overrides. I even cleaned the solution and rebuilt it, but the problem persists. What could be wrong here?

Upvotes: 1

Views: 5026

Answers (2)

Jehof
Jehof

Reputation: 35544

You can use an AssemblyBinding to ensure that the new version of Unity is used when the old version is requested. At the following to your configuration file and it should work

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.Practices.Unity"
                        publicKeyToken="31bf3856ad364e35"
                       />
      <!-- Assembly versions can be redirected in application, publisher policy, or machine configuration files. -->
      <bindingRedirect oldVersion="2.0.414.0"
                       newVersion="2.1.505.0"/>
    </dependentAssembly>
    <dependentAssembly>
      <assemblyIdentity name="Microsoft.Practices.Unity.Interception"
                        publicKeyToken="31bf3856ad364e35"
                       />
      <!-- Assembly versions can be redirected in application, publisher policy, or machine configuration files. -->
      <bindingRedirect oldVersion="2.0.414.0"
                       newVersion="2.1.505.0"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>

I had the same problem when i updated to the new Unity version, but the Enterprise Library that i use, requested the old version, cause Enterprise Library was build against version 2.0.414.0.

Upvotes: 4

Chris Tavares
Chris Tavares

Reputation: 30411

Something in your project is still referencing the old DLL.

Have you tried turning on fuslogvw (see http://msdn.microsoft.com/en-us/library/e74a18c4.aspx for instructions) and looking at the logging it does? That usually picks up referencing issues pretty quickly.

If you find the reference is something you can't fix (another DLL that you don't own, for example) you could look at setting up a binding redirect.

Upvotes: 1

Related Questions