Is there a way how to use web.config from my project that us under the test.
I have in mind something dynamically coping the file into my project?
You could use VS build events. Assuming you want to copy web.config from your webapp project to test project you can try something like this:
Select your Test project and open its properties window (Alt + Enter)
Navigate to Build events tab
Edit Pre-build event command line textbox to following line:
copy "$(SolutionDir)MyWebApp\web.config" "$(TargetDir)"
Command above will take web.config file from your MyWebApp project in solution directory and copy it to current project's (Test) target directory (which should be \bin).
Now, everytime you build your test project, web.config will be copied to its target directory.
I don't know what info from web.config you need in your test project. However, the need for a config file is usually a smell that you actually do integration testing rather than unit testing.
Related
In a C# csproj project, AppendTargetFrameworkToOutputPath and AppendRuntimeIdentifierToOutputPath prevent msbuild from creating subfolders for target framework and runtime in the build output directory. However, the configuration name is still appended.
Is there a configuration option to prevent a separate subfolder for each configuration?
So I figured out a solution to this. When editing the project settings in Visual Studio, it modifies the <BaseOutputPath> element in the XML project file. Simply change the element name to <OutputPath> instead, and it won't append the configuration name (and as you said, add <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath> and <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath> to disable appending target framework and runtime identifier).
As an example, I have the following in a <PropertyGroup> in a C# project:
<OutputPath>$(SolutionDir)Build\$(Configuration)\Plugins</OutputPath>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
For a debug build, this will output the build files to <SolutionDir>\Build\Debug\Plugins.
I am running the build command like this:
set MSBuildParams=/m:16 /target:Rebuild
/property:Configuration=""Release"";Platform=""x64"" msbuild
%MSBuildParams% C:\path\to\the\sln\Solution.sln
I'm using the following msbuild version:
Microsoft (R) Build Engine version 14.0.25420.1
Solution.sln contains 2 projects,
let's say Project1 and Project2.
Project1 is set as the startup project.
After I build the Solution.sln using this setup, I would like to
rebuild it, but this time using Project2 as the startup project.
Is there a way to do that, without changing the Solution.sln?
What would be the best practice to accomplish that?
You could use the specific command line to build/rebuild the specific project using MSbuild like the following case.
specify project file of a solution using msbuild
But we have to change certain files if you want to change the start up project without using the VS IDE, since the setting was stored into the ".SUO" file.
Actually there is no setting in ".SLN" file for startup project even if you don't want to change it,
In addition, the start up project was the running project of the solution, maybe you don't have to change it:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/b6347dce-8449-4cbb-a606-7b19407a1026/how-do-i-set-the-startup-project-in-the-sln-file?forum=vcgeneral
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.
I'd like to copy a file and include the file in the web project and would like to do this as a part of the Pre/Post build events.
My understanding is that these events support DOS commands and I can use xcopy for copying a file, but I am not sure how I would update the csproj file to include the file in the project.
Do you need the file to be in the output directory or actually be part of the .csproj file ?
If you really want to update the csproj file then try customising the AfterBuild target in the csproj file of the startup project in your solution. All csproj files are msbuild files and you can use the full power or msbuild including callling any task. Right click on the project in the solution explorer, select unload project and then edit project. Then customise the AfterBuild target to change the particular csproj file you want. Use built in tasks or the excellent extension pack for changing the file. Finally reload the project.
I've got a test which requires an XML file to be read in and then parsed. How can I have this file copied into the test run folder each time?
The XML file is set to "Copy if newer" and a compile mode of "none" (since it's not really a compile-able thing)
use a DeploymentItem attribute
using System;
using System.IO;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using CarMaker;
namespace DeploymentTest
{
[TestClass]
public class UnitTest1
{
[TestMethod()]
[DeploymentItem("testFile1.xml")]
public void ConstructorTest()
{
string file = "testFile1.xml";
Assert.IsTrue(File.Exists(file), "deployment failed: " + file +
" did not get deployed");
}
}
}
It seems that if you provide a TestSettings file for the Solution then you can uncheck the "Enable deployment" option and stop mstest from trying to run from the ...TestResults\...\out folder where it doesn't copy your extra files (unless you make them a deployment option).
This is also useful if you depend on the extra files being in a preserved folder structure because Deployment items all seem to be copied directly (flat) into the temporary run folder (out) if you use the Deployment, Add Folder option in the TestSettings (answers above suggest you can keep the structure if you add each item as its own DeploymentItem).
For me it worked fine running tests directly in Visual Studio (i.e. my extra files in their structure were found and used by tests) because I had created a TestSettings file for another reason long ago (which has Enable deployment unchecked), but not when TeamCity ran mstest to run tests because I hadn't specified that the TestSettings file should be used.
To create a TestSettings file in Visual Studio, right click on the Solution and choose New Item, and select the TestSettings template. To use the TestSettings file at the command prompt of mstest.exe add the option, /testsettings:C:\Src\mySolution\myProject\local.testsettings (or add as an extra command line option in TeamCity with appropriate path)
The Preet answer is used to deploy items for a single test. If you want to do it at solution level, use the .testrunconfig settings.
Best solution to me is using testsettings, especially if multiple tests need the same datafiles.
First create a testsettings file, and add the deployment items you need (file or folder name):
<TestSettings name="Local" id="00ebe0c6-7b64-49c0-80a5-09796270f111" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>These are default test settings for a local test run.</Description>
<Deployment>
<DeploymentItem filename="Folder1\TestScripts\test.xml" outputDirectory="TestScripts"/>
<DeploymentItem filename="Folder2\TestData\" outputDirectory="TestData"/>
</Deployment>
<...../>
Running in visual studio, use "select Test Settings File" from "Test\Test Settings" menu to select new testsettings
Running mstest, use the /testsettings parameter to have mstest use your testsettings.
You can define DeploymentItem in a class that holds a method with AssemblyInitialize attribute. Then you're sure that the files are copied regardless of which test you run.
Unfortunately DeploymentItem attribute is executed only on classes which contain tests you're running. So if you have 10 test classes which use the same set of files, you have to add the attribute to all of them.
Also found out that changes in *.testsettings files are not automatically refreshed in Visual Studio. Therefore after adding files / folders into deployment in testsettings, you have to reopen solution file and then run the tests.
In Visual Studio 2012, vstest.console.exe (the built-in test runner) runs with the output dir as the current path. This means that you only need to include the items in your solution with the 'Copy always' or 'Copy if newer' property for them to be used by your test. You don't need the DeploymentItem attribute for the general case. The same applies when running vstest.console.exe from the command line inside your output/test directory.
There are some cases where a separate folder is used, one of them being when you are using the DeploymentItem attribute. See here for more information.