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.
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 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.
I am getting this error:
Could not load file or assembly, system could not find the file specified.
Images:
http://s30.postimg.org/4x936f6ch/error2.png
http://s17.postimg.org/41ta9aaj3/errro3.png
I have a solution built in .NET 4.0
In it I have projects that act as plugins. They use dlls and the issue is that one of the solutions projects dlls is being called, and that references the dll that is causing the issue.
I get no error when rebuilding etc just when the program gets to the part where it uses the dll that references this one.
I have also made sure that in the projects bin folder that it has the dll that it is complaining about.
I have opened the dll in reflector and I don't think it has any issues.
COuld someone point me to the next step to try with fixing this issue?
Thanks!
Couple of tips - hard to know if they'll help you:
Open the csproj file(s) in a text editor and see where the dlls are being referenced (GAC possibly)
If it's a signed assembly, make sure you've got a signed copy (if you've built an Open Source project yourself the signing will be lost)
Look at the references in Visual Studio - do you have Copy Local set to True and Specific Version set to False?
Look at you're App.config or Web.config - is there a binding redirect that failing to load
I remember reading a post about assemblies not being able to be unloaded - probably not an issue on this one but I think the trick was
to load the DLL in a separate AppDomain to keep it isolated - loadable
and unloadable.
I wrote a dll c++/cli library which uses my other c# dll library. C++/cli library works fine when I've got c# dll in the same folder as application which calls it. This library will be finally loaded to many applications and a C# dll must not be copied into directory with application. It has to be in the same folder as c++/cli library, but in that cases I've got System.IO.FileNotFoundException.
My suggestion is to load c# library manually or to change path where f.ex. firefox is looking for dependencies, but I tried with LoadLibrary() and Assembly::LoadFrom() methods to force loading from right directory. Of course I added directory path with dll to system PATH.
I work on VS2010.
You don't change the default directory where an application will look for dlls.
At design time put your dll in some well know location, the one you are going to deploy to. Add a reference to it, make sure it's set to Don't copy ever, otherwise it will end up in the bin folder. You have to do this otherwise it won't compile.
When you deploy, you'll need one package to deploy common dlls, and one for each application. Careful you don't create your own version of dll hell, if appA needs an older or new version of the common dll, compared to AppB
Add an AppDomain.AssemblyResolve event to main (for windows app). At run time the event handler will get fired when you reference a type in your dll, and the assembly has not yet been loaded.
In there you load it from the well known location. That usually in config, or in a relative path.
E.g.
AllMyApps
CommonDLLS
MyFirstApp
So the path you load the required common dll from would be "..\CommonDlls\MyCommondll.dll".
NB you will want to secure the dlls in some way, otherwise a bad guy might be able to inject their version of one in to your app, which would be bad...
You can use this mechanism to get the dll from a remote server or a database blob as well.
The simplest case is only a few lines of code, just look the event up. Took me about 15 minutes to get this going in a similar scenario.
Not on this machine though, otherwise I'd have pasted in the code.
I have a COM-visible dll "COMInterface.dll" which is deployed into an existing application's folder. I have created a test harness that has verified the functionality of this dll.
However, when I try to use classic asp to call one of this dll's methods I get a message like the following:
MyCompany.MyProject.COMInterface (0x80070002)
Could not load file or assembly 'MyCompany.Framework, Version=2.6.4202.14897, >Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
My "COMInterface.dll" references a number of other dlls such as my company's standard framework, logging classes etc. "Framework" is one of these such dlls.
Where will the asp page be looking for these dlls? I am guessing that my harness worked because it was being run from the program folder whereas the asp page is within an IIS web site.
Do I need to use GAC registration here? I'm hoping not as there would be quite a few dlls I would need to deploy there and I am hoping to extend the application without having to impact the core installation on users' machines.
Thanks in advance of your questions and suggestions.
[EDIT]
I should point out that the object can be created fine. It's the location of the referenced dlls that are causing the problem.
When you use Regasm to register the dll you need to use the /Codebase switch to ensure the dll can be found.
As a general answer, you can use Fusion Log Viewer to determine what paths have been searched by the assembly binder.
See http://msdn.microsoft.com/en-us/library/e74a18c4.aspx for information on this tool.
Fusion Log Viewer will list all the paths probed by the binder. If you put your assembly into any of these paths it will be found. Whether any of these paths will be suitable for your scenario I'm not so sure.