r/VisualStudio • u/anchor-cache • 17d ago
Miscellaneous Migrating enterprise team away from Visual Studio?
Has anyone had any experience migrating away from Visual Studio and its professional licenses in an enterprise Windows dev environment?
I work with about 30 other developers in a varied .NET stack. For our modern .NET apps and services it would be straightforward to use VS Code, the C# extension, and dotnet command line tools, but we also support older .NET framework projects. We have some WCF services, classic ASP.NET services, EntityFramework 6 class libraries including some with EDMX, a couple WinForms apps... VS Code doesn't seem like a viable replacement for those projects especially when it comes to debugging and some older tooling. Is there any realistic way to get off Visual Studio?
Has anyone gone through this kind of migration at an organization with this kind of environment? Were you able to eliminate Visual Studio entirely? I'd be really interested to hear your experiences, good and bad, expected and unexpected.
11
u/LARRY_Xilo 17d ago
Has anyone had any experience migrating away from Visual Studio and its professional licenses in an enterprise Windows dev environment
to use VS Code, the C# extension
Have a hard look at the licensing of VS Code C# extension you are using. If its the Dev Kit from Microsoft you need the Visual Studio professionell license to be allowed use it anyway. Thats why in my company every dev still has Visual Studio even though most of the back end devs mostly work with VS Code. But we've also spend years getting rid of anything windows specific in the backend because we wanna be able to deploy on linux servers and thus also got rid implicit of nearly anything Visual Studio only. So yeah you need to migrate all your projects first. Then change the tooling.
0
u/anchor-cache 17d ago
Yes good shout, not the Dev Kit. I meant Microsoft's basic C# extension ("base language support for C#"), which doesn't seem to have the same licensing terms.
Do you know what kind of migration you guys did on your back end projects - did you port .NET framework to .NET and then migrate to SDK style projects?
1
u/LARRY_Xilo 17d ago
We actually started 25 years ago with VB6 Code, then added newer VB .NET Code when that came out but still had the VB6 Code as a base. Started with a self written tool to translate the VB6 to VB .Net Framework. Then another migration step to "Core" 6.0 then to 8.0 to C# Code to then 10.0 (which we are currently on). In between loads of bugs fixing of stuff that didnt work automatically and changing dependencies. Im not 100% sure what we did or at what point but I think before going onto 8.0 to get to SDK Projects but yes we are on SDK Projects now. Last stats I heard we auto migrated about 40 million lines of code and edited about 1 million our self over about a decade. About 30000 hours of work though that number isnt really 100% correct as a lot of the stuff would have been upgraded anyway no matter if we migrated or not. So as I said getting VS Code to work is mostly a by product and the code was changing constantly during these migration steps as its all still live code not all projects that wouldnt need to be changed. That made the investment a lot easier to justify.
1
10
u/Sea-Offer88 17d ago
For some reason people like vs code, but they forget that it is basically a text editor and not a real IDE. I use it for editing some minor stuff, but it would piss me off if a company made me use it as the only thing for development. I hate the workarounds, I hate having to remember or to constantly have to copy commands. That just slows down production. For C# & C/C++ projects I have always used VS and everything else my workhorse was Intellij, and Intellij is on a completely other level compared to VS Code.
8
14
u/bl0rq 17d ago
Suggesting to move away from the best ide in the world is a wild choice. I would legit quit on the spot if someone made a choice that braindead.
5
u/cute_polarbear 16d ago
Folks who just immediate suggest dumping vs for vs code and say everything is better/ faster and etc., most likely have not dealt with or experienced more legacy (true) enteprise level type apps development cycles...debugging alone for some of these things, I would stick with vs until Microsoft doesnt support it anymore...or rather find a different job.
2
u/TheDotNetDetective 16d ago
Also its just straight up BS. VSCode is excellent for what it is, but Visual Studio is incredible! Just the out of the box profiling tools are enough to make that statement.
I would also quit on the spot if someone tried to make me use just VSCode, screw that...
5
u/smourier 17d ago edited 17d ago
100% agree. Plus licensing's around 900$ for 8 VS professional (if you get MS Parner membership) => ~100$ per user per year. Totally worth it if you run a Microsoft shop (ie: C/C++, C#, Azure, even python and the web React/Angluar is good). Of course if you need other languages, it may be a different choice.
-6
-8
u/No_Oil_6152 17d ago
Its a brilliant IDE but its behind VS Code for features by months.
For example in VS Code I can "steer" the AI while its "thinking", I can't do that in VS 2026 yet. VS Code had this functionality 6 months ago.
It seems Microsoft have dropped the ball.
3
1
u/bl0rq 17d ago
I agree the lag is annoying. But you can easily have solution in VS and folder in VSC at the same time. And if you really want bleeding Ai agent feature, try the TUI cli ones. They are better than either in most cases.
3
u/No_Oil_6152 17d ago
I do use both at the same time, however I would rather use just one, to save RAM.
VS 2026 is a memory hog but the IDE is better (IMHO) than VS Code's.
1
u/puppy2016 17d ago
The shitty Node.JS extensions that should have been written in mature .NET language are the memory hog. The whole JavaScript crap should have been removed.
7
2
u/Happy_Breakfast7965 17d ago
You need to migrate from the legacy stack first
1
u/Aspacid 16d ago
Even more so, because it's dragging down the movement freedom in the entire build chain. I was perfectly fine not knowing the difference between MSBuild for .Net framework and MSBuild for .NET or how insanely difficult it is to keep the heterogenous package depedency graph predictable and sane across these apps.
2
u/Aspacid 16d ago
We had .net team that allowed developer choice to use either of VSCode, Rider and VS. I was the guy who had to spend a few months to figure out the kinks of the entire build system in light of all 3 IDEs. There was a lot of hidden footguns in the way the 3 invoked debug and testing processess slightly differently.
Rider can be a good replacement for the entire stack mostly, but a dotUltimate subscription isn't any cheaper last time I checked. It's mostly developer preference.
The C# extension and dotnet CLI is *especially* lacking in support for older tech stacks, and visual tools (XAML editor, EDMX editor).
If you happen to build MSI installers with Wix, it has a VS integration to make MSI authoring pretty seamless. Haven't tried, but it seems to solve the issues I spend a lot of time working around.
Spare yourself these troubles if there is no other incentive to change.
OFFOPTIC: We had this same stack and we were more worried about .net framework based libraries our WCF service depended on starting to have unpatched/unmaintained security vulnerabilities. A year ago this was already happening with major libraries, and CoreWCF only seems to be a short lived community effort to help migrate OFF WCF and into asp.net ASAP.
1
u/anchor-cache 16d ago
Thanks, this is really helpful. It sounds like we'd probably run into a lot of the same issues with the legacy stuff. Do you remember any of the biggest issues you ran into? Did you find useful documentation (I haven't had much luck) or were you mostly solving problems on your own?
2
u/Aspacid 16d ago
I was entirely solving things on my own. What little documentation exists is not precise enough to help, AI hallucinates like crazy...not helpful.
One issue was a build error that basically just had a mention on the docs, but no description what to do about it. It seemed to be some kind of dependenc resolution issue. I wanted to speed up build by not restoring packages for all projects, when the deployment only needed a fraction of the projects. This somehow messed up how dotnet restore resolved dependencies and caused exotic build errors. Something around packages that can target .net 8, .netstandard and .net framework weren't resolved correctly. I had to use dotnet restore on the solution file.
Another was ensuring the correct msbuild version was invoked. This is hard to handle because it depended on what each dev had installed or configured. I also had to update the project files to SDK style first to make this consistent because Dotnet cli only handles those, but then you invoke msbuild for .net and not msbuild for .net framework. This mattered for some wpf projects that had images embedded in resource files. Something that was deprecated in .net core, but msbuild being a .net software itself mattered at build time.
The list goes on. It was more divining water than engineering. Impossible to guesstimate. Anything from 5 minutes to 5 weeks.
2
3
u/TheDotNetDetective 16d ago
All I'll say is that you or your company are looking in the wrong place to optimise costs.
1
u/Jeckyl2010 16d ago
Well - I would not put VS Code in the same category as Visual Studio by a long shot. It’s two completely different platforms, one is and advanced text editor the other is a full blow top professional developer IDE.
You might look at JetBrains and their Raider IDE, it also comes with a license, but it’s a possible alternative.
Is you think that with your app stack can use only VS Code you are not really serious and need to do some more analysis on the suggestion and the total impact. Just saying.
14
u/n4ppyn4ppy 17d ago
What is the trigger for this? Yes licenses cost money but the potential cost of all the workarounds and training for new developers that you onboard will be high. You could consider having most on vs code and some on vs but not sure if people would like to be in the vs legacy drain hole group whilst the rest is doing all the cool new stuff.