.NET Core - MVC

Observations about .NET Core, MVC and converting YetaWF from ASP.NET MVC5 to .NET Core MVC. The new .NET Core has great new features. Getting there from an existing MVC 5 app is HARD!

Yay, Visual Studio 2017. NOT!


Warning: This is a negative writeup about web development with Visual Studio 2017 ... (some comments are PG+).

I actually have to (and try to) get work done. Visual Studio 2017 is a letdown in so many ways that I hate using it.

All of my comments apply to web development with Visual Studio 2017 and ASP.NET Core. I have no issues with C++ and C# Windows Forms (etc.) development. And mind you, I have been using VS2015, 13, 10 for similar web development, often the same type of solutions, and not had any of these issues.


Working on an ASP.NET Core web project with maybe 100 projects, it constantly goes off into "heavy thinking" mode, meaning it's hung for 10+ seconds. Just right-clicking on the Solution folder or Website folder to bring up the popup menu takes an eternity.

Often, just double-clicking on a file in Solution Explorer causes an unexplained delay of several seconds. And renaming a file... And moving a file...

And every once in a while it goes into "dotnet restore" mode and just makes me wait for no apparent reason.

Then there is this dumb, dumb Debug property page (Project > Properties). You can select a new profile all you want, it will always use the first one listed in your launchSettings.json file. If you give me a UI for settings that don't work, just skip wasting that development time and document the launchSettings.json settings.

While building a solution, the UI becomes unresponsive quite often, and long enough for a popup to appear that VS2017 may be hung. Building the same size project in VS2015 works just fine.


Then, one of my biggest gripes, I can no longer build and then test in IIS. They say the differences between IIS Express and IIS are minor so no need to debug under IIS. Especially since IIS does very little when hosting an ASP.NET Core app. Well, I call bullshit. First off, it is recommended to host your production app on IIS (on Windows anyway). In order to run on IIS, you have to "publish" your app through Visual Studio. Did you notice how the assemblies are now littering your site's root folder? That doesn't look like your dev environment. And it's just a mess. What was the objection to using a /bin folder???

When you deployed your first site to IIS, did it work right away? Yes, so much for being like IIS Express.

If the differences between IIS Express and IIS are minor, why not simply support IIS???

Have you tried using multiple domains for one web app? You CAN'T do it with the current tools. You have to manually "hack" .vs\config\applicationhost.config and add all the Urls. WTF!

Using SSL with Kestrel is a pain. At least IIS Express picks up the certs used with IIS.

I like to test my web apps with REAL domain names, not localhost:port. And SSL. So I want to use port 80 (of course) and 443. As I work on ASP.NET 4 apps and ASP.NET Core apps I now constantly have to stop IIS to run an ASP.NET Core app and then restart IIS when I switch back to ASP.NET 4. Just let me run everything under IIS. Problem solved.

Publish Thy App

So MVC Views are only precompiled when publishing your app. Hhmm. This used to be possible in a simple Release (or Debug) build.

And, the publish step is no longer optional, because it creates some magical refs folder. And it rewrites your web.config (I hate that). Even building your app actually rewrites your web.config. WTF! And the above mentioned assemblies littered throughout your root folder. These are all design choices that may have valid reasons but are highly disruptive.


There is a definitive improvement. Unfortunately, using "Manage Bower Packages..." is disappointing. The "Include Prerelease" check box doesn't work, some installed packages don't show an installed version, others say they can be upgraded, but really can't. Unusable, just edit the bower.json file.

.xproj and .csproj

Shortly before releasing VS 2017 the switch was made from .xproj project files back to .csproj files. That part probably required just a bit more testing than it received.

Wasn't I surprised to find that an (ASP.NET Core) assembly included as a reference didn't actually become available in the web app. Even the generated sol.deps.json showed no trace of it. Only when included as a project (with source) would it work. WTF!

Adding/removing references is slow AF. Just open the "Add References..." dialog on the "Dependencies" folder (appropriately mismatched name) of a web project and WAIT... I just did it while typing this sentence. And waited 30 seconds longer... Visual Studio says "(Not Responding)". A while later, I got the References dialog. I probably had to wait for a "dotnet restore" run behind the scenes. WTF.


I understand the MS devs are excited about their shiny new VS2017 and tooling, but the emperor has no clothes. For the rest of us who have to actually work with the tools in our existing projects, shiny new in this case means different, awkward and not quite ready.

Overall, Visual Studio 2017 feels like it was rushed out the door instead of adding final polish and thorough testing... While it works with trivial test projects, it fails miserably for larger projects.

Too bad. We'll just limp along with mediocre web app support until Update x.x. Sure, these issues will be fixed someday. And maybe waiting to use VS 2017 would be better. Unfortunately, this isn't possible when you need to work on ASP.NET Core MVC (released summer 2016). The joke there being that MVC is unusable without proper tools. And we've gone from .csproj to .xproj to new .csproj formats in a few months. In other words, Microsoft proclaims ASP.NET Core MVC is available - 9 months later, the tools are mediocre at best and I'm hesitant to risk a production site to the current conditions. (This doesn't even touch on the complaints I have about MVC itself).

No Comments

Be the first to add a comment!

Add New Comment

Complete this simple form to add a comment to this blog entry.