this may be a stupid question but when I add a reference to my project and set Copy Local to false (so it doesn't copy the dll to the working directory) I get this error:
Could not load file or assembly 'HtmlAgilityPack, Version=1.4.0.0, Culture=neutral, PublicKeyToken=bd319b19eaf3b43a' or one of its dependencies. The system cannot find the file specified.
All I want is to load the dlls from "(working directory)/dlls"
Is this even possible? And what am I doing wrong?
Thanks in advance!
References simply aren't resolved relative to the working directory of the process - they're resolved relative to the assembly which is trying to load them (or from the GAC of course).
It's not clear why you want to do this, but basically you should make sure the DLL is available in the same location as the executable.
Related
After doing push from git server I got this error when I build and open my project:
Could not load file or assembly 'System.Web.Mvc, Version=5.2.3, Culture=neutral, PublicKeyToken=******' or one of its dependencies. The system cannot find the file specified.
The project is working pretty well with the same code in a different computer.
Problem
The error is a file not found, like the one I helped out with the other day:
Could not load file or assembly .. The system cannot find the file specified.
Troubleshooting
Open ProcessMonitor and run it when VS won't let you build your solution and throws the error. Stop the trace when it fails and investigate ProcMon's (Filemon) log to see where the IDE is looking for the DLL it cant find.
Solution
Put the DLL where its expected to be found (this will hopefully sort out the VS library referencing failure).
Also try:
disable Resharper
restart VS
clean & rebuild
I found nuget or some other update can bump the System.Web.MVC version to 4.0.0 unintentionally. So just check the dll that you have in your bin folder (or wherever the reference points) is of the same version specified in your web.config.
I am developing a .net solution. Due to certain complications, I have been asked to add dlls to the solution and then reference the dlls from within the solution.
It works fine on the local box , and builds perfectly on TFS Build server,
but when I run it on the server after deploying , I get a run time exception saying :
Could not load file or assembly 'Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Would you know what I should be doing at this point ?
I can provide you more detailed info if needed.. please let me know.
It seems like you need to get Microsoft.TeamFoundation.Client.dll file,
then add it as a reference to your application
this is the dependencies you described:
Two possible resolutions
Set CopyLocal property to true so that when build is done local copy of dll is added.
Check reference folder has been checked in TFS or not. Sometimes it happens that reference folder is not added in TFS.
I built a simple WIX installer that deploys an exe and a third-party dll, and creates shortcuts. The installer appears to work fine, and places both the exe and dll in a folder in C:\Program Files(x86), but when I try to run the application I get an error:
System.IO.FileLoadException: Could not load file or assembly 'GACManagerApi, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'GACManagerApi, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
The application runs just fine from the IDE, and even from the executable in the IDE bin directory, but after deploying with WIX cannot load the assembly. On a hunch, I copied the dll from the bin directory to the deployed location, and it started working. Looking closer, it appears that WIX is doing something to the third-party metadata when it deploys that changes the signature enough that the exe can no longer load it. Here is the definition of the assembly in the wxs:
<Component Id="GACManagerApi">
<File Id="GACManagerApiDLL" Name="GACManagerApi.dll" Source="$(var.GHCComponentManager.TargetPath)" />
</Component>
I also noticed that the details on the dll properties are different, with the File description, product name and original filename being changed to that of my executable, instead of the original values for the assembly.
Am I missing something in my wsx that is causing this to happen?
I figured it out. The problem was how I was defining the Source attribute. The hint really should have been in the file property details, but I was too consumed with my assumptions to see it. I was reading some other documents talking about pulling assemblies from outside the project when I noticed it.
I was defining the source as:
Source="$(var.GHCComponentManager.TargetPath)"
which translates literally to the full path of my release executable. With the Name attribute of the File element, it was effectively moving my executable to the release location and renaming it GACManagerApi.dll. The correct source should be:
Source="$(var.GHCComponentManager.TargetDir)\GACManagerApi.dll"
I'm trying to compile an application for which I have the solution and can't get past:
'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.IConfigurationSource'
is defined in an assembly that is not referenced. You must add a
reference to assembly 'Microsoft.Practices.EnterpriseLibrary.Common,
Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
So I added the assembly to the GAC:
After some research I opened up visual studio with the Fusion Assembly Binding Viewer running, which seemed to create a lot of logs but none that related to this exact version of the assembly (however 4.1.0.0 is in there).
I can't simply add -> reference as VS tells me that a reference with the same name already exists.
What other avenues should I explore?
Have you tried to Alias the assembly also if you are using .net 4.0 you would have to have an entry in the .config file for example that shows the old assembly name referencing the new assembly name. Several other things to keep in mind .. if the .DLL is in the GAC and you don't have a copy of that assembly in the bin folder, this could cause an issue..
Is this local referencing or is the code on a remote machine ..? if it's a remote machine.. why not add that specific assembly to the GAC.. notice the versioning difference of the two assembly's in your screen shot as well..
I've created a new Silverlight 3 from template and started a debugging session. However, when I looked to the modules window I saw the following:
The path to my Silverlight3Application.dll was lacking (even though the pdb was found just fine). I made sure that it isn't just a UI issue, indeed I could delete the Silverlight3Application.dll file that was located next to the PDB just fine without any issues.
Questions:
Where is my DLL actually loaded from UPDATE in runtime?
Why isn't it loaded from the expected location?
Is it possible to make it load from the location next to the PDB file, where I actually expected it to load from?
Update 1
What I really need is to find out the location of my Silverlight3Application.dll in runtime, using Reflection, for example.
However, just as the modules window hides the real location, so does reflection:
Assembly: {Silverlight3Application, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null} System.Reflection.Assembly {System.Reflection.RuntimeAssembly}
FullName: "Silverlight3Application, Version=1.0.0.0, Culture=neutral,
publicKeyToken=null" string
ImageRuntimeVersion: "v2.0.50727" string
IsDynamic: false bool
Location: "" string
I've tried located this assembly manually using Prcocess Explorer and its location seemed rather random:
C:\Users\Vitaly\AppData\Local\assembly\dl3\G1KDTYO5.XJ3\6GQ19BER.4OW\5e5cbf28\50366acf_1a3ecc01\Silverlight3Application.dll
Anyone knows how I can find the location of the assembly in runtime? If nothing else works, using external tools is an option, however, I must be able to execute the tool from code. I'll be happy to hear ideas.
Thanks!
By default, Silvelight DLL is located in \Bin\Debug of your Silverlight project.
If you want to see where an actuall DLL is loaded from:
output path is visible in Visual Studio Output Window during build
use ProcessMonitor.
Also see http://msdn.microsoft.com/en-us/library/cc838164%28v=vs.95%29.aspx for detailed description of Silverlight project structure.
To your Update1: see How do I get the path of the assembly the code is in?
Have you considered how the assembly is actually executed in your browser? It comes from a .XAP file, not via any DLLs built/stored under your project folders. More specifically, your project builds a DLL, which is then packaged into the XAP file, which is in turn served to your web browser, which unpacks the XAP file, reads the manifest, and loads the specified DLL entry point.
The path to the DLL from the XAP root is, well, the file name (unless you've done customized the XAP yourself). That's probably why there isn't any path specified.