I have a Teamproject which has only one solution, which contains a MVC web application and a MS Test project (Unit tests).
The Unit test project references the web app.
MyWebApp
MyWebApp.Tests
I can see all files being copied to the Build_SourceDirectory!
But I can only see the MyWebApp.Tests being copied to the Drop folder!?
My Visual Studio buil step:
My Copy Files build step:
Question:
Why does "Copy Files" build step only copy the artifacts of the test project and not the web app, which is in the same solution?
Here is the log file
**\bin\$(BuildConfiguration)\** means you want to copy the files in any sub-folder under bin\$(BuildConfiguration), but MyWebApp's outputs are in bin folder, not under bin\$(BuildConfiguration), so they are not copied.
Specify the Contents in Copy Files task to **\bin\**, you'll get both outputs for MyWebApp and MyWebApp.Tests:
An addition to the provided answer.
With the OOTB minimatch filter:
**\bin\$(BuildConfiguration)\**
you copy everything beneath the BuildConfiguration folder (Release/Debug/etc).
Web apps don't have a Debug/Release folder by default, only one bin folder. That's the reason why anything was copied to the drop folder.
So I had to include some content filters to include/exclude the files/folders I want to copy/don't want to copy, like this:
For exclusions you can use negated filters using the ! sign.
Related
We have a build pipeline set up with a "Visual Studio Build" step. I just need it to copy one of the project files into the build folder before publishing it to our server. Trying to copy a .runsettings project file for unit testing.
So far I've tried setting the file to "Copy to Output Directory" in its properties, I've tried using both copy and xcopy in the post-build event command line and tried a few different syntaxes for that in the xml csproj project file. Everything that seems to work fine locally, doesn't do anything through azure. My brain has been wracked thoroughly!
Any help would be greatly appreciated!
Edit:
This is what the copy settings look like:
I tried this as well as ***.runsettings in contents as suggested.
Here is the log from my last copy attempt
2020-05-29T20:07:01.3481827Z ##[section]Starting: Copy .runsettings to: E:\Backend_work\116\a
2020-05-29T20:07:01.3669241Z ==============================================================================
2020-05-29T20:07:01.3669530Z Task : Copy files
2020-05-29T20:07:01.3669781Z Description : Copy files from a source folder to a target folder using patterns matching file paths (not folder paths)
2020-05-29T20:07:01.3670032Z Version : 2.164.1
2020-05-29T20:07:01.3670179Z Author : Microsoft Corporation
2020-05-29T20:07:01.3670406Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/copy-files
2020-05-29T20:07:01.3670656Z ==============================================================================
2020-05-29T20:07:01.9575993Z found 1 files
2020-05-29T20:07:01.9583367Z Copying E:\Backend_work\116\s\UnitTests.runsettings to E:\Backend_work\116\a.runsettings
2020-05-29T20:07:01.9674455Z ##[section]Finishing: Copy .runsettings to: E:\Backend_work\116\a
I've tested with the following post-build event command line and it copied the file in pipeline as expected:
copy "$(ProjectDir)Settings1.runsettings" "$(SolutionDir)TestCaseProject\bin\$(ConfigurationName)\*"
Pipeline log:
Including using enter image description here, you can also try adding a Copy files task in Pipeline to copy the file:
How can I declare that the "root" folder for all deployment items are the .sln dir?
Seems like I work really hard with relative paths of deployment items
[TestMethod]
[DeploymentItem(#"..\..\..\MyTestFilesFolder\myFile.xml")]
public void Test_bla{}
Given that "MyTestFilesFolder" is near my .sln file (solution folder) I'd like to have
[TestMethod]
[DeploymentItem(#"MyTestFilesFolder\myFile.xml")]
public void Test_bla{}
How can this be achieved with tests of vs2013?
It seems you are not deploying the xml files with your unit tests. Go to the properties of the xml files and set the build action and to content and copy to output directory to copy always. Now the files are deployed to your test directory.
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
I want to add an deployment item to my test. As far as I understood up until now, the path is relative to the solution. I want the path to be relative to the project. Otherwise, the project can't be used in multiple solutions.
How can I configure the deployment Item to be relative to a project dependent variable?
I was hoping for something like: [DeploymentItem(#"$(ProjectDir)..\..\bin\$(Configuration)")] but I don't find any documentation and it does not seem to work.
I just did a small test. Just plain wizard code and one deployment item:
[TestMethod]
[DeploymentItem("stdafx.cpp")]
void TestMethod1()
{
Assert::Fail();
};
and the trx file shows the following line:
Warning: Test Run deployment issue: Failed to get the file for deployment item 'stdafx.cpp' specified by the test 'TestProject1.UnitTest1.TestMethod1': System.IO.FileNotFoundException: Could not find file 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'.
System.IO.FileNotFoundException: Could not find file 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'.
File name: 'd:\Development\Projects\deploymentItemTest\stdafx.cpp'
which means that "stdafx.cpp" is searched relative to the solution directory (which is in ...\depoymentItemTest) and not the project directory (which is in ...\depolymentItemTest\TestProject1)
I know this is an old question, but my answer may help others.
I was able to solve this problem with two simple steps:
Create the following build event on the test project:
xcopy /I /S /Y "$(TargetDir)*.*" "$(SolutionDir)\bin"
This will copy all the contents (including sub-directories) of the project folder to a folder "bin" relative to the solution.
Add the following DeploymentItem to the test class:
[DeploymentItem ("bin")]
This will copy all the bin contentes to the test folder
This mechanism may be refined (if required) with additional filters both in the build event and the DeploymentItem
Let the test setup copy the file to Environment.CurrentDirectory.
I use VS2010 for unit testing. Does anyone know how to specify the location of where VS 2010 put its TestResults? By default it put a TestResults folder in the solution folder, I'd like to move it out somewhere else.
Thanks,
Ray.
Currently, this is not possible to control from within the IDE, see http://social.msdn.microsoft.com/Forums/en/vststest/thread/4ff650e1-a99a-4bd4-8311-6007f2a6e16e.
However, if you can use MSTEST.EXE from the commandline, it will use the current folder to generate the TestResults folder in.
Update:
Found this in http://blogs.msdn.com/b/vstsqualitytools/archive/2010/10/24/test-agent-test-controller-and-mstest-faq.aspx:
How to customize the default deployment directory?
You can change the default deployment folder by editing the test settings file in the XML editor:
<Deployment userDeploymentRoot="C:\TestResults" useDefaultDeploymentRoot ="false" />
Note that ,if the test settings is modified by XML edit (instead of using the default editor) VS need to be closed and reopened ( since the editing is done in XML , the changes will not be updated in the loaded settings.)
Best regards,
Marco Kroonwijk
MSTest.exe will generate results in the current folder as kroonwijk states, but you can override that with the /resultsfile command line switch by specifying the output filename in a different folder, it will also deploy a subfolder with the test files to the same location.
For example "/resultsfile:c:\TestResults\mstestreport.trx" will override the default deployment folder and also override anything that is in the <deployment> tag in the settings file.