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.
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.
Related
I currently have a .NET application which references "SomePackage.dll" and "SomeUtilities.dll".
SomePackage.dll is contained in a separate folder, and one of the assemblies it depends on is also named "SomeUtilities.dll".
In other words, I added a reference in my project to \somePath\SomePackage.dll, and there exists a file \somePath\SomeUtilities.dll that SomePackage.dll depends on. Since I already have a reference in my project to a assembly called SomeUtilties.dll, I could not add a reference to \somePath\SomeUtilties.dll.
As a result, when I try to run my application and initialize a module in from SomePackage.dll, I receive an error:
Could not load file or assembly 'SomeUtilities.dll..." or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.'
To work around this, I used gacutil in the VS developer command prompt to add \somePath\SomeUtilities.dll to the GAC. Now both assemblies are resolved fine, but I was wondering if there was a better way to resolve this name collision that doesn't involve adding to the GAC. I'm worried about potential issues that may arise with installing into the GAC, and have heard that .NET has the ability to look through certain subfolders to resolve assemblies, but am not sure where to find more on this concept.
You can use bind redirect.
Open the .config file to find the location of < assemblyBinding>
Remove the < assemblyBinding> reference.
Type in Package Manager Console: Add-BindingRedirect.
Windows/.NET has a tool called FUSLOGVW.exe that will help find issues with assemblies. This tool is useful but sifting through the logs is cumbersome. There is an open source tool that is a wrapper around FUSLOGVW.exe and makes it much easier to sift through the data and find the root of the problem. I would use this
https://github.com/awaescher/Fusion
I've researched a lot on stackoverflow and no one really explained what to do in my case.
I have application that is using a TFS Api, and it is using a Nuget packages that contains dll like Microsoft.TeamFoundation.*.dll.
Here comes the tricky part - When I run application from debug everything is working fine since CLR is loading dlls from my , BUT when I deploy application and start using it, it loads dlls from the GAC if any of those dlls exists in GAC.
This causes numerous errors since it loads different versions e.g. Microsoft.TeamFoundation.1stdll.dll with version 11.2.2302 then Microsoft.TeamFoundation.2nddll.dll with version 11.0.2123 and there are cases when it starts with 10, and then asking for a reference 10 dll to resolve issue and I end up with exception.
What I did?
I've tried to point to probing path with without success. As soon as it finds for example version 11.0.2.1 in GAC and 11.3.1.2 in probing it resolves dll with GAC one.
I've tried as someone explained to create a new appdomain and to share dlls between domains but I've hit the dead end, no matter what I've tried it loaded it from the GAC. I've also tried to load dlls at entry point of my app, and than to redirect it to my path and resolved it. Again no success. I've tried to trick application and at resolving point return null for publicKeyToken in order to tell it that I am using a non-signed dll, in which case it wouldn't look at the GAC, but had no luck. I've tried to remove signing with Nirsoft snremove.exe and guess what? No success either.
I am looking for a code that will no matter what force my application to use my dlls instead of one in GAC. I want to avoid that during runtime it does not randomly pick up a 11.00.xxxx version but instead use my specific 11.92.21212.2 even when it has bigger or in some cases lower versions.
The only thing that I cant accept as a possible solution is to manually configure CLR interfaces for resolving and loading assemblies in C++ as someone mentioned on stackoverflow before.
One thing I can think of is you can try is to limit the permissions of the new Application domain you load to not have access to the file system, drive, or to the GAC path more precisely, for example on the first call into a method in the new domain or a constructor set the permissions like it's done here.
Then you can embed the needed assemblies in the Resources of the application and use the AssemblyResolve event to load them like this.
I am getting a bizarre error that has crippled an application with tens of compile errors that were not there before this issue occurred. Most of the compile error's are not recognizing objects in the XAML code that were fine before this error.
The error,
Unknown build error, 'Cannot resolve dependency to assembly
'Microsoft.SharePoint.Client.Runtime, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxx' because it has not
been preloaded. When using the ReflectionOnly APIs, dependent
assemblies must be pre-loaded or loaded on demand through the
ReflectionOnlyAssemblyResolve event.
The events leading up to this are,
2 of us collaborating on GitHub
The other collaborator downloaded Windows Office reference for Excel
Office.Interop.Excel reference seems to all be there on my end
When updating to last commit, runs fine on my machine until I re-build solution
Runs fine on collaborator's machine.
I have never used SharePoint on my machine.
I have never come across something like this. From what I can see the required references are there. I am lost as to what I need to do to get this to work again.
The answer to this was that the other collaborator had installed Office Developer Tools and after I downloaded them as well, all the compile errors were fixed. It seems that not all the references were there.
I hope this helps someone in the future.
I have a very small, simple ASP.NET MVC app (MVC 4 I think. .NET Framework 4) it consists of one controller with one action serving one page.
I'm deploying it on AppHarbor, pushing it with git on my local machine, I've never had problems running it locally and it has never had build issues/errors on AppHarbour but every now and then a new build (with no relevant change in my mind) will start throwing the following error:
Could not load file or assembly 'Microsoft.Threading.Tasks,
Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Looking into this the top answer here sorted it, I removed the dependent assemblies listed and it worked again. But then it came back. Tried a lot of different suggestions, it has always used nuget, tried removing everything and re-installing, it started working again when I wasn't even sure what I'd changed and now it isn't working again. Today I switched it to NuGet Package Restore as outlined here but that hasn't made any difference.
I can re-deploy the last working build, what I notice comparing working/not working builds downloaded from AppHarbor is that the Web/App.configs are identical (no dependent assembly entriy for this) but the Microsoft.Threading.Tasks dlls and xmls (including Extensions and Extensions.Desktop) are not in the broken build (in the working build they appear in the root and in the bin)?
In the project the dlls are linked from the packages folder for the app and Copy Local is True, they aren't a direct dependency of the Web App but of the Google Calendar API its using.
Update
On the back of writing the answer I've looked more closely at the build logs and noticed a distinct difference between a working and not-working build.
The Microsoft.Threading.Tasks.dll is not a direct dependency, its required by Google.Apis.Gmail.v1.dll, in a working build the build log will contain (see the bottom line copying Microsoft.Threading.Tasks.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\voz3srsa.vhb\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\voz3srsa.vhb\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\voz3srsa.vhb\output\log4net.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.dll"
to "D:\temp\voz3srsa.vhb\output\Microsoft.Threading.Tasks.dll".
A not-working build will have a different dll in its place (see the bottom line again, Microsoft.Web.Infrastructure.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\0kzqakoc.4jo\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\0kzqakoc.4jo\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\0kzqakoc.4jo\output\log4net.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll"
to "D:\temp\0kzqakoc.4jo\output\Microsoft.Web.Infrastructure.dll".
Looking into dlls missing in the build I found this answer but I have tried a command prompt build locally and it works fine.
Update 2
Also in trying to solve this I had noticed a comment on the build (not a warning) around reference versions:
1> Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Users...\packages\TweetSharp.2.3.1\lib\4.0\Newtonsoft.Json.dll] to Version "6.0.0.0" [C:\Users...\packages\Newtonsoft.Json.6.0.6\lib\net40\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Couldn't get a remapping that sorted it but did get this where adding an app.config (which makes no sense for a web app) redirect fixed it where the redirect in the web.config didn't. This did stop the build issue but made little sense.
I took this to the AppHarbor support forum as this didn't get any response here, Build succeeding but missing dll and they were very helpful and it now looks like it is resolved.
Although in Visual Studio 2012 Professional all references were marked as Copy Local True, they did not have the True tag so I added these by hand for the three libraries in question. And that was it, DLLs copied.
There are a lot of links around this discrepancy, that MSBuild needs them (although I had tried an MSBuild build and it was fine), Visual Studio doesn't insert them by default (may appear if you toggle the setting false and then true) and it manifests in not copying references-of-references.
Stack Overflow question, see highest voted answer not accepted hack
Raised with Microsoft and closed as not reproducible
We have a project which utilizes Sharp Architecture. For the purposes of some testing, we made some adjustments to strongly type some assemblies.
Following this, the project would no longer build. VS2010 complained that:
error CS0012: The type 'SharpArch.Core.PersistenceSupport.IRepositoryWithTypedId`2' is defined in an assembly that is not referenced. You must add a reference to assembly 'SharpArch.Core, Version=1.5.0.0, Culture=neutral, PublicKeyToken=b5f559ae0ac4e006'.
The reference has been removed and re-added. It's also in the GAC and we've verified that the Public Key Token matches.
Just check if you are running in x64 mode. Otherwise things will not work. Go to the vs project properties and change it to x64.
This is my checklist with the most likely cause on top.
Make sure your project is not set to ".NET x.x CLIENT Framework". This one gets me all the time.
Try cleaning your solution. I find that VS gets confused sometimes and needs you to clear out the obj/bin folders.
Restart VS
Set the reference to copy locally.
Change it so that it doesn't request a specific version.
Change it so that it does request a specific version.
Remove the reference to the GAC version and add one to a version stored in a file.