I'm trying to get MSTest.exe to run, and it seems like testcontainer isn't being read properly; while my tests all run successfully in all config environments within Visual Studio.
the command I'm using is:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /nologo /usestderr /testSettings:"C:\temp\MyProject\Sources\MyProject\Local.testsettings" /searchpathroot:"C:\temp\MyProject\Binaries" /resultsfileroot:"C:\temp\MyProject\TestResults" /testcontainer:"C:\temp\MyProject\Binaries\MyProject.Services.Server.UnitTests.dll"
The project references within testcontainer project look like this:
<ItemGroup>
<ProjectReference Include="..\..\Services\MyProject.Services.Server\MyProject.Services.Server.csproj">
<Project>{92EC1999-CC0C-47DD-A4D6-17C3B1233C50}</Project>
<Name>MyProject.Services.Server</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Interfaces\MyProject.ServiceConfiguration.Interfaces.csproj">
<Project>{8E2E7BA9-75DB-458E-A184-AC1030EAD581}</Project>
<Name>MyProject.ServiceConfiguration.Interfaces</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Services\MyProject.ServiceConfiguration.Services.csproj">
<Project>{39514766-23A8-45DB-96EA-B6B4D9C8B086}</Project>
<Name>MyProject.ServiceConfiguration.Services</Name>
</ProjectReference>
</ItemGroup>
Neither the ServiceConfiguration.Interfaces nor the ServiceConfiguration.Services DLL is placed into the Out folder in TestResults.
The project GUIDs do match between the references and the referenced projects.
Is there something that I'm missing in the command line?
mstest.exe will not coy all referenced dll's.
See a blog post on this at https://web.archive.org/web/20111221110459/http://www.dotnetthoughts.net/2011/11/22/mstest-exe-does-not-deploy-all-items/
You can specify exactly what files are copied to the test directory using a test settings file. You can create multiple test settings files in Visual Studio, so you can have one for running from VS, another for running from MSTest, another for server CI builds, and so on. See here for more information: Create Test Settings to Run Automated Tests from Visual Studio
Use the /testsettings:<filename> option to specify it on the command line.
What seems to confuse people at first is that, by default, MSTest's "current directory" is not the MSTest launch directory, but the Out folder of the test results.
As mentioned previously, MSTest does not correctly infer all used assemblies, if you don't have a direct reference, it will not copy the assembly. That said, Visual Studio has similar behaviour in its build too, so a lot of people work around this by adding bogus code references - a terrible solution - I don't recommend it.
However, native DLLs are even more problematic, and I have found that explicitly copying them in the test configuration (test settings) works for them, just as for managed assemblies.
Whether it goes to Out or the build area depends on different factors, however, for the situations where it still doesn't work, you can use a DeploymentItem "hack", or, tweak your runsettings file.
Try looking at this answer: https://stackoverflow.com/a/33344573/2537017
Related
I try to add a folder and its subfolders (~4000 files) as content to a C++ windows store app (in VS2015).
Heres the scenario:
G:\Game -> is the build directory
D:\data -> holds the original content
I've read there are some methods to declare external content in the .vxcproj file like that:
<ItemGroup>
<Content Include="D:\**">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<DeploymentContent>true</DeploymentContent>
</Content>
</ItemGroup>
This actually copies the contents of D:\data into the build-directory (G:\Game). This is great since the program can now be run & debugged. BUT: as soon as i deploy the project to the AppX Folder (G:\Game\AppX) the data-folder doesnt get deployed there.
G:\Game\game.exe
G:\Game\data\...
G:\Game\AppX
G:\Game\AppX\game.exe
(G:\Game\AppX\data\... - missing)
Any clues ?
After fiddling around for days, as of now i can state there is no way to do this properly in the Visual C++ - IDE (2012 / 2015) (it seemed to work with C# projects though).
The only way to achieve what i wanted to do is
a post-build-event using robocopy to copy/synch the data over to the AppX folder
Writing a script for the packaging / signing using MakeAppX.exe, SignTool.exe and 7-zip.
After a clean Windows reformat and installing Visual Studio 2013, trying to build a project with database-first Entity Framework edmx files yields the following error:
The "EntityDeploySplit" task could not be loaded from the assembly
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll. Could
not load file or assembly 'file:///C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll' or one
of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements Microsoft.Build.Framework.ITask.
Is there some way to install this separately? What is this assembly included with by default?
UPDATE: This also manifests itself when looking for the EntityClean task. I'm inclined to think that it checks the bin first, since another developer who was running it fine tried a clean / rebuild and then this started showing up.
I found the accepted answer to be a little confusing, below are the steps that worked for me.
Open C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets in notepad.
Alter the UsingTask elements to:
<UsingTask TaskName="EntityDeploySplit"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploy"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploySetLogicalNames"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityClean"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
I ran into this problem and was able to fix it as I have described below. Your paths and variables may be different.
I found that when my project builds it points to this target file:
C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Data.Entity.targets
That target file appears to just be a placeholder. There is an Import element, in that file, that points to $(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.targets which runs the target file located at that path. I searched registry and found that MSBuildFrameworkToolsPath is a registry entry with the value of C:\Windows\Microsoft.NET\Framework\v4.0.30319\
I went to the targets file that was referenced and search for the UsingTask element that was specified in my exception. Inside the UsingTask element, the AssemblyFile attribute was pointed to $(MSBuildBinPath)\Microsoft.Data.Entity.Build.Tasks.dll. I searched the registry and found that the MSBuildBinPath registry entry was pointed to c:\Windows\Microsoft.NET\Framework\v3.5\
I'm not sure why it was pointed to that, maybe a Framework or Visual Studio installation didn't clean it up. Finally, I changed all my UsingTask elements' AssemblyFile attributes to:
$(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.Build.Tasks.dll
I used the same variable that was in the MSBuild Bin target file.
Hope this helps.
I give a lot of credit to Andy Mahaffey for his answer, without it I would not have found what I did.
I followed along his line of research but didn't like the idea of just changing the UsingTasks' attributes. I opened up the "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets" file and I found the first thing it says after the opening Project element is this comment:
<!-- This .targets file can be used by updating Microsoft.Common.targets to
include the line below (as the last import element just before the end project tag)
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
-->
I followed it's suggestion and presto, problems solved.
I hope this helps!
TLDR
Paste the line below as the last element before the tag in the following file. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
In my case, I had accidentally created two copies of one of my .edmx files, one in a subfolder, where I didn't notice it. Once I deleted the extra one, everything was fine.
I got a problem with MSTest Deployment,
i set folder deployment to something like that "..\MyProject\bin\debug\"
I know this path is relative to the test solution dir (C:\dev\MyApplication\Tests in my case) and it appears as
>Solution Directory>..\MyProject\bin\debug\ in the deployment GUI.
The problem is that there is no error at all but no folder or files are copied.
But if i put the full path like this
C:\dev\myApplication\MyProject\bin\debug\
i got a warning that it could not work on other computers as it's outside the solution folder.
despite that warning it works and all files from my debug folder are copied.
The problem is that i want relative pathes as every one on the team got a root path of the solution different of course.
Any Idea ???
I forgot to mention that this project was migrated from VS2008 where it worked to vs2010 where i have this problem.
The relativeroot is by default the solution directory. So this should be "MyProject\bin\debug\"
I am building a C++ solution with Visual Studio 2005.
Sometimes I open the solution in Visual Studio and build it from within the development environment. Other times I build it from the command line using msbuild.exe. I'm wondering if there is a way that I can determine which of these two types of builds I'm using at compile time (for example, a macro or something like like that). I want to change the path of my output files based on this determination. So, if I'm building from within Visual Studio I would put my output files in FolderA but if I'm building from the command line I would put my output files in FolderB. Is this possible?
Perhaps you can pass in a command-line parameter when building from the command-line that would indicate you are building the solution from the command-line. Otherwise, you can assume you are building from within Visual Studio.
I don't have the answer to your general question, but in order to change the output path, have you thought of adding project configurations ? You could copy project configurations and update the output path of the new ones.
As above really, I have some integration tests that use files from a relative file path. To help picture it here is the file structure:
/Dependencies
/VideoTests/bin/release/video.dll
/SearchTests/bin/release/search.dll
/OtherProjects
The GUI is running the tests from the root, however when TeamCity runs the tests it is running the tests from each test dlls bin directory. Now I don't mind which one I can get to follow the other but I do need them to be the same otherwise my relative paths just won't work!
Any ideas?
P.S. Using TeamCity 5.0 and NUnit 2.5.
You probably don't want to rely on CurrentDirectory. I'd suggest reading the doc, but the main point you'll want to take away is that the CurrentDirectory is where the .exe was started from: it could be any path in the system. For example, let's assume your users add your .exe (or whatever .exe uses your DLLs) to their path. They could then navigate to c:\foo\bar and start the .exe from there, which would set the CurrentDirectory to "C:\foo\bar" and you may not be able to deal with that.
I think it would be preferable for you to rework whatever you're doing so you don't rely on CurrentDirectory. What problems are you encountering by relying on CurrentDirectory right now?
Have you made sure that both TeamCity and NUnit are using the same working directory when starting the application?
And if they aren't, you could adjust the current directory in the test code.