I am wondering if there is a way to set the deployment setting under Local.TestSettings in a Visual Studio 2010 Test to a relative path. Right now we have to copy over a couple of DLL's in order to use our tests correctly. We have this path hard set on a machine, but this gets messed up if you accidentally commit that file and then someone updates.
You can use test setting to add one deployment item. And continually use notepad to edit the *.testsettings file. Then, manually add "outputDirectory" attribute to the deployment item.
For example, there is one folder named "Config" in "myProj" which contains your online codes. And you want to copy all configuration files under the folder - "Config" to your test project - "Test.myProj" and make them also be placed under "Config" under "Test.myProj"
So you need to manually change the *.testsettings and add the following item in the file.
<Deployment>
<DeploymentItem filename="myProj\Config\"
outputDirectory="Test.myProj\Config\" />
</Deployment>
P.S. VS2010 did not allow to input value to "outputDirectory". So u have to use notepad or text editor to update it.
What is the source for these DLL's? How are they being used, as reference DLL's? If they are third party DLL's the tactic we usually do is place them into a "Reference DLL's" folder and add them as deployment items. When VS goes to execute the test it will copy them to the OUT folder along with the test DLL. Now that they're both in the same folder your tests should have no problem finding the needed reference DLL's.
If these DLL's are of your own creation (or your group/organization) I would add the project to the solution then add the reference as a Project reference. VS will automatically detect the dependency and compile the additional projects and copy the built reference DLL's to the out folder.
Related
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 specifically should my command line be written as to copy the output from one project into the output of another project? The list of macros that are avaliable does not list anyway of accessing OTHER project directories under the same solution:
http://msdn.microsoft.com/en-us/library/42x5kfw4(v=vs.80).aspx
Here is what I currently have:
copy "$(TargetDir)FILE_TO_MOVE.EXE" ""
What should I put in the second quote to complete this command?
NOTE: A similar question does NOT actually show you HOW to do it, which is what I am asking: Visual Studio 2008: How do I include project output as an embedded resource in another project?
It is much easier to do it the other way around, have the project that has the dependency on the file also copy the file. Which you can do in the IDE without pre/post buid event or macro trickery.
Ensure the source project is built. Right click the target project, Add Existing Item and select the file. Click the added file in the Solution Explorer window and set the properties to Build Action = Content, Copy to Output Directory = Copy if newer. And right-click the target project, Project Dependencies, tick the source project to ensure that it always gets built first.
I am assuming that yout are copying the "FILE_TO_MOVE.EXE" in the post build events of your project.
The thing about the build events in Visual Studio is that they are run just like a batch file, therefore I beileve that the easiest way to solve your problem is to use a system environment variable in your project... This way your code would be similar to the one below.
copy "$(TargetDir)FILE_TO_MOVE.EXE" "$(MyVariable)"
Note: Visual Studio doesn't let you use your environment variable like this: %MyVariable%.
I think the correct way now would be to simply add your secondary project, i.e a Windows Service, to the References of the main project.
For example if you have a main GUI project (that the solution was created with), and a second Service project added to the solution, adding it to References of the GUI project will cause the EXE and the PDB of the service to be placed in the Debug/Release folder of you main project.
I am not sure if you still need to add the Project Dependancy as Hans suggested . This is probably automatic thanks to the reference.
I have a Visual Studio 2010 project which references some third-party components. Their assemblies are accompanied by XML documentation files, which are useful for us (and only us) developers. And whenever the project is built (either in Debug or Release modes) these XML files are copied to the build directory.
I can't seem to find a setting or switch to disable the copy of those XML files to the build directory, either within Visual Studio or though MSBuild. A post-build script may be an option, but a smelly one. Any ideas? Thank you.
When you build a project the .xml/.pdb files are gathered through the ResolveAssemblyReference task. When ResolveAssemblyReference is called it is passed a list of file extensions for related files. That list of file extensions is captured in the MSBuild property AllowedReferenceRelatedFileExtensions. By default that list will contain ".pdb;.xml".
If you want to exclude all related reference files from being picked up then just override the value of the property to something which related files won't have extensions of. For example you can set AllowedReferenceRelatedFileExtensions to "-".
You can also customize the list of file which are returned by that. If you only want to find only .pdb files then you will need to pass in AllowedReferenceRelatedFileExtensions=".pdb". In that case any references which have .pdb file next to the .dll/.exe they will be copied as well. You can also use this to copy other related files which may not end in .pdb/.xml. For example if you have a referenced assembly named, MyAssembly.dll and in that same folder there exists MyAssembly.pdb and MyAssembly.foo If you set AllowedReferenceRelatedFileExtensions=".pdb;.foo" then both the .pdb and .foo file will be copied to the output directory.
Visual studio project file has the same format as any msbuild file. So you can manually add the condition into corresponding section to not copy your xml files if configuration name is 'Release'.
It should be changing
<ItemGroup>
to
<ItemGroup Condition="'$(CONFIG)'=='RELEASE'">
or something like this.
If the .xml/.pdb are marked as build-action "Content" (etc), you can change them to "None". You should also ensure they copy-to-build-output is false.
Are both of those set?
What is the problem with having the XML files get copied into the folder on release builds? It seems to me that this is fine and that the real problem is with the code that picks up files to place them in the installer. Picking up third party dlls from your own bin\release folder is not a good practice in my opinion. I'd have my installer pick up third party dlls from their own folder in my source tree.
The setting is in the Properties of the project in question, under the "Build" tab, uncheck "XML documentation file". It's also an MSBuild property called <DocumentationFile> under the applicable <PropertyGroup> for your build configuration in the .*proj file.
I have two projects in one Visual Studio 2008 solution. I'd like to use the primary output from one of the projects as an embedded resource in the other, but for the life of me I can't find any way to accomplish this.
If I simply add the output file as a resource, then it doesn't seem to change when its source project is rebuilt. I even have the project dependencies/build order set up properly and this does not seem to help.
Anyone have any hints for me?
Thanks!
the best option is to "reference" the other project as if it were a class library.
that way you make sure the whole references tree is copied to your output dir.
When you add an existing file to a project, Visual Studio copies the file into the project's directory.
Any subsequent changes to the original file are ignored.
There are two workarounds:
Add a post-build action to the first project that copies its output file to the second project, and edit the dependencies so that the first project is always built first.
Add the output file to the second project as a link (Click the down arrow next to the Add button in the open dialog).
This will reference the file from its original location without making any copies.
Set the output directory of the project that generates the resource to point to the resource directory in the project that uses it.
If that's not possible for some reason, use a post-build command (also available in the project settings) to copy the file there.
I have a Web Setup project in VS. I'll be switching to WiX, but that's in the future and currently I need to solve the following issue.
I need to exclude some common dlls from the project. So I build the project, VS updates the list of Detected Dependencies. I exclude them and the setup builds. I check the file list with Orca and the files are not included in the installer.
But when I clean my output directory, reload the solution and do the build, some of the dependencies do not show as excluded! And so they end up in the MSI. (This is what is happening on the build machine).
I think that the problem might be with the fact that these are second-level dependencies:
my app -> NHibernate.dll -> Antlr3.Runtime.dll
(Antlr dll ends up in the MSI).
Is this a bug or am I missing something?
I found this page on msdn that has a work-around for the Exclude flag being reset to False:
Previously excluded files are included again when the solution is re-opened
When you exclude a file from a Setup project, you may see that the file is included again after you close and re-open the solution. This may occur if there are two copies of the same DLL file from two different source locations.
To work around this error, change the Copy Local property on one of the files:
In Solution Explorer, click on the DLL reference that you want to remove.
On the View menu, click Properties Window.
Change the Copy Local property to False.