When deploying new builds of applications, I find that applications built by another dev would have the structure:
ApplicationName.exe
ProprietaryClassLibrary.dll
associated config files.
However, when I deploy a version I have built, I start to get "Could not load file or assembly" type errors.
These can be "resolved" by including the named assembly in the application folder. So now I would have (for example):
ApplicationName.exe
ProprietaryClassLibrary.dll
System.Data.SqlServerCe.dll (for example)
But my question is- if these aren't references I've added, and the version hasn't changed, why do I now need to include them in the application folder?
I don't necessarily want to have to include copies of libraries that are already in the GAC or installed elsewhere on the server if I don't need to- but am open to suggestions on best practice.
I have checked my the references' settings in VS to change "Copy Local", "Specific Version" as well as Path, but with limited success.
Any pointers on what might be causing this?
Thanks.
Related
I downloaded a package from SourceForge, PlanEph, which has 64 and 32 bit DLLs for C#. I got the 32 bit included C# demo to work by putting the DLL in my bin/Debug directory (I'm using Visual Studio 2015 Community) and adding the DLL as a reference.
Then I tried to make my own version of the demo in a separate solution, and got the System.DllNotFoundException. Various experimentation lead me to believe I can't have two identical namespace names anywhere in my Visual Studio installation, so I erased everything and started over.
I made a directory C\GJAbin, put the DLL in it, and added it to the system Path variable. I also put a helloWorld type program in that dir and executed it from the command line to verify the directory really was in the path. Then I recreated the demo solution, added the DLL as a resource, and built the solution "successfully". Then I ran it and got the System.DllNotFoundException.
So I can't understand why the DLL is being found when compiling but not at run time.
Go to project settings, go to "publish" tab and on the top most button (labeled something like "application files"). Chose "Show all files" checkbox if you don't see your DLL. Set the DLL's publish status to "Include" (NOT "Include (Auto)"!!) and publish it again.
Now the DLL should be inside the publish folder.
So I can't understand why the DLL is being found when compiling but not at run time.
Locating the assembly at compile time is done differently (by MSBuild) than at runtime (by the CLR).
At compile time, MSBuild has specific search paths that it knows about, or in most cases like this, there will be something in your project file telling MSBuild where to look for the file. Usually the <Reference> has a <HintPath>.
At runtime, the CLR will attempt to find the assembly from its own set of well-known paths. It will look in your app's config file (if applicable), then in the Global Assembly Cache (GAC), then in your app's root directory. Much more detail on this is available here.
You can tell MSBuild to copy the reference to your build output directory (usually the same as your app root directory when running). In VS, you can do this by selecting the reference and looking at the Properties tool window (or press F4 by default). Set the CopyLocal state to True. In the project file, this will add a <Private>True</Private> on the <Reference>.
You can also add the assembly to the GAC using the gacutil tool, but this does make it harder if you want to share your app with others. Usually it's preferable to keep a copy in your app root directory.
If it's still not working, you can also see the log for how the runtime is trying to find this assembly. The fuslogvw.exe tool in the Windows SDK (you can run it from the VS command prompt and it will be on the %PATH%) allows you to enable logging for assembly loads. You do need to be able to run this as an administrator to configure the setting.
As you can see in the screenshot, you can either log the results in the exception (so that you can see it while debugging), or you can log it to a file on disk (so you can see it whenenver).
The problem turned out to be an unfortunate interaction among the way the author chose names and the way Visual Studio displays information and error messages. The author created a c# dll Astronomy.PlanEph32.dll containing a namespace PlanEph32, which which was really just a wrapper for the c dll PlanEph32.dll. So all the error messages about not being able to load PlanEph32.dll were referring to not finding the c dll; the c# dll was being found just fine.
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 have been given a web service project to work on and I've made it reference a dll. This dll has several other dll's it is dependent on to load. For any other application I've used that needed this dll, I just slapped the dependent dll's in the bin folder. This doesn't seem to work for the web service application, and I get the error stating that "blah.dll failed to load because dependent dll blah blah". My question is where can I put these dependent dll's or what can I configure in visual studio for the web service to find and load the dependant dlls.
Thank you.
*Also, this is for debug purposes only, so the solution doesn't need to be the "correct" way. Anything hacky is fine, as long as I get it to work.
I recommend that you enable the "Copy Local" option on each reference to a non-standard dll. This will ensure that the dlls are copied into the bin directory when you build, and you can easily build a deployment from there. Assuming you are hosting under IIS, it should be as simple as zipping up the bin directory and moving it to your server application directory.
Okay, I asked this question the other day, and it was closed due to my vagueness. I'll try to be more specific. In a project, say C# (using Visual Studio), I add a reference to a dll (right-click References->Add Reference), and the location of said dll is in C:\Blah\Foo. Now, if I move the exe that is built over to another machine, will the location of the dll need to be with the exe, or will it need to be in C:\Blah\Foo? Thank you.
When you add a reference in the way you've described it is copied to the output folder (same as the exe file). Look in the properties of the reference (F4) and you will see an option called "Copy Local", if this is set to true then the DLL will be copied to the same output folder as the EXE file.
So when you deploy your application to another machine you will need to copy the exe and all it's referenced DLLs to the deployment location. Windows will search for DLLs in a number of locations, the first of which is the same folder as the EXE file.
Typically, you'll just put the assemblies in the same folder as the application, which causes it to be in the default probing path, and get found (for most applications), but there are many other options depending on the type of application. When you define your reference, there is the option to "Copy Local" - which causes the assembly to be copied to the application's output folder. If you leave this set to True, the assembly (DLL) will be with the .exe, and typically "just work."
The full process the runtime uses is covered on MSDN in How the Runtime Locates Assemblies. In particular, the topic titled Locating the Assembly through Codebases or Probing covers how the assemblies are located in detail, which depends on a lot of factors.
The DLL should be with exe file. Have a look on this link to see where .NET serach for DLL In what order are locations searched to load referenced DLLs?
The dll could either be installed in the GAC or be present with the EXE in the same directory.
EDIT: The above mentioned are only just a couple of locations to resolve references.
When you add reference, you add path on your csproj on this assembly, dont you must just ensure that you can reference this dll.
When you deploy, it's another question, because your dll is copied on your Bin directory.
If you deploy you check your path of assembly in your csproj, and ensure that you deploy your assembly
Nota : check CopyLocal Property of your refrence
2 Other solution :
You can use GAC Global Assembly Cache in order to share your assemblies
Tools : Gacutil.exe in order to set assembly
I have created a dll that will be used by multiple applications, and have created an installer package that installs it to the program files, as well as adds it to the Global Assembly Cache.
The dll itself uses log4net, and requires a xml file for the logging definitions.
Therefore when the installer is run, the following files get copied to the install directory within program files:
The main dll that I developed
- The Log4Net.dll
- the Log4Net.xml file
I am now experiencing a problem. I have created a test console application for experimentation. I have added my dll as a reference, and set the 'local copy' flag to false.
When I compile the test console exe however, I noticed that it has copied the log4net.dll and log4net.xml files to the bin directory. And when running the test console, it appears that it will only work if the log4net.dll is in the same directory as the exe. This is dispite the fact that the test console application does not use log4net, only the dll that was added as a reference does.
Is there some way to have it so that the log4net.dll & xml files used will be the ones that were installed to the program files, rather than any application needed to copy over local copies? The applications that will be using my dll will not be using log4net, only the dll that they are referencing uses it.
Many thanks
Don't install into the Global Assembly Cache! Even if your library dll is used by multiple applications each should have it's own local copy. Otherwise you get into a whole world of pain for saving a few KB of disk space.
Always copy the required dlls locally. If you are really sure that the application won't need it you can simply delete the unnessesary dlls later or don't include them in the installer. But if your application will call ANY reference there it will crash at runtime. So best option is to leave them there (after all they WERE referenced for a reason).
No, it's not possible (at least not without much efford) to have .Net load dlls from arbitrary locations on the disk. And it should be this way (look up DLL-hell if you want to know why).
I suspect your problem is the configuration. You must use fully qualified names if you want it to work from the GAC. As per the documentation at http://logging.apache.org/log4net/release/faq.html:
"When loading an assembly from the GAC the fully qualified assembly name, including the version, culture and public key must be specified. This is in the standard syntax supported by System.Type.GetType. See the next FAQ on how to get the version and public key for an assembly."
I managed to resolve this by adding Log4net.dll to the GAC as well. It will now run without needing a local copy the dll.
It does however require a local copy of the XML file, to correctly log.