By way of background, I'm trying to get one of the Emgu CV examples working. It is the Motion Detection example mentioned in the answer to "Looking for a function for motion detection on emgucv"
To get the example code working I need to add references to the Emgu CV DLLs to the project and also make sure that the relevant Open CV DLLs are copied to the output executable directory of the project build. The relevant DLLs are listed on the EMGU wiki.
I'm adding the Open CV DLLs by adding them as content to the example project and marking them as "Copy always" in the content properties:
I do not want these cluttering up the root level of the project so I have added a project folder to put these DLLs in:
However when I build the project the DLLs are copied with the same directory hierarchy, i.e. they have an enclosing folder within the execution directory which I do not want:
What properties do I need to set to ensure that the DLLs are copied into the execution directory but into its root rather than in a sub directory?
========== EDIT ==========
Note that I cannot add these DLLs as references to the project as they are neither .Net assemblies nor COM components but the Open CV C++ libraries.
Talking to another developer at work he uses another workaround. He keeps the DLLs in a project folder and then adds a post-build event in the project's property pages to copy the DLLs into the directory with the executable:
copy/b/y "$(ProjectDir)Libs\*.dll" "$(TargetDir)"
user7116's advice and my colleague's are great workarounds but I'm going to leave the question open just-in-case someone discovers (or Microsoft adds) a way to actually set properties on the content files to ensure that the DLLs are copied into the root of execution directory rather than in a sub directory.
Our group keeps the files in a folder similar to you, however instead of adding the folder to the Project, we reference these DLLs in your main project by adding the items as a Link to the top level of your folder:
As before, set each item as Content and Copy Always (items shown in a solution folder):
Then when you build they will make it to your output directory:
It isn't as pretty--you still see them all in your main project--but it at least puts them in the right place.
Related
I have moved binary files into the project under the bin folder to avoid publishing the same binary files twice since one of the binaries is huge; i.e. 15MB.
This was originally in a separate Includes folder. So the files were being copied twice to the publish folder.
Is the bin folder the correct placement for these or are there other steps I should take?
Edit:
Sorry if I gave a poor explanation (and original title). I've changed the title; this was "Where should static libraries (3rd party DLLs) be kept in Visual Studio?", and is now, "How can I avoid publishing the library folder in a Web Publish?"
As mentioned, I originally had a separate folder named Includes. When I did a Web Publish, each of the DLLs are published twice; one into the bin folder, the other into the Includes folder. In this case, I am publishing at least an extra 15MB of unnecessary file space. Normally, not a big deal but if I am on a very slow connection, I'll need to wait longer to deploy the project to its environment.
I moved the DLLs back into a separate folder but the folder is still published along with the bin output folder. I did this to see if the placement of these files would set their properties differently.
I have tried various settings for Build Action and other property settings for these libraries without success.
Is there no way around publishing the DLLs twice?
If these files are part of the overall source of the system (not necessarily as source code, but as source-control-tracked artifacts nonetheless), then you probably don't want to keep them in the output folder for the build. The output folder should be transient and shouldn't be tracked in source control.
Keep 3rd party libraries in a library folder. The folder structure in source control might look something like this:
/
--/lib
--/Project1
----/SomeSubFolder
--/Project2
----/Images
----/Styles
and so on.
Each Project would have its own bin folder when it gets compiled, which itself may contain other folders for types of compilation (Release, Debug, etc.). But you don't want those build artifacts tracked in source control or in any way interfering with what's in source control.
The projects would reference their library dependencies, and at build time those dependencies would be copied to the output folder to be used by the application runtime.
I have 2 c++ projects in a solution.
ExecB (an executable) depends on ProjA (a dll).
So in ExecB's properties I add ProjA as a reference, and select Copy Local = true.
The problem is, ProjA's dll isn't being copied to ExecB's output folder folder. So the executable obviously doesn't run.
Any suggestions ?
For C++ projects, the Visual Studio template/wizard sets the Output Directory to a subfolder of the solution: $(SolutionDir)$(Configuration)\. This is so the DLL Search Path works well for the developer. It even works if you have added projects to the solution from outside the solution folder hierarchy; The build will put all binaries into the output folder for that solution.
If this isn't working, check the Output Directory property on all platform/configuration combinations of all your projects. Also make sure that the Build Configuration Manager shows that your selected solution build is building all the projects appropriate for the solution platform/configuration.
The Copy Local in Project References that you are trying applies only to referenced .NET assemblies. The docs are ambiguous and too terse on that. (Most often undistinguished use of "assembly" means .NET assembly rather than WinSxS assembly.)
I'd like to include some folders of static files shared between many projects and solutions.
These files could be images, script libraries or css that are shared between many projects.
I do not want to copy each time the folder inside the project structure but reference it just as we can link files between projects in the same solution so if any file changes in the referenced folder all the projects that link to it will have an updated version.
I know I can put it in a shared dll and embed resouces in it but I'd like to be able to choose witch folder to include.
Is this possible with Vs2010 or Vs11?
Sure, its possible, and not even that hard. Put the files in a well-known location in your hard drive, then add them to each project as a link. See the second section in the following article:
http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx
If you use source control, I would strongly encourage you to have at least one separate folder per solution file, and nest the folder under your solution root somewhere. TFS, in particular, gets antsy if your solution file includes locations that are outside the current workspace. (It will work but you may get strange warnings or errors, particularly if someone else tries to get the solution for the first time.)
I have a couple of different solutions, in which some projects may depend on output from projects in other solutions. To manage this, I've been copying dll files from the /bin/ folder in each project to a shared library location after build, and then copy/reference them from there to the dependent project.
However, as the library solution gets larger, this tends to become unmaintainable. Too much of my time is being spent traversing solution directories in Windows Explorer looking for /bin/ folders, and trying to figure out which one, or which ones, of the dll files from each one I need.
Is there any way to give Visual Studio a hint that I want all projects in a solution to have the same output directory? For example, a /bin/ folder directly under the solution folder, where all projects put their output.
If possible, I'd like to achieve this without hard-coded post-build events that copy the files, since that will fail if a project output changes file name, or adds another file. I'd rather like to change the location of the actual output directory - the location of $(OutDir), if you will.
I know you said you don't want to use post build events, but your reason as to why not intrigued me. It sounds like you might be hard coding the name of the .dll in your post build event. That can easily be avoided.
xcopy "$(TargetDir)*" "c:\common\" /Y
The * would just cause everything in your bin/Debug/ folder to get copied to your common folder. You could also just copy dlls if you want. Or, if you use $(TargetPath), you'll copy just the 1 dll that is the result of the project, and not any other related dependencies.
UPDATE
The way we do it is each projects entire bin folder is copied to a subfolder. Suppose you have 2 projects, WebUtil and HtmlParser, where WebUtil depends on HtmlParser. For both projects, use xcopy "$(TargetDir)*" "c:\common\$(ProjectName)" /Y. This will create c:\common\WebUtil\ and c:\common\HtmlParser. In WebUtil, add a reference to c:\common\HtmlParser\HtmlParser.dll. There will now be 2 copies of HtmlParser.dll in c:\common.
c:\common\HtmlParser\HtmlParser.dll // the most recent build.
c:\common\WebUtil\HtmlParser // what was the most recent build when WebUtil was built
This has all kinds of advantages. If you change the API of HtmlParser, WebUtil will continue to work, since it will have the older HtmlParser.dll until you try to rebuild WebUtil (at which point you'll get build errors because of the changed API).
Now, if a 3rd project got in the mix that depended on WebUtil, and you're using some part of WebUtil that exposes classes in HtmlParser, then you'll need to add a reference to both projects from your new project. When you add a reference to HtmlParser.dll, use the one in c:\common\WebUtil. You do this because you're only including it as a necessary requirement of WebUtil. Now you'll always have the version of HtmlParser.dll that matches your current version of WebUtil.dll.
I hope that makes sense. It can definitely be a tricky thing to manage. Just wait till you have to start pulling down all your dependencies using svn:externals =P
You can set the output directory in each project properties.
Right click on the project, select Properties
For C#, it is one of the Build property page, under Output, Output directory.
In VB.Net projects, it is on the Compile tab, in the textbox at the top.
I'm working through installing the N2 content management framework in an ASP.NET website project.
The instructions at http://n2cms.com/Documentation/Content-enabling%20an%20existing%20site/The%20first%20content%20class.aspx recommend I create a lib folder to hold the required dlls. The very next step asks me to reference those same dlls - which will presumably add them to the bin folder! Thus my project will contain duplication copies of the dlls.
Can anyone suggest why this recommendation has been made?
Thanks
David
The project will not contain duplicates. The bin folder is where the output goes, but it is not considered part of your actual project and is not checked into source control.
By placing the DLLs in a lib folder, it makes it easier to distribute them with the source of your application and ensures that anyone else who gets a copy of your code, whether you send it to them or they grab it from source control, has the necessary DLLs to run the application. It also ensures that they are use the same version of the components that you used to create the software. If the DLLs require licensing, it can be a different story because anyone who wants to compile the project would need the licensing component for the DLLs installed on their workstation.
Basically, the main benefit I see is that it keeps all components used by your code in the same place, making your project one whole unit.
If you add the DLLs to the bin folder, then one day decide to clean your project, they will disappear... So it's good practice to keep your reference DLLs out of the bin folder.
Actually there's quite a few ways the DLLs can be accidentally removed from the bin folder. Just think of the bin folder as a transient location, the contents of which can be refreshed at a moment's notice.
During the build process all relevant files will be copied to the bin folder, including config files, content files marked for copy to the output folder, and of course, any referenced DLLs marked for Copy Local.
If the duplicate locations bother you, you can keep the DLLs in another folder, and just add the containing folder path to the PrivateBinPath of the current AppDomain, which will ensure they get loaded without requiring the Copy Local property.