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.
Related
Well, I'm not familiar with C#. Here's my story:
In the VS2010 solution, there are 2 projects: Entrance, Core and Plugin. Entrance may be compiled into an exe, while the others may produce dlls. Core is added to Entrance's and Plugin's reference. Plugin is set to be compiled to plugin folder. So after compiling, the output directory contains:
entrance.exe
core.dll
plugin\core.dll
plugin\plugin.dll
How can I remove the duplicate core.dll under plugin? Thanks.
In the Solution view of the plugin project, right-click on the core.dll reference and select Properties. Set Copy Local to false to prohibit copying of the assembly to the output directory. Note this will only work properly at runtime if the referenced assembly can be found by the application. In your case it's fine since core.dll is also referenced my the application but that might not always be so.
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.
At the moment I have added and referenced another project to my main solution. It works, but then I need the separate dll that is compiled.
How can I reference another project without the need for a separate dll that I have to distribute with my final exe?
A C# class project in a Visual Studio solution always compiles to an assembly, so adding a project reference will inevitably mean that your executable references the assembly built as a result of compiling the other project. If you don't want to distribute the separate assembly with your executable the only thing you can do is to ILMERGE the assembly into your executable as a part of your deployment build process,
You can't. The way .net works is to load an additional assembly and using its meta data the classes inside that. If you are attempting to have a set of classes that you refer to by source similar to the way c++ uses header files you will have to import those files into your project.
This sounds like you're trying to statically compile a library. This is not (easily) offered by .NET without manually creating and merging assemblies.
I'm attempting to implement a C++ DLL (of my own creation) that uses the Intel Performance Primitives in a C# forms application. I'm getting a "DLL Not Found Exception" when I attempt to run the program. One possible reason put forward in other posts on this site is that there are dependent DLLs that must be referenced and in fact after downloading DpendencyWalker I found that my DLL uses "IPPS-7.0.DLL".
My problem is that it is unclear to me how to reference these dependent DLLs. I've added the IPPS-7.0.DLL containing folder to referenced paths as well as added references to the "IntelCppOptPkg" and "IntelLibOptPgk" assemblies but this has not solved the problem.
So, am I correct in believing this is the problem? And if so, how does one reference a depedent DLL in managed code?
Thank you.
You don't reference them, they are not .NET assemblies. You just need to make sure that the DLL(s) get copied to your build directory. Easiest way to do that is with Project + Add Existing Item, select the DLL from wherever it was copied. Then select the added file and in the Properties window set Build Action = Content, Copy to Output Directory = Copy if newer. Checking-in the DLL(s) in source control is generally a good idea btw.
Managed code can not reference unmanaged dll the same way it references managed assemblies. Managed references actually change the meta data of your assembly:
The compiler records static
references in the assembly manifest's metadata at build time.
...
The preferred way to reference an assembly is to use a full reference,
including the assembly name, version, culture, and public key token
(if one exists).
Native dlls simply don't have this .NET meta data associated with them. They have to be copied manually in the Post Build step or during deployment. There is a workaround but I don't think it will work if your managed app is platform independent (Any CPU) and you have x86 and x64 versions of unmanaged dlls.
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.