DEV Community

Cover image for The Unnecessary Evil: How I Stopped Opening Visual Studio for .NET Framework 4.8
Heriberto Flores
Heriberto Flores

Posted on

The Unnecessary Evil: How I Stopped Opening Visual Studio for .NET Framework 4.8

Every developer has a necessary evil. Mine had a purple icon, a splash screen and 14 GB on my disk.

The relationship

I want to be fair to Visual Studio. It's a powerful IDE. It has helped millions of developers ship software. It has also, on more than one occasion, frozen while I typed a semicolon.

But I had no choice. I work on an old .NET Framework 4.8 codebase: classic non-SDK .csproj files, Web.config files the length of a novel, NHibernate, IIS Express. That kind of project doesn't do dotnet run. It needs Visual Studio the way an old car needs one specific mechanic who's the only person in town who still has the parts.

So every morning went like this:

  1. Open the solution.
  2. Get coffee while it loads.
  3. Come back. It's "Preparing solution…".
  4. Get a second coffee.
  5. Press F5. It builds the 37 projects I didn't touch and somehow skips the one I did.
  6. Clean. Rebuild. Restart Visual Studio. Restart the computer. Question my career.

Meanwhile, VS Code sat in the corner, opening in half a second, quietly judging me. I wrote everything else in it. I just couldn't run anything in it.

The necessary evil.

The breakup

Here's what I eventually realised: I didn't need Visual Studio. I needed four things it did for me.

  • Find MSBuild.
  • Build the projects in the right order.
  • Put the right config in place.
  • Start IIS Express on the right site and port.

None of those needs a 14 GB window. They are just steps. And steps can be written down.

So I wrote them down. One Markdown file in the repo, written for Claude Code (and for humans, which turned out to be a nice bonus). It walks through the whole thing in plain steps: check that the local config is there (and stop and ask if it isn't, never invent secrets), put it in place, build the projects in the right order, start IIS Express in the background, and poll a health endpoint until the API answers.

At the bottom there's a troubleshooting section with every scar I collected along the way. My favourite: Git Bash helpfully turning IIS Express's /config: switch into a file path, so it dies complaining that switches must start with /. It did. Thanks, Git Bash.

Now my morning goes like this:

Start the admin Web API locally.

Claude Code reads the doc, checks the config, builds, starts IIS Express, polls the health endpoint and tells me the port. When something breaks, it reads the log file the doc points to, instead of me scrolling through the Output window looking for the one red line among four thousand grey ones.

I edit in VS Code. I run through Claude Code. Visual Studio stays closed.

Full disclosure

Visual Studio is still installed. vswhere finds MSBuild inside it, and IIS Express still reads the applicationhost.config that Visual Studio generated once, long ago.

So we didn't really break up. We just stopped living together. It's in the garage, doing build work, and I don't have to look at the splash screen anymore.

The necessary evil became the unnecessary evil. It's still there. I just don't need to open it.

The lesson

Nobody gave me a better tool for this. The codebase is still .NET Framework 4.8, and it's not getting migrated this quarter, or the next. The tooling I was handed was "use Visual Studio, that's how it's done".

What changed is that I stopped accepting that as the end of the conversation. I spent an afternoon writing down what the IDE did for me, and that Markdown file now saves me (and my team) the pain every single day.

So here's my question for you: what are you going to do with the tooling you have? Improve it, or accept whatever you were given?

Your necessary evil might be more unnecessary than you think. Tell me in the comments which one you're still opening every morning.

Top comments (0)