I have some unit tests in my project that needs runsettings file to run properly.
When I launch those tests, I have issues with parameters that should be taken from the runsettings file
My question is how can I pass the runsettings file to visual studio code in order to use it when I execute my tests ?
Thank you in advance,
Regards
Two parts need file .runsettings when you work with VS Code:
when build tests in VS Code, it firstly run vstest.exe with parameters
when run tests in VS Code, it need mstest.exe.
For the first part, here is the document for .NET Core Test Explorer:
https://github.com/formulahendry/vscode-dotnet-test-explorer
The settings are available via File / Preferences / Settings. Navigate
to extensions and .NET Core test explorer.
Additional arguments that are added to the dotnet test command. These
can for instance be used to collect code coverage data
("/p:CollectCoverage=true /p:CoverletOutputFormat=lcov
/p:CoverletOutput=../../lcov.info") or pass test settings
("--settings:./myfilename.runSettings")
But above settings are global, you can setup from .vscode\workspace.code-workspace file for specified test project only:
{
"folders": [
{
"path": ".."
}
],
"settings": {
"dotnet-test-explorer.testArguments": "--settings .runsettings",
"dotnet-test-explorer.testProjectPath": "**/test.project.name.csproj"
}
}
For the second part, we need a new feature RunSettingsFilePath that's delivered from VS 2019 16.4.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<RunSettingsFilePath>$(MSBuildProjectDirectory)\.runsettings</RunSettingsFilePath> // or $(SolutionDir)
</PropertyGroup>
...
</Project>
If you're using the C# extension for VS Code, there's a setting to configure your .runsettings file. Go into VS Code's settings and search '.runsettings'. This should show the "Omnisharp: Test Run Setting" setting under the Extensions > C# configuration node.
I suggest clicking on the "Workspace" tab, so the setting is stored in your project instead of your user. That way, you can also check these settings into git.
Related
I'm writing some tests with xUnit in visual studio code.
Tests extract some sensitive data from Environment.
I'm storing those variables in .env file, in the workspace root folder.
If I load that file content in my shell and then issue dotnet test, tests runs correctly and use sensitive data extracted from environment.
In order to debug those tests, I'm setting envFile parameter in launch.json like this:
This usually works in a console application, but not when I debug a test through the VSCode Debug button:
The content of my .env file (in the workspace root, next to .csproj) is:
TEST_VAR=aaaa
Is this the expected behaviour?
Thanks.
Update:
In the end I changed approach. If you are interested in a different (and more powerful) solution, I described it in this article
I would like to create my own extension that would provide predefined configuration for debugger (launch.json) and a predefined set of tasks (tasks.json).
Right now I have vs code configured in those 2 files but there are lot of hardcodes in many places that will vary across different projects. So ideally I would like to have a plugin that eg reads one configuration file and applies all that stuff to "tasks.json" and "launch.json".
Wondering if that's even possible with vs code extensions API.
I think you can do this with variables defined in settings.json. You can define your own custom settings in settings.json (either user or workspace settings):
{
"editor.formatOnSave": false, // normal settings defined by the editor and plugins
"foo.bar": "baz" // custom setting
}
You can then reference this setting inside tasks.json or launch.json using string interpolation as "${config.foo.bar}".
I'm not sure where this is documented, but I found a reference to this in https://github.com/Microsoft/vscode/pull/11291
Update:
I've created a test repo at https://github.com/boyvinall/vscode-c-dbg. When I invoke the "run" task within tasks.json, I get the following output:
Using through launch.json with my current configuration doesn't seem to work with the "gdb" configuration, although the "cppdbg" configuration does seem to work ok:
NB, in case it's important, I'm running vscode v1.8.1
Visual Studio Code:1.15.1
settings.json (.vscode folder current dir)
{
"foo.bar": "baz" // custom setting
}
launch.json (example)
{
"program": "${workspaceRoot}/${config:foo.bar}.exe"
}
I was looking around found it. But it was out date and was trying to figure it out. Until the helper visual studio code hint gave me the information when mouse hover/over the strings.
"${config.foo.bar}"
does not work.
"${config:foo.bar}"
does work.
I am working on a ClickOnce application. I am trying to publish it from command line using this:
msbuild Project.csproj /t:Publish /p:configuration=release;
The problem is I want to set some other properties along with configuration, like 'PublishUrl' etc.
I've tried this:
msbuild Project.csproj /t:Publish /p:configuration=release;publishurl="\\sdmm\publish\"
It builds successfully but the output of that project will be copied to the debug folder of application in app.publish folder.
How should I handle this thing? Thanks.
You could set any property you want from the command line but before doing so, you need to open your .csproj file in some texteditor(notepad etc). Find the property that you want to edit. In your case it is publish url. Remove this property from csproj file.
Then you could do this
msbuild /target:clean,publish /p:publishurl=c:\publish_location\
you must clean the project before you publish it.
Try to change your target to
msbuild /target:clean,rebuild,publish
because property you are overriding (PublishUrl) was not embedded into application file if only "Publish" target is used.
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
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.