I have several build configurations and depending on the configuration chosen, I need to copy the dll to a created folder. Basically, my executable is located on c:\project and my dll is in c:\library. I need to setup a post-buildevent on the dll so that it creates a folder called custom in the c:\project executable directory and then copy the dll to this custom folder. How do I accomplish the above? One thing I have noticed is that a post-build event on the dll does not give me access to the executables directory and I don't want to have to hard code something like c:\project\bin\debug for example.
Related
My Question is, When i am building any solution all the dll's are copied to bin folder. Can we split this dll's with different-different folder's once build is completed? i.e I am having some third party dlls and some other dlls like DevExpress dll's so i want to separate all of then in thier specified folders.
Please dont suggest for manual copy paste. Developers is pulling code from git hub once it is build then folder structure can be made automatically.
Please suggest if we can do with Post-Build Event.
Thanks in Advance.
You could copy files through Copy task after build. For example, (add to the end of your project file):
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.
How can I consume a registration free COM object without copying the dll to the same directory as the executable? Is this possible?
I would like a complete working sample or a detailed step-by-step guide for my exact scenario.
For example, I have the following components:
CppTestRunner.exe - vc++ console application
CppTests.dll - vc++ mfc dll
CsCOMServer.dll - c# COM visible dll
I do not want to modify the exe or its directory, like adding an external manifest.
CppTests.dll is in a different directory than the exe.
It is okay if CsCOMServer.dll is in the same directory as CppTests.dll.
CppTestRunner.exe calls LoadLibrary on CppTests.dll which works fine.
After embedding manifests and using the windows activation context apis, I was able to copy CsCOMServer.dll to the exe directory to verify that CppTests.dll can create an instance of CsCOMServer.dll without issues, but again, I am trying to avoid this step.
Currently, with CsCOMServer.dll in the same directory as CppTests.dll, and without CsCOMServer.dll in the exe directory, I am getting the following error when I call CoCreateInstance:
Error = 0x80070002 The system cannot find the file specified.
I have used sysinternals process monitor to track down the paths CppTestRunner.exe looks in, etc.
I notice that depending on the things I try to do, sometimes CppTestRunner.exe tries to read CsCOMServer.dll.config in the same directory as CppTests.dll, but no matter what I try to put in there, I was not able to get past the error.
Also depending on other things I try to do, CppTestRunner.exe tries to read CsCOMServer.dll in the same directory as CppTests.dll but for some reason, I still get the same error.
Anyone know of working code with this exact scenario?
As you can probably tell, this is part of some unit\integration tests.
As a simple workaround, I am currently copying CppTestRunner.exe to the same directory as CppTests.dll and running it from there, but would like to avoid this step.
Thank you.
.NET looks for managed registration-free COM first in the GAC, then in the executable's folder. It uses the activation context to read activation metadata, but not to determine the location of the files themselves.
You can save the DLL in a sub Folder, let say DLLFolder\YourDll.dll, and in the manifest file of yourDll, write the filename like
<file name = "DLLFolder\YourDll.dll">
But you need to keep the manifest file (of the DLL) in the location where the EXE is saved.
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I'm writing some extension and I need to pull out data from the file that is included into vsix. But if I'll use Environment.CurrentDirectory I will not have this file because this folder points to VS folder not on the extension's one. How can I define it in a run-time?
System.IO.Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase get the path to the executing dll.