If this “cross-platform” workflow was smooth and without issues, I probably wouldn’t be writing this blog post. Alas, if you have ever run MES or Platform tests in Visual Studio, you know this isn’t the case. Permission errors, LBO errors, build errors, I’m sure you’ve encountered at least one of these.

Recently, I went on a quest to try and fix this issue. My goal was to have a seamless testing workflow. Ideally, I would select a test or a list of tests, press a button, and they would just run. If you just want to know what I did, and how you can do it too, skip to the “My Solution” section. However, if you’re interested in the whole process and not just the result, you should read the whole blog post. It’s 100% human-written by me. 😁

Visual Studio

In order to fix this problem, I first had to understand it.

Why did Visual Studio fail so much?

There’s no one answer, but there is an explanation for most of the issues. If you took an Operating Systems class in university, you already know that Windows and Linux use different instruction sets in their machine code.

For everyone else, the only thing you need to know is that, when a program is compiled, it’s converted to machine code. Computers don’t “speak” code in the way we write it, the compiler converts it to a simpler format that the CPU can understand and execute as binary instructions. Different operating systems, and even different CPU brands, use different instruction sets. Therefore, an executable compiled for Windows cannot run in Linux and vice-versa.

What does this mean for us? It means that, when we compile our tests, since we run the command in Linux, they are compiled for Linux, not Windows. It means that we need to compile them again on Windows (that’s why you need to build — sometimes with a clean or full rebuild — your Visual Studio solution when you open it).

This isn’t the only problem. The localenv WSL only has one user: root. When build files are generated, their owner is root. Sometimes, Windows may need to overwrite some of these build files when compiling the solution in Visual Studio. However, since they have a different owner from the current Windows user, you may get a permission error. Windows can’t overwrite files that it doesn’t own or have permission to write.

Okay, Visual Studio doesn’t seem to be the best option for our current workflow. Why don’t we use VS Code instead then?

Visual Studio Code (VS Code)

VS Code has native WSL support, which means that we can compile and run our tests without having to switch to a Windows program. This gets us very close to the ideal solution I mentioned earlier. Unfortunately, VS Code also has its fair share of issues.

If you have never used VS Code to run .NET tests, you’re not aware of its limitations, so I’ll briefly go over them.

First, VS Code is a text editor, not an IDE, so it needs extensions that implement a test explorer, a debugger, etc. Microsoft has an extension for this purpose — C# Dev Kit — but it lacks many of Visual Studio’s features. For example, you can’t use a .playlist file to filter tests. If you didn’t know, our cmf-product command can generate a .playlist file with the tests that are failing in the latest CD / Nightly environment. If you use VS Code to run tests, this is worthless.

Additionally, the native test search feature is very limited. You can’t search tests by class or project in the same way you can in Visual Studio. You can’t filter tests by their status (technically you can select an option to only display the failed or executed tests, but that’s it; there’s no way to only see passing tests, skipped tests, etc.).

This makes VS Code a possible replacement for Visual Studio, but a severely lacking one. However, its biggest weakness is also its biggest strength. Since features can just be implemented using extensions, why not create an extension to bridge the gap between VS Code and Visual Studio? That’s exactly what I did!

My Solution

Let me introduce you to .NET Testing+, a new VS Code extension that makes running .NET tests on Linux not just possible, but even easier and better than on Windows. I know this is a bold claim, but I think you will agree with me after trying it out. I’ve been using it for the past few weeks, and I haven’t opened Visual Studio since. All of my work is done in VS Code now.

If you just want to use it, you can install it from here, but as you’ve come this far on this blog post, I suggest you finish reading it first.

.NET Testing+ implements every feature that we need (and some that we didn’t even knew we needed) in order to run .NET tests using VS Code. Since everything runs in VS Code, this means that our workflow doesn’t need to leave WSL now. Everything lives and runs within our localenv.

First and foremost, .NET Testing+ lets you have more than one solution open at a time. Yes, you read that correctly. This means that you can run integration and E2E tests, MES and Platform tests, or tests from any other .NET project, all at the same time, without having to switch solutions or open new windows. Each solution uses its own .runsettings file, so that they can have their own configuration without interfering with each other.

You can also read and write .playlist files. If you have a custom filter applied to run specific tests and you want to share it with others, or just save it for later, put those tests in a .playlist file. You (or someone else) can then open it and see those exact tests.

Speaking of filters, you can also search through tests by class or project. .NET Testing+’s search bar allows you to write something like (Project:Dashboards & Class:UIPage) | Class:ActionBar, which would show only the tests from the Dashboards project that are defined in a class with UIPage in its name, or tests from any project, as long as their classes have ActionBar in their name. You even have toggles to show only the passing, failing, skipped or not run tests, as well as any combination of these attributes.

Two other features that are still a work in progress, but are already functional, are the “Override Runsettings” and “Export Screenshot” features.

Override runsettings lets you run tests with custom runsettings options, without having to modify the file. This allows for quick changes, like making multiple tests run in parallel, with minimal effort.

Export screenshot generates an image with the tests that have run in the current session. With this feature, you no longer have to mess with the explorer tab in order to make it big enough to take a screenshot, or take multiple screenshots because the list of tests is too big. Just press the button (with options to customize the screenshot) and you have an image ready to paste in the PR description.

These features may have some bugs, so if something is not working correctly, feel free to warn me, or fix it yourself. The code is open-source and can be viewed on the extension’s GitHub page.

To address the elephant in the room: yes, this project was developed mostly by GenAI — “vibe-coded”, as they say. Writing all of this code by hand would take a lot of time, more than I have to give, unfortunately, and since this extension is not an official CMF product, its existence is more valuable than the quality of its code. Every feature has been human-tested and validated, but there may be some kinks that haven’t been discovered yet.

So… problem solved, right? Kinda, but not really.

Now we can run tests on Linux, but just because they CAN run, it doesn’t mean that they SHOULD run.

Other Issues

We fixed the workflow, but the work itself hasn’t changed. The tests are still designed to run in Windows.

For most of them, this doesn’t really mean anything. However, some tests use Windows-specific features, most notably file share paths, carriage returns and backslashes.

For those of you who didn’t study this in university (or didn’t pay attention), here’s the gist of it:

• Paths in Windows work differently from Linux. Linux (and other Unix systems, for that matter, including MacOS) use forward slashes (/) to separate folder/directory names in file paths. Windows, on the other hand, can also use backslashes (\) in file paths. If a test contains a path with backslashes, it will only work on Windows.

• File shares, like \\files, in addition to this problem, have the additional obstacle that they must be mounted. In localenv, the files share is mounted in /src/files, which means that, if a test needs to access a file that’s available there, it needs a different path to access the file share.

• Carriage returns are a vestigial artifact from the typewriter days. If you have never used one (I haven’t 😅), all you need to know is that, when you finished writing a line, you couldn’t just switch to the line below it, you also had to return the carriage (the thing that holds the paper) back to the left of the typewriter, otherwise you would start writing at the end of the next line, instead of at the start. Windows systems still use the carriage return symbol (\r) when switching to a new line. If you’ve never seen it, that’s because your computer hides it automatically. It’s a control character, so it doesn’t need to be displayed. The problem with this is that Linux doesn’t use carriage returns when switching to a new line, computers don’t need them for this purpose, Windows just kept them for backwards compatibility. This means that text that spans multiple lines will use this character or not, depending on which OS you’re using.

I have already merged a PR that aims to fix these issues and make every test cross-platform. Some may have slipped by, so keep an eye out for them and, if you come across one, you can try to fix it yourself.

Conclusion

If you’re reading this sentence, thank you for putting up with me for this long, unless you just skipped to the conclusion…

The main point of this post was to share my extension and the reasons why I created it. I love Linux and the Free and Open-Source Software (FOSS) philosophy, and I hope that, moving forwards, we can rely less and less on Windows for our work.

If you have any ideas on how to improve .NET Testing+, I hope you’ll reach out to me or give a go at implementing it yourself.

Happy coding! 😊

About me

Hi, I’m Sofia (she/her)! I joined Critical Manufacturing in 2025 (and again in 2026 after a brief “sabbatical”). Currently I’m working as a Software Engineer in the MES White Squad.

You can visit my website to learn more about me and read more of what I’ve written.