1

I am running a project that had been running without issue for some time but recently started throwing an error stating,

"Could not load file or assembly 'Microsoft.Practices.Unity, Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified."

I see that this assembly is for IoC/Dependency Injection support however I never explicitly added it to the solution; although I do see that it is in fact there.

When I check the version of the assembly it is showing the same version that is being referenced in the above error; so I cannot figure out why the file cannot be found by the project.

In effort of resolving the issue I've cleaned the solution, deleted my obj folder, rebuilt, removed and even reinstalled the assembly via nuget but the issue persists.

I've found somewhat similar issues reported here on SO but the proposed resolutions were either not applicable because it was not the same assembly reference as the one I'm having issue with OR it involved configuration of a XAML based application. This is ASP.NET.

The only other clue that I could find as to why I'm having the problem is that the targeted runtime framework of the assembly is v2.0.50727 and this application is .NET 4.5

Which would seem a reasonable explanation for the problem from my limited perspective except that the app was previously running without the problem.

I'd also mention that the assembly isn't explicitly being called from the block of code throwing the error; which is simply creating a web service client and calling a method.

long memberId = 1326728123;
ServiceClient sc = new ServiceClient("ServiceClientEndPoint");
var leadPackage = smc.GetLeadPackages(memberId);

So there could be other variables of this equation that may be attributing to the problem (e.g. Network blocking and etc)

I just wanted to make certain that I may not be missing something by running it past SO before wasting time going in the wrong direction for an answer.

Mark
  • 1,667
  • 2
  • 24
  • 51
  • In the properties of the reference, have you set `CopyLocal=true`? – spender Jan 04 '16 at 13:08
  • Yes, it appears to be set to CopyLocal = true – Mark Jan 04 '16 at 13:11
  • This may be helpful [Could not load file or assembly or one of its dependencies](http://stackoverflow.com/questions/4469929/could-not-load-file-or-assembly-or-one-of-its-dependencies) – Marshal Jan 04 '16 at 13:15
  • Use the "Assembly Binding Log Viewer" (Fuslogvw). It will show you what it's trying to load, where it looked for DLLs, why each one was rejected, etc. And it's already installed with Visual Studio... https://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx – Basic Jan 04 '16 at 13:26
  • Thanks, I'll take a look at the Assembly Binding Log Viewer – Mark Jan 04 '16 at 13:46

1 Answers1

1

Note that this could mean a number of things, including that one of the dependent assemblies of Microsoft.Practices.Unity could be loaded.

The first place searched is the GAC, if you are building and running on the same machine, this probably won't cause a problem because the runtime will also find the same library but if you are deploying, the project will sometimes bind to the GAC library whereas the production server might not have it installed and it will fail to run. CopyLocal=true should fix that but if you are deploying, you should check that the library is copied into the bin directory.

Secondly, you should open Microsoft.Practices.Unity.dll using reflector or ilspy.exe and see what other dependencies it has (other than the System.* libraries) since any other ones will need the same treatment as Microsoft.Practices.Unity i.e. adding to the project and copy local set to true.

Marshal
  • 6,551
  • 13
  • 55
  • 91
Lukos
  • 1,826
  • 1
  • 15
  • 29
  • 1
    @Marshal it looks as though closing out of VS, rebooting and then re-opening the solution resolved the issue; which is great so thanks for pointing me to the link because it was the 1 thing I hadn't considered. The unfortunate part of this is that I still have no clue as to why that would resolve the problem. It's nice to have resolutions but more advantageous to have a logical answer which I suppose I'll never know now. – Mark Jan 04 '16 at 15:37
  • @Mark: That's true. I am guessing that may be VS frees the resources when it closes and gets hold of the new one on startup. But its always good to know the exact reason than just the resolution. – Marshal Jan 04 '16 at 16:01