Visual Studio 2022 WSL unit tests as root - c#

How do I run Visual Studio 2022 unit tests to WSL as root?
I have a testEnvironments.json file that is able to run unit tests to my WSL instance from Visual Studio 2022 on Windows 11. Unfortunately there seems to be no way to force these tests to run as sudo / root. I've already tried running Visual Studio as administrator.
I have verified the getuid returns a non-zero value.
I have a hard requirement of running my code as root on Linux.
{
"version": "1",
"environments":
[
{
"name": "Ubuntu",
"type": "wsl",
"wslDistribution": "Ubuntu"
}
]
}

Run from powershell:
ubuntu config --default-user root
If that does not work, try using the following code for the testEnvironments.json file:
{
"version": "1",
"environments":
[
{
"name": "Ubuntu",
"type": "wsl",
"wslDistribution": "Ubuntu",
"runAsRoot": "true"
}
]
}
If not, I suggest you refer to these two documents.1 2

Related

How can I use Godot 4.0 C# with dotnet run watch?

Godot 4.0 beta has shipped with C# support, and it reportedly works out of the box with hot-reload support in Visual Studio.
I would like to get this working on my Mac, which doesn't have Visual Studio. I took the launchSettings.json and put it in my Godot project in "Properties/launchSettings.json" with this content (taken from what Visual Studio autogenerated):
{
"profiles": {
"Development": {
"commandName": "Executable",
"executablePath": "/path/to/Godot_csharp_b1.app/Contents/MacOS/Godot",
"commandLineArgs": "--debug-server tcp://127.0.0.1:6666",
"workingDirectory": "/path/to/my/project",
"authenticationMode": "None",
"remoteDebugEnabled": false,
"remoteDebugMachine": ""
}
}
}
Now I try to do this:
dotnet watch run --launch-profile Development
However, it doesn't work. It gives this error:
The launch profile "Development" could not be applied.
The launch profile type 'Executable' is not supported.
Unable to run your project.
Ensure you have a runnable project type and ensure 'dotnet run' supports this project.
A runnable project should target a runnable TFM (for instance, net5.0) and have OutputType 'Exe'.
The current OutputType is 'Library'.
Is it possible to work around this? Any way to run Godot on MacOS with hot reloading would be acceptable for me - command line or anything else.
I'm on MacOS + M1 if that is important.
Edit: My original answer misunderstood the question, but I will leave it below as it may be helpful.
Regarding hot reloading, I am not sure Godot 4 is capable of playing nicely with dotnet watch as I haven't been able to find much on it. However, I was able to find this outstanding issue regarding hot reload in Godot 4 beta 3, but that's about it. It will likely be some time before Godot 4 reaches stable, so this may change rapidly over the coming weeks.
If you are trying to debug a Godot 4 C# project with Visual Studio Code, you can do so with the following launch.json configuration. Note that Visual Studio and Visual Studio Code are two entirely different IDE's. Just place the snippet below in a file at .vscode/launch.json in your Godot project:
{
"version": "0.2.0",
"configurations": [
// For these launch configurations to work, you need to setup a GODOT4
// environment variable. On mac or linux, this can be done by adding
// the following to your .zshrc, .bashrc, or .bash_profile file:
// export GODOT4="/Applications/Godot.app/Contents/MacOS/Godot"
{
"name": "Play",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${env:GODOT4}",
"args": [],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
},
}
}
Make sure you have a GODOT4 environment variable that points to your Godot4 executable.
You will also need to place the snippet below in your .vscode/tasks.json file, since the launch configuration above depends on it to make sure that dotnet build is run before debugging.
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "dotnet",
"type": "process",
"args": [
"build"
],
"problemMatcher": "$msCompile",
"presentation": {
"echo": true,
"reveal": "silent",
"focus": false,
"panel": "shared",
"showReuseMessage": true,
"clear": false
}
}
]
}
If you are looking for Godot 3 launch.json configurations, you can find those here.

Visual Studio Code attach to process for debugging .NET Framework

I have this idea to use Visual Studio Code as a debugger of a working .NET Framework application.
Let's assume that there is a running process that runs a full .NET Framework 64-bit application. I have all the PDBs. Would it be possible to attach to that process Visual Studio Code debugger and debug that process?
For now, I have tried, with C# extension from OmniSharp launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to process",
"type":"clr",
"request": "attach",
"processName": "process_name"
}]
}
but it ends with:
Unable to start debugging. Failed to attach to process: Unknown Error: 0x8013132e
Anyone mayby tried to achieve the same? Is this even possible? Maybe there is some other plugin that I have skipped?

How to set a .NET project as StartUp in VS Code?

I'm using VS Code with the vscode-solution-explorer to develop a .NET solution.
For debugging, I've configured my .vscode/launch.json file to run a build solution task and to execute a specific C# project (.csproj file).
My problem is: this .NET solution uses the Microservices approach, so I have ~50 Web API projects and each time I need to debug a specific API, I need to open the .vscode/launch.json file and replace the project name in 4 different places.
What I would like to do is the same that I do in Visual Studio: I right-click in the project and select "Set as StartUp project", so every time I press F5 it will run this selected project.
My launch.json looks likes this:
{
"version": "0.2.0",
"configurations": [
{
"name": "MyProject",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceFolder}/MyProject/bin/Debug/netcoreapp3.0/MyProject.dll",
"args": [],
"cwd": "${workspaceFolder}/MyProject.csproj",
}
]
}
You can create multiple configurations in launch.json file.
Check this post: How do I designate a startup project in VS Code?
Hope this helps.

Visual Studio Code .NET Core debugger not hitting a breakpoint

I have a problem trying to debug applications written in .NET Core in Visual Studio Code. Here is the setup:
I'm using a virtual machine running Debian 9 (with the default GUI). I've installed .Net Core SDK 2.1, and Visual Studio Code 1.30.0. Installed the extensions for C# 1.17.1. I've created simple project:
class MyProgram
{
static void Main(string[] args)
{
Console.WriteLine("Hello You Angel!");
ProcessStartInfo startInfo = new ProcessStartInfo() { FileName = "/bin/bash", Arguments = "-c nautilus /home/", };
Process proc = new Process() { StartInfo = startInfo, };
proc.Start();
}
}
If I run the program, in executes, and produces the correct output.
In the debug window I pressed the gear button to edit the launch.jason file
Here it is what it looks like:
{
"version": "0.2.1",
"configurations": [
{
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
// If you have changed target frameworks, make sure to update the program path.
"program": "${workspaceFolder}/HelloWorld/bin/Debug/netcoreapp2.1/HelloWorld.dll",
"args": [],
"cwd": "${workspaceFolder}/HelloWorld",
// For more information about the 'console' field, see https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md#console-terminal-window
"console": "integratedTerminal",
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart",
"externalConsole": false,
},
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command:pickProcess}"
}
,]
}
I've put a breakpoint in the project:
and when I hit the green triangle button, the breakpoint it not hit. Actually I think that non of the code i executed at all.
Is there something I'm missing to get this app it debugging mode?
Please help!
I was having the same issue on a different setup. Running windows 10 using VSCode and dotnet sdk 2.2.
I found a few answers browsing through gissues Here.
And This one I think fixed my problem
I also noticed to make sure I was selecting the correct "c:/projectdir/bin/debug/projectname.dll" when asked to attach the debugger to a process.
After that VSCode successfully hit my breakpoint.
I hope this helps.
1) In terminal go to your project and write
dotnet restore
dotnet clean
dotnet build
2) Check paths of "program" and "cwd" in your configurations (launch.json).
In case anyone hits this problem when they have 'converted' a Class Library project to a Console Application here are the symptoms and cause that I found:
I had mistakenly created a Class Library when I actually wanted a Console Application. I've made this same mistake in .NET Framework projects before and so thought I'll just convert it, no problem. So I altered the Output Type and gave it a Startup Object. The project ran but breakpoints were not hit.
It took me a while to find out why; it was because I'd created the original Class Library project as a .NET Standard project. When I created a new project (same code) as .NET Core (rather than .NET standard) the breakpoints were hit.
Quite interesting that you can actually switch a .NET standard Class Library project to Console Application, as it appears you can't create that setup through the UI.
I switched my project file from netcoreapp3.0 to netcoreapp2.2 and everything build fine but my breakpoints did not hit. After deleting the bin and obj directories, I got an error that the executable dll could not be found. Turned out I had to also change my launch.json file.
In .vscode/launch.json make sure to check your program folder and executable exists.

VS2015 Code Coverage not working with tests in ASP.NET Core 1.0 (formerly known as ASP.NET 5)

I have a an ASP.NET Core 1.0 (previously known as ASP.NET 5) solution with a couple of Class Library (Package)'s and an ASP.NET MVC6 project.
I have a test library using the new XUnit 2.0 which supports Core 1.0.
However, for some reason my code coverage is producing zero results when running it on all of my tests which are passing.
By default, ASP.NET Core 1.0 projects are built in-memory by the runtime and no artifacts are persisted to disk. So in the settings I enabled "Produce all outputs on build" for each project in the solution. Now when I build I see the pdb and dll files being output to the artifacts folder. I thought for sure code coverage would work after this, but still no results.
Maybe code coverage just simply doens't work with the new .NET Core 1.0. If anyone has some information on this that would be great.
I'm able to get code coverage with OpenCover 4.6.166 using this configuration :
project.json sample
{
"version": "1.0.0-*",
"dependencies": {
"<project under test>": "1.0.0-*",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"xunit": "2.2.0-beta2-build3300"
},
"frameworks": {
"net451": {
"dependencies": {
"Moq": "4.5.16"
}
},
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"moq.netcore": "4.4.0-beta8",
"System.Diagnostics.Process": "4.1.0",
"System.Diagnostics.TraceSource": "4.0.0"
},
"imports": [
"dnxcore50",
"portable-net451+win8"
]
}
},
"testRunner": "xunit"
}
I use the myget CI feed my NuGet.config :
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<!--<add key="aspnetmaster" value="https://www.myget.org/F/aspnetmaster/api/v3/index.json" />-->
<!--<add key="aspnetlatest" value="https://www.myget.org/F/aspnetvnext/api/v2" />-->
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
</packageSources>
</configuration>
Restore dependencies with --infer-runtimes option:
dotnet restore --infer-runtimes
Then use OpenCover with this command line :
OpenCover.exe -target:"C:\Program Files\dotnet\dotnet.exe" -targetargs:" test ""<your project path>\project.json"" -f net451 -xml ""test\ChatLe.Repository.Test\xunit-results.xml"" -nologo -parallel none" -output:"<your coverage .xml path>" -register:user -filter:"+[*]* -[xunit*]* -[*]*Migrations.*" -returntargetcode
Note the -f net451 switch is important, it says to dotnet to use the net451 framework. To cover netcoreapp1.0 use -f netcoreapp1.0.
In my console output, I can see those result :
I got a .NET Core project with working code coverage using xUnit 2.*, Appveyor, OpenCover and Coveralls, but it had to be extended to .NET Platform Standard. You can see the results on the relevant open source library here.
Some notable conclusions:
I couldn't find a way to get OpenCover to pay attention to 'portable' debugType *.pdb files. I had to use the legacy, Windows-only 'full' *.pdb format. This is done by setting 'debugType' to 'full' under 'buildOptions' in your project's 'project.json' file.
I had to run OpenCover on Windows, and it had to run via some version of the traditional .NET Framework. If you haven't yet, configure your non-test project to use .NET Platform Standard instead of .NET Core explicitly, like I did here. Then, in your test project, break apart your .NET Core and your traditional .NET Frameworks, like I did here. Assuming you use .NET Platform Standard 1.6, you would use net463 where I have net46.
Run OpenCover using the traditional .NET Framework via the dotnet test command line tool, not the xUnit console runner. You can see my code coverage generation (and submission) powershell script here. Where I specify net46, you would specify the version you used in your test project (presumably net463).
Here's the script pulled from source. You may or may not need to adjust the filter argument with respect to your dependencies.
nuget install OpenCover -Version 4.6.519 -OutputDirectory tools
nuget install coveralls.net -Version 0.7.0 -OutputDirectory tools
.\tools\OpenCover.4.6.519\tools\OpenCover.Console.exe -target:"C:\Program Files\dotnet\dotnet.exe" -targetargs:" test ""test\Invio.Extensions.DependencyInjection.Tests\project.json"" -f net46" -register:user -filter:"+[*]* -[xunit*]*" -returntargetcode -output:opencover_results.xml
.\tools\coveralls.net.0.7.0\tools\csmacnz.Coveralls.exe --opencover -i .\opencover_results.xml
Technically, this isn't testing .NET Core. This is testing the traditional .NET Framework's interpretation of an otherwise .NET Core project. However, if you do not do any conditional compilation based upon which framework you're using, the code coverage results will be identical.
A minor word of caution: if you look at the example repository, you'll see that I have a debugType of portable, not full, for my project.json file. That's because I am using Travis CI for Linux & Mac OS X builds, and that fails when you use full debugTypes. I got around this by setting mine programmatically via a powershell script running after my build on appveyor.
I've got it working XUnit.
Important things to note:
xunit.runner.json is where your xunit configurations go
Microsoft.CodeCoverage package is needed to run code coverage in visual studio
You will get all tests shown in the Test Runner Explorer. You can also analyze code coverage with the Visual Studio menu item. Only thing I haven't got working is code coverage highlighting: code coverage highlighting in .net core visual studio
This is my project.json
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"copyToOutput": {
"include": [ "xunit.runner.json" ]
}
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.1.1",
"xunit": "2.1.0",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"ClanService": { "target": "project" },
"Utilities": { "target": "project" },
"UnitTests.Configuration": { "target": "project" },
"Microsoft.CodeCoverage": "1.0.2"
},
"testRunner": "xunit",
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"imports": [
"dotnet5.4",
"portable-net451+win8"
]
}
}
}
I followed this blog and was able to get some results, with opencover, althought I don't think it's correct.
And I need to investigate why the wrong numbers, if you find/found a way to do it, please share.
http://dotnetthoughts.net/measuring-code-coverage-of-aspnet-core-applications-using-opencover/
There is a thread in the OpenCover GitHub repository about this topic. The trick to making it work is noted in a wiki post.
The trick (user supplied) is to use the --lib argument of dnx.exe e.g.
OpenCover.Console.exe -target:"C:\<path-to-dnx>\dnx-clr-win-x86.1.0.0-beta6\bin\dnx.exe"
"-targetargs:--lib c:\projects\<path-to-site>\website\bin\debug\dnx451 --lib
c:\projects\\common\bin\debug\dnx451 -p
c:\projects\\test\Website.Tests test"
-output:coverage.xml
-filter:+[Website]*

Categories

Resources