C# Dev Kit – Now Generally Available
Today, we are thrilled to announce the general availability of C# Dev Kit, a Visual Studio Code extension that brings an improved editor-first C# development experience to Linux, macOS, and Windows.
A Community Effort – Thank You!
Since our initial preview in June, we have received both quantifiable data and invaluable community feedback that have shaped this product. Approximately 350 issues, primarily reported by our community, have been addressed. These enhancements range from quality improvements to scenario clarifications. Your active engagement has led to over 300 targeted improvements, rendering a more robust and reliable extension. This combined effort was crucial in our decision to transition from preview to general availability and to initiate official support for Visual Studio subscribers.
What is C# Dev Kit?
The C# Dev Kit leverages the core C# language services and delivers additional productivity value to developers. While these core productivity features are now generally available, additional experiences that support .NET MAUI and Unity are still in preview, leveraging the C# Dev Kit. These extensions continue to benefit from feedback and improving your development workflows for MAUI and Unity in VS Code.
What’s Next for C# Dev Kit
Today’s official launch is only the start as we will continue to listen to your feedback and work toward improved performance, reliability, and adding features to support your C# development in VS Code with updates to the extension on a monthly cadence. If you want to get the early bits, opt-in to the pre-release channel where we will insert fixes and previews of new features as they are developed.
Please share your feedback by reporting new issues via VS code or searching the existing enhancement and issues and give your ‘thumbs up’ or additional context to the issue to help us prioritize.
Learn More
If you would like to learn more about C# Dev Kit, you can catch some great sessions coming to Ignite and .NET Conf in November or explore our updated C# VS Code documentation and Get Started docs. Try out the new C# environment with C# Dev Kit today!
Light
Dark
21 comments
CONGRATS!
Can’t wait to see how our VS Code plugin integrates with it https://marketplace.visualstudio.com/items?itemName=unoplatform.vscode . Start the clock, we are on it 🙂
Dev Kit has stopped working for me. Tried to reinstall it without luck.
I don’t have a build of RC 2 installed. Just RC 1.
Starting Spawn .NET server... Starting Open a solution... Starting Open a solution with environment service... Starting Clear environment... Using preinstalled .NET runtime at "/usr/local/share/dotnet/dotnet" Using runtime installed in SDK. .NET server STDERR: Failed to load /usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib, 0x0001): tried: '/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib' (code signature in '/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib' (no such file), '/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib' (code signature in '/usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs) The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/host/fxr/8.0.0-rc.2.23418.14/libhostfxr.dylib failed - Installing .NET prerequisites might help resolve this problem. https://go.microsoft.com/fwlink/?linkid=2063366 .NET server exited with 130Marina, I am so sorry you are experiencing a problem working with C# Dev Kit. Can you please file an issue either through “Report Issue” in VS Code or through our GitHub repo so the team has information needed to investigate and resolve for you.
When you install an ad-hoc signed SDK to a MAC machine, MAC security layer will block it to be used by any signed application/process except a small sets added as development tool on the machine. For CDK, you need turn on a machine level setting on VS code, so it would run under a compatible mode to allow it to work with ad-hoc signed SDKs. It would change some behaviors, for example, always downloading a signed runtime instead of using the installed SDK to load some of its processes, so it would not run into security blocks. The compatible mode is therefor slower, and not necessary for majority users who install fully signed SDK only.
You can find the setting through vs code setting pages, and expand extension/C# Dev Kit/Working with test signed SDK.
You have to reload the workspace after changing the setting. (You also need ensure vs code is listed as development tool on the Mac through its security setting pages, if it is not yet there.)
Thank you, Lifeng. That solved my problem.
It never occurred to me that I had to enable something in the settings, plus do some stuff in Security settings.
I would have hoped that the extensions should perhaps have warned the user, or at least, give it a clear hint.
yes, we thought that would be a good idea too. But it was delayed due to other priority work. That security check also blocks the product code in various different places, based on scenarios, which made it more work to provide recommend when it happened.
Actually, there are more people using ad-hoc builds than I originally thought, certainly more than the inner SDK developer team, so providing a hint may be more valuable than first impression.
Can I use to debug catalyst app (without MAUI) on mac?
Hi Wendy. I broke out an old Raspberry PI 4, and installed VS Code and .NET 7 today for my kids to play with, which worked perfectly.
Unfortunately I got an error message that Dev Kit and the base C# plugin does not run on that version of ARM, even though I think it is 64 bit. It would be great if Microsoft can also get Dev Kit working on the PI 4 or even just the PI 5 about to come out.
Even though the processor is ARM64, by default the Raspberry Pi Imager will install the 32-bit OS, I’m still new to the whole Raspberry Pi thing though, so I could be wrong. But maybe try installing the 64bit OS?
Not trying to be a moron here, but what does it do? Does it let you write C# apps on Linux that run on Linux? Or does it run on Linux so you can write C# apps that will only run on Windows? Does it fully support Windows Forms on Linux yet?
C# already lets you write apps for almost any platform.
This is a vscode IDE extension that makes writing C# apps a little easier.
However vscode makes C# feel like a second class citizen vs older IDEs and I feel like this is only further putting a bad taste in peoples mouths when it comes to C#.
Its ok if its your only option.
Pros:
* Only free portable option now for Open-Source projects
* It exists
Cons:
* Building an IDE around HTLM/JS/TS was a huge mistake.
* Making users sign into MS accounts is a huge mistake.
* Most serious cross-platform dev is now going to be using Rider as VScode is a massive IDE regression from MonoDevelop.
* Long run this could actually do harm to C# as a language because it now feels like a alien to the IDE and a second class citizen.
* No way to open .sln files without opening folders first (again feels like C# is now a second class citizen)
* No NuGet management without using command line?
* No way to manage .csprojs in solution
* No way to unload .csprojs in solution
* No way to manage solution level build configs
* OmniSharp doesn’t load .csproj or .sln build configs for debuging
While its good this exists when everything else is going dry… I can’t but help think this is going to contribute to more negativity around C# as a lang.
VScode was never built to handle a lang like C# and it really shows IMO. The constant battle with .sln files relevancy needs to be further improved (or some equivalent needs to exist thats human readable idk). Also maybe vscode needs to let extensions have more control & allow adding file menu options among other things as well?
Yes, this is the kind of stuff that spoils the whole cross platform story for .NET.
Those of us that were raised in Visual Studio, now have to additionally buy a Rider’s license to get a similar experience outside Windows, regarding all available .NET development workflows.
And what does it say from .NET cross platform capabilities, when the major IDE like offerings rely on Java and JavaScript stacks instead of .NET.
Agreed. For some inexplicable reason, Microsoft seems to have decided that anything they build that needs to be cross-platform should be built as some embedded browser based trash. VS Code, Azure Data Studio, the new Outlook, the new Store app – all websites running in an embedded browser. The new Outlook is atrocious.
Why is MS even building MAUI when internally all new dev is being built as websites? Browsers are good for rendering content. Google drove this insane push to make everything a web-based app instead of native, because they have a vested interest in keeping you in the browser so they can track you better and serve you more ads. And then MS decided to copy Google and go all in on web apps, even for things that make no sense being a web app. It just reeks of laziness. Sure you save the effort of building natively for each platform, but congrats, you are now delivering a crappy product on each platform, including Windows. What’s the point of putting in all the effort to make .net cross-platform if MS feels that HTML is the future instead?
I don’t quite understand some of the criticism. VS Code won over Microsoft independent devs by storm and now is (to my knowledge) the most popular source code editor of all. Being cross platform its target audience was mostly web or script language devs who’d never use Visual Studio or .NET anyways. So coming from that background: Why not open up an improving path for them to code in C#/.NET?
Personally I like VS Code, it’s light weight, and I find myself typing “code .” more frequently. So I really like the things Microsoft is doing here and hope they keep up the good work.
And regarding the Electron or “why’s everything a web app?” topic:
Having a strong XAML background myself, watching WPF struggle and come to a halt for years, watching the MAUI chaos and harsh backlash in the comment section in each of the team’s posts, watching Javascript keep on skyrocketing … I just have no choice but to admit that I personally think that the HTML5/JS/CSS-UI-Stack has won and XAML has lost. If I like it or not is irrelevant.
Which cross platform .NET UI-Framework is/was Microsoft supposed to use in VS Code? MAUI is just in a really sad state. Electron was a rational choice back then, even more so since Blazor was just an experiment at that time. And why not make use of the fact that there’s a huge community out there familiar with HTML5/JS/CSS while XAML is quite exotic in comparison and – at least in my experience – never achieved to get the originally intended “Work on XAML can be split up between pure designers and coders” concept going? That’s why I think the Blazor Hybrid way is very promising: Embrace HTML5 in desktop apps, but combine it with the superior .NET/C# in contrast to the JS mess.
But hey, I happily jumped on the Silverlight WPF-Everywhere bandwaggon back in the day, so maybe I’m wrong and focus will soon “shift” again 🙂
MAUI which renders using the native UI systems of each platform is not a good way to do a cross platform UI (this idea was bound for failure).
The HTML agnostic rendering code which renders the same across all platforms is much simpler. This is also true for game-engine UI systems. Its far more productive and far less prone to the whims of platform differences.
AvaloniaUI did this correctly using Skia as well. This UI approach for a C# IDE is what should be used IMO.
Hi Andrew,
MAUI which renders using the native UI systems of each platform is not a good way to do a cross platform UI (this idea was bound for failure).
Yes, good point, I agree.
The HTML agnostic rendering code which renders the same across all platforms is much simpler. This is also true for game-engine UI systems. Its far more productive and far less prone to the whims of platform differences.
AvaloniaUI did this correctly using Skia as well. This UI approach for a C# IDE is what should be used IMO.
Avalonia is pretty much what WPF should have evolved into if Microsoft for some reason had not decided to put it on life support for so many years. I agree here as well that Avalonia’s approach is much better than losing yourself in platform specifics. Personally I have no problem with VS Code using the Web-Stack, it just works for me tbh.
* No NuGet management without using command line?
I’m spoiled by the VS Nuget Manager so I looked for a GUI and found this extension:
NuGet Package Manager GUI
Not the prettiest, but it works. Could this be an alternative for you?
*EDIT: Blockquote completely broke the mobile view for me so I quoted just by using em, hope that’s better.
“I’m spoiled by the VS Nuget Manager so I looked for a GUI and found this extension:”
— Nice find. Probably a good solution atm for this part.
How do you run tests and get code coverage results using VS code with this extension ?
I’ve pretty much made the transition to using Rider because the support for VS for Mac was horrible and I wasn’t shocked that they discontinued support for it. Basically MS want’s to say they are cross platform but they really only want you using Visual Studio on a PC and this extension is just a half hearted attempt to appease the people that don’t use Windows computers.
If you have a test project in your solution and it has been built, you can find our tests and run them in the Test Explorer Pane in VS Code. You can find more information about the test integration here: https://code.visualstudio.com/docs/csharp/testing.
We would love for you to provide feedback through the report issue for things that are missing from your C# Dev Kit experience so that we can improve it.
Can this be used in neovim?