Monthly Archives: May 2015

Could not load file or assembly Microsoft.Practices.Unity after Web Deploy

Assume you have multiple ASP.NET MVC applications deployed under the same domain, say funkydomain.com.

The first application can be accessed by visiting the URL funkydomain.com and is your main application website. Second application, an HTML5/Javascript ASP.NET MVC5 web application, can be accessed via funkydomain.com/funkyness and the third, a Web API application, via fundydmain.com/funkynesswebapi.

All three ASP.NET MVC applications are deployed using Visual Studio’s Web Deploy capability. What you need to ensure here when using Web Deploy is the correct relative application path when specifying the Site parameter for Web Deploy.

For your main application resident at funkydomain.com, the Web Deploy configuration should be as follows, assuming your are deploying to your-cloud-server.com and the site name provided to you by your Cloud provider is funkydomain.

Server: wdeploy.your-cloud-server.com
Site Name: funkydomain
User Name: your-user-name
Password: your-password
Destination Url: http:myfunkydomain.com

Your second application available at URL funkydomain.com/funkyness, should have the following Web Deploy settings:

Server: wdeploy.your-cloud-server.com
Site Name: funkydomain/funkyness
User Name: your-user-name
Password: your-password
Destination Url: http:myfunkydomain.com

For your third application available at URL fundydmain.com/funkynesswebapi should have these settings:

Server: wdeploy.your-cloud-server.com
Site Name: funkydomain/funkynesswebapi
User Name: your-user-name
Password: your-password
Destination Url: http:myfunkydomain.com

Note that the main difference between all three configurations is the Site Name parameter. If you do not specify the relative path to each application, all three will be deployed in the same folder under funkydomain/bin and if each application uses a different version of a DLL such as Microsoft.Practices.Unity, you will run into this problem:

Could not load file or assembly ‘Microsoft.Practices.Unity, Version=2.1.505.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)

Happy coding.

Advertisements

Visual Studio unable to load a program with an incorrect format.

Verify the bitness of the hosting application when you encounter this error.

Visual Studio 2013, for example, runs as a 32 bit process.  IIS Express also executes as a 32 bit process.  However, I just learned that a Windows Forms application being debugged in Visual Studio  2013 executes as 64 bit process.

A quick way to confirm the correct bitness is to identify the process under the task manager.  A 32 bit process will be appended with a *32.  Visual Studio for example is represented as devenv.exe *32.  However, the  Windows Forms application that was being debugged was represented as ApiTestClient.vshost.exe.

In our case, we had copied the 32 bit version of an unmanaged dependency from the bin folder of an ASP.NET classic application into the bin folder of the Windows Form application.  This was the problem.  We needed to use the 64 bit version of this dll worked instead.