I have a dll project that references Microsoft.Practices.EnterpriseLibrary.Common.dll (="the dll") from my install dir of the Microsoft Enterprise Library 3.1. It has a public key that starts with "b03f".
I have another project that references Miner.Geodatabase.dll version 9.30.2.5168 (It shows 9.2.0.0 in the GAC folder). The Miner dll has a public key starting with "196b".
A third dll references the other two.
Here's a simple vs2005 solution with the above projects
ELTest.rar -
1. RefEL, just references the dll from its lib folder.
2. RefGeodatabse, just references the Miner.Geodatabase.dll from the GAC.
3. RefBoth, references the other two projects.
After compilation, the bin/debug folder of the RefEL contains the "b03f" ("real") version of the dll, while the bin/debug of RefGeodatabase and RefBoth contain a version of the dll with a public key starting with "196b" - same as the Miner dll. It seems to me they have recompiled the enterprise library (and possibly changed something).
At runtime (In my real solution, not in this bogus solution), my "both" projects calls the "EL" project, that needs the "b03f" dll, can't find it, and crashes.
What am I supposed to do? Maybe if I register the Enterprise Library dlls in the GAC they will be found at runtime. Is there a different solution that does not require me to install the entlib on my target computer?
Well, I've decided to register the normal ("b03f") version of the enterprise library in my GAC (and also on the production computers). I've used this link to register all the dlls at once. worked like a charm.
Now, my RefEL project references the GAC version of the dll, and even though the RefGeodatabase has Miner.Geodatabase.dll, which references the "196b" version from the GAC with CopyLocal=true, at runtime my project finds the "b03f" version in the GAC and doesn't crash.
Related
I have used a third party dll(ABCpdf) in my .NET app and installed the app onto another machine. The program worked fine but then the trial expired and we purchased the third-party component and copied the new dll into the application directory. When running my app we got an error that assembly could not be loaded. I have noticed that the reference to the dll has copy local set to false so I changed it to true. Still getting the same error.
I checked and there are a number of copied of the dll on the machine - one in the folder of the installed third-party application, one in application folder of my application (copied from the installation folder) and also one in GAC. I did set copy local to true but then again, once the assembly is installed in GAC, that's the version that will always be used.
How can I resolve the issue? Would deleting dll from GAC be safe? Would it resolve my issue? Please advise
Check the references used, etc.
First of all be sure that you're compiling with the right version, with license installed.
You can use this code to add the license key on runtime (to avoid future errors in your customers):
WebSupergoo.ABCpdf7.XSettings.InstallRedistributionLicense("your_serial")
AbcPDF don't need to be installed on GAC. So you can remove it from there.
Then, check the 32/64 bits issue, because ABCpdf use to provide 4 dlls, 2 for each platform (ABCPDF.dll and ABCPdfCEXX.dll).
Try deleting the DLL reference in your project's References and then readding it. Make sure you are adding the purchased DLL that is in your application's directory. I've had to do this plenty of times before when fighting with third-party DLLs...it usually works.
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
I am trying to make a program that works on every operating system by forcing it to load and use the DLL's in the current directory, not the windows directory, but it don't works. I tried to enable "copy local" and change the refference path, but without any success, the program tries to load the DLL's from the windows directory.
My question is: how can I fix this?
The Search Order for DLL's is documented here on MSDN. It also includes instructions on how you can modify the search order so that the local bin directory is searched first, instead of the GAC.
The directory %windir%\assembly is called the GAC. Assemblies are not copied there, but installed typically using gacutil /i or by installation packages.
GAC is a suitable folder for libraries referenced by lots of other libraries and applications in build versions that are not centrally coordinated. Using GAC allows you to have multiple versions of the same library, all of which might be indirectly required even by a single application, installed side by side on the system. Case in point is the .NET framework itself.
The assemblies that you build are probably not that kind. Application assemblies and libraries that are basically part of a single application should never make it to the GAC or you can get into trouble. There is a variety of possible trouble:
one accidentally or intentionally creates different (incompatible) builds of the same library with the same version number.
assembly in GAC references an assembly not in GAC
one app installs the same assembly into GAC, but another app wants to load it from its local folder (where application binaries reside).
Code in the GAC gets a preference when assemblies are loaded. To remove an assembly from the GAC, use gacutil /u.
In our environment, we have two in-house frameworks and a separate website. During development, the references to the in-house frameworks tend to be set tp project references. However, once we move to release, the in-house frameworks are installed into the GAC as they are used for multiple instances of the website on each server. All of the ProjectReferences are changed, by hand, to References and the website assemblies and website are re-compiled and deployed.
I am attempting to automate this process. What is the best way to handle these issues? I have started to learn MsBuild in the attempt to accomplish this, but am totally confused. Any pointers and/or suggestions on how to proceed?
As far as I am aware there shouldn't be any need to change from using project references to file references simply because the assembly is registered in the GAC - as long as the referenced project is strongly typed at the point that it is built, the reference should still be valid.
Clarification:
There is no fundamental difference between a GAC reference and a file reference - if you have a reference to a strongly named assembly, and that assembly is placed in the GAC then the end application will load that assembly from the GAC.
See this link for more information on how the runtime locates referenced assemblies:
http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx
FYI - I believe it is recommended that you don't reference assemblies which are in physically in the GAC, and that you instead reference the strongly named assembly before it is placed in the GAC (not to be confused with whether or not the assembly should be installed to the GAC on the end-user machine)
If you leave the project references in, MSBUILD will copy all the project references as DLLs into the target website's bin directory, even though you've installed these DLLs into the GAC, which I assume is why you want to change this at the release level--so that space can be saved.
I also assume that you are intending to do this at the Release Branch only, and not at the development branch of your source control. Because if you are doing this at all branches of source control, then doing by hand is actually the best and fastest way of doing this for a one-time change.
To do this in MSBUILD, you will need to create a custom task that can modify the project file. The project file is an XML file, so you could use XPath as your custom task in MSBUILD. In the project file, you will find tags for "" to your referenced projects. You will need to change those to "" tags instead. Use existing examples of the tag in your project to see how it should look
Sorry I don't have sample code for this--doing it this way will be a bit of an undertaking, as there will be a number of things to take into consideration, and it might end up not being feasible.
Please excuse the large amount of background info, but this is a fairly specific question.
I have a Visual Studio 2005 project that creates a .dll file. This project depends on a .dll from another company, "BigCorp", which gets installed with BigCorp's software.
Ideally the dll I create should be usable with any (backwards compatible) version of BigCorp's dll. That is, if I link against version 4.3.2.100 my program should still work if the user upgrades BigCorp's app so that the .dll is version 4.3.3.20.
This is straightforward enough in VS2005, by looking at the project's References, selecting the .dll and making sure the "Specific Version" property is false.
Now for my actual question: Is it possible to specify a base version of the .dll that is older than the one installed on the machine that is building the project? Continuing my previous example, my build machine has version 4.3.3.20 installed, but I want the .dll it generates to be compatible with installations that haven't upgraded, and only have version 4.3.2.100 installed.
It seems that VS resolves the path to the .dll and detects the runtime version based on the file it finds. Trying to override it by specifying the version number directly in the .vbproj or .csproj, i.e.,
<Reference Include="BigCorp.Program.Component, Version=4.3.2.100, Culture=neutral, PublicKeyToken=abc123def456654fed321cba, processorArchitecture=MSIL">
has no effect. Trying to register my assembly on a computer that has the older version fails with the good old "Could not load file or assembly" error because it tries to find the newer version of BigCorp's .dll.
Is what I want to do even possible?
You can do this by referencing the older DLL directly from the project, so copy the .dll file to your project, then reference it from there.
I do this all the time with my various development projects. Typically I'll put a "References" folder inside my project to hold referenced DLL's