I have a C# project which references a DLL (call it external DLL) which comes with another application. When I build my project, due to the reference, the external DLL gets automatically added to my project output. And when I run my project it loads the external DLL from my project folder.
The other application, which the external DLL belongs to, is developed by another team and the DLL is regularly updated. I don't want to package their DLL with my project. Instead I would like to have my project load their DLL when executed -- rather than pick the DLL copy from my project's folder.
Now I know that this is possible through reflection. I know that I can do an "Assembly.Load" and pick the DLL. But because I use the types from the external DLL all through my code, I would like the code to be statically type checked.
Here's what I would like:
Be able to compile my project by referencing the external DLL and thus get static type checking.
When the project is run, the external DLL is picked up from the other application's folder and not the copy of the DLL which is in my project's output folder.
Is there any way to solve this problem? Is there some middle ground between adding a reference and using reflection?
The most immediete solution to your problem is to change the properties of the reference. There is a setting called Copy Local. Set that to false and it'll stop copying the DLL to your project's output. You can access the properties of the reference by expanding the references folder in your solution, right-clicking on the reference in question, and clicking properties to open the properties pane.
The fact that Visual Studio copies the DLL to your project's output folder at build time doesn't really matter to the .Net Framework at runtime. All that matters is that the assemblies you reference are available to the framework either in the paths it searches or in the global assembly cache.
Related
I'm using an external DLL to handle PDF exports in a C# project. I've added the external DLL reference in Visual Studio, added appropriate using statements, Intellisense shows all sorts of methods and properties when I type out the namespace, and the same is reflected in the object explorer.
However, when I run the application, the program throws a run-time exception because my external DLL can't find another DLL that lives in the same directory as the external DLL.
To make matters more confusing, the program doesn't complain if I just copy every single DLL from the directory of the one I want to reference into the Debug folder of my program, but obviously I shouldn't have to do this.
Thanks in advance.
What you need is to check "copy to output directory", "always copy" in the properties of your DLL in VS.
Otherwise the DLL is not automatically copied in the output, and the program can not run.
I think this other question might help you: MSBuild doesn't copy references (DLL files) if using project dependencies in solution
Looks like your dependency has another reference you want to include into your drop. You have two options:
- Either add a reference to that implicit dependency as well (and set "Copy Local" = true)
or
- Add the dependent dll as a project item and mark it as "Copy to output directory" = true.
I have a solution with quite a few projects in it and several dependencies to external DLLs. While trying to build a x64 version of the solution, I found that when building one project several libraries are copied into the output directory which are not mentioned in the project's references or anywhere else within the solution. I figured out that there is a collection of file names called _CopyFilesMarkedCopyLocal, which contains these DLLs. In the concrete case the copied library was used indeed, but it is a x86 library, which overwrites the existing x64 file in the output folder. How does a DLL, which is not mentioned in any project of the solution, become part of this collection? Can some referenced DLL induce further implicit references? Can I control this behavior?
Update: In the x86 build the set of file names contained in _CopyFilesMarkedCopyLocal is what I expected, namely one reference explicitly mentioned.
Please any one explain this. This Question helps to understand common things
Question:
What is the difference between when you 'add DLL reference from one project to another project via Browse Option and Add DLL reference from Solution project to another project and copy-paste from one project to another project'?
I have found an answer on google
Answer:
Adding a project reference adds a local project's DLL to the project that references it, and every time the solution compiles, the updated DLL for that project gets copied to the other project. So when you go through the build process, if you have 5 projects, each one rebuilds its DLL, and copies that DLL to its references.
But:
I don't know what the process is and the difference when we copy-paste from one project to another project?
When you do copy paste from One project to another, the dependent project add its reference of the file that you have paste in the project solution directory
When you do copy paste the dll of one project to the other project's directory and then Add its reference by browsing to that directory where you have pasted your dll. Then VS only add its reference and copy that dll to its bin folder and show you (allows you) all the method and properties that it contains.
If you do any change in your source project solution like adding or modifying methods then the updated dll of that project is not available in your dependent project solution.
So VS still points to the old dll file just because of the reference you added. So whenever you made any change in your source project solution, you have to add the reference of the updated dll to your dependent solution every time.
In Second Case: When you add reference of your source project into your dependent project solution, VS always take the most recent updated dll from your source project into your dependent project. So in this way you don't need to add reference every time you compile the code or debug.
When you just reference a DLL by browsing to it, VS would copy it to the output directory of the dependent project.
Suppose afterwards that DLL is updated - there is no guaranty that VS would retake that updated DLL, and copy it again to the output directory of the dependent project - which mean, that even after you fixed some bugs in the other project, those bug would persist in the dependent project (because it is still using the previous version of that DLL).
When you add reference to other project in the solution, VS would always take the most recent and updated DLL outputted from that project.
Our project has a lot of external DLLs, most but not all of which are 3rd party DLLs.
Currently we do not have these DLLs included in our project. They are included in SVN and given a path to our build output directory. So, after building our project the neccessary files are there, because of SVN, but the project itself has no knowledge of them.
My feeling is that we should have a folder under the root of our project named something like Dependancies or ThirdParty with all of the DLLs included there and set their build event to copy to the output directory. They would exist in SVN as well, but in the same structure as the project, not in the build output directory.
The project itself only references one of these DLLs called CommunicationProc.DLL. The CommunicationProc.DLL then references all of the other DLLs. We have numerous DLLs to support different types of radio. So not all DLLs will be used, but any one of them may be used depending on the radio type.
As to whether or not the DLLs should be included in the project we have differing opinions internally, some of the team beleives they should only be in SVN and not part of the project itself.
Of note is that this are not .NET DLLs, most are old C DLLs.
What is the accepted practice? Can someone please provide me with a compelling arguement one way or the other as to whether to include them in the project or just SVN?
Its better to have them in a folder on source control and then copy them over to the debug folder on build event. This way you can manage their versions. If a newer version of some dll comes then you can replace the old one and put some comments with check in. Also if you are working in a team, then instead of copying files from debug folder to each team member, you can let each team member to use the same set of dlls from source control. If you are developing some control and want your customers to use that control then its easier for you to have a set of dependent dlls some where so that you can give those to your customer along with your .Net dlls.
I had the same issue with some un-managed dlls and ended up putting them in a folder so that all the team members have the same version of the dlls. Hope this helps.
I include a project that has no code but contains a folder where all the external assemblies and their dependencies are kepts. For each file set the Build Action to None and Copy to Output as Do Not Copyp. The project then references the binaries from this location. In your other projects, reference this special project. When you build, because the special project is referenced and it references all the needed dependencies, the binaries are copied as needed.
If you do not want a special project, still create the folder in your main project, added the assemblies, set their properties, then reference the assemblies as needed.
This gives you complete control over the versions and output, and more importantly, it is simple.
I make use of the Belgium Identity Card SDK for reading data from a idcard.
The SDK exists of 2 components: interface dll and a wrapper dll.
In VS2010, i can make a reference to the interface dll, but not to the wrapper dll, so I put it manually in the bin folder. When I migrate my application to another pc on the localhost, it is not able to find the wrapper dll.
Not even when I (on the 2nd pc):
-installed the sdk.
-put the wrapper dll into the bin folder and system32 folder
In visual studio, properties of the interface dll, I've set "Copy Local" to true.
What can I do?
This could just be a difference in path names between machines.
I would create a folder at the top level of your solution and place these DLLs in there. Call it something obvious like "Solution dependencies". Then you can reference them as needed and set them copy to local as required. You wont always be able to reference a DLL, especially if it isn't .NET compatible.
I'm curious about your statement of interface and wrapper dlls. Is the wrapper dll not meant to be a .NET wrapper for a C++ style dll?