Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

.NET Core 2.0 and ASP.NET Core 2.0 are Here

continued from Page 2

The Dark Underbelly

So, I've talked about a lot of things that are improved and that make 2.0 a good place to jump into the fray for .NET Core and ASP.NET Core.

But it's not without its perils - there are still a lot of loose ends especially when it comes to tooling. Let's look at a few things that feel like they still need work.

SDK Projects and Cycle Time

The biggest issues I've had with development under .NET Core in general is the tooling.

While I love the fact that command line tooling is available to build, run and compile applications using the various dotnet commands, the performance of these tools is considerably slower than the old compilers in classic full framework .NET projects. I'm not sure where the slowness is exactly but the start/debug/stop/restart cycle is dreadfully slow with anything .NET core related.

When building Web applications with ASP.NET Core I tend to use dotnet watch run which uses additional build tooling to automatically recompile your applications when a change is made, and then automatically restarts the application.

When working on a SPA application I often end up making a change on the server, switching back to my browser to see the changes. Client side changes happen almost instantly, but the server side API code still takes between 20-30 seconds even for a small project which is very slow. This is especially frustrating when working on a client project where the client side content is live updated nearly instantly in the browser.

The slowdown appears to be in the build process, because if I run a published application like this:

dotnet albumviewer.dll

it fires up instantly in less than a couple of seconds which includes some db initialization.

However, running:

dotnet run

is achingly slow and takes upwards of 20+ seconds. Dotnet run builds the project again and that's seems to be where the issue is as .NET goes through re-packaging the application in order to run it.

The slowness of the cycle time to restart an application is a noticeable drag on productivity for me which makes me very wary of running the application or running tests for that matter, which have the same issues.


Another area that's problematic is tests which run considerably slower under SDK projects than in full framework projects. I'm also seeing test runs that just stop running randomly in the middle of the test run quite frequently.

As I mentioned earlier I moved a couple of projects from full framework to the new .NET SDK projects with multi-targeting in place, and I can compare performance side by side and the full framework tests run 3-4 times faster and reliably run through where the SDK project frequently stops mid-run.

Another problem with tests in particular is running multi-target tests when running inside of Visual Studio. It's never clear which target you are actually running, nor does the test output tell you.

To be fair if you run tests from the command line you can specify which framework target is used and you can easily specify which namespace, class or even method you want to test. In fact, in many cases I had to use the command line, because that was the only way I could get tests to run.

I find myself waiting on builds and application startups a lot more than I used to with full framework projects. In fact, I work with both, and whenever I switch back to a full framework project from a SDK based project I go "Damn that's so much better". That's not an experience I like to have with a new platform.

Slow Editing in Visual Studio

Another annoying issue is working with projects in Visual Studio. The tooling quite frequently goes out to lunch and finds errors that aren't errors, not letting the application run. I also frequently see the editor show perfectly valid code as invalid while a full compilation of the project shows no errors. The only workaround for this often is to close the solution and re-open it.

Visual Studio also often slows down drastically when working on .NET Core projects. In fact, a few minutes after opening a .NET Core project, the fans of my Mac Book Pro go into hyper drive mode and after an hour of this it's not unusual for my computer to actually throttle down due to heat. This does not happen on full framework projects, so there's something specific to .NET Core or SDK projects that cause this madness.

On a related note, I also use Resharper as a crutch I can't live without, and it too seems to have a lot of problems with validating code properly. Razor content especially seem to be a problem for both the raw Visual Studio editor and Resharper.

Just to be clear though I've also run extended periods without Resharper to make sure it's not R# that's causing issues. Resharper causes its own set of problems, but even 'raw' Visual Studio throws up the same issues.

You'd think using Command line tools and shelling out would be very efficient and if nothing else offload a lot of the workload external from Visual Studio, but currently that's not the case. The difference between classic and SDK projects is extremely noticeable and very productivity sapping.

The alternative is to use Visual Studio Code with OmniSharp and the C# addin, or JetBrains Rider which fare much better when it comes to editing performance and getting stuff done, but even then the external compile process, and running of tests is just dreadfully slow.

Rider especially looks very promising but there are still a number of issues related to .NET Core projects that are deal breakers for me at the moment. Testing in particular is a problem. I've tried out working both in VS Code and Rider for a while, but while I can some work done it seems like some processes are just too much of a pain. Rider actually comes close, but it probably needs a few more iterations before it becomes a viable choice for me.

So many choices, but none of them are really satisfying at the moment. All have some very strong things going for them, but every single one has also major drawbacks.

I am also hopeful that the tooling mess will sort itself out in time, but I think we as developers really need to make it clear to Microsoft that this is a big concern and not give them an easy pass. I know I can be overly critical at times, but I've heard this very same feedback from quite a few capable developers, so much so that many have just given up and just gone back to full framework where you get dependable tooling and tool performance. I think the tooling needs to be as first rate as the framework and there's a ways to go to achieve that goal.

Microsoft knows how to build great tools and I'm sure it's technically feasible, but the Achilles heel for the tooling has always been getting the final polish right. Right now we could use a massive shoe shine, (Achilles) heel cleaning kit 😃

Summer of 2.0

I don't want to end on this downer note, so let me make clear that I think overall the entire 2.0 train of upgrades is a huge improvement over what came before and the progress of change has been pretty rapid and amazing. The new features and improvements in the framework finally provide enough of a surface to make it realistic to jump in and build applications with .NET Core 2.0 and ASP.NET Core 2.0.

Another thing that I find extremely promising is that Scott Hunter recently mentioned that .NET Core 2.0 and .NET Standard 2.0 will stay put for a while, without major breaking changes moving forward. I think this is a great call - I think we all need a breather instead of chasing the next pie in the sky. Some time to try to catch up to the platform, figure out best practices and also see what things still need improving.

It's been a rough ride getting to 2.0 and I for one would appreciate a little stretch smooth road.

Figure 8 - Smooth road - for maybe a little while

Go ahead and Jump

I have been very hesitant to jump in with pre 2.0 versions, but with the release of 2.0 I've decided the time has come to build apps with this platform. My first work has been around libraries which has been a great learning experience, and the experience has been a good one. In fact the benefits of the new project system and multi-targeting has been a big improvement over older versions.

The support for pre-installed runtimes makes it much easier to manage deployment of Web applications, and proper multi-target support in the project system is a big bonus for library developers.

I'm in the middle of upgrading a couple of really old internal ASP.NET applications to .NET Core 2.0 and so far the process has been relatively smooth. Yes I struggle with the slow tooling quite a bit, but as annoying as that can be it's workable. And I am confident that Microsoft (and perhaps also JetBrains for both R# and Rider) can work out the kinks on that end as the tooling becomes more mature. I do hope they hurry though.

So what about you? Are you ready to give .NET Core and ASP.NET Core 2.0 a spin if you've been sitting on the fence like me? Sound off in the comments with your experience.


this post created and published with Markdown Monster.

The Voices of Reason


October 24, 2017

# re: .NET Core 2.0 and ASP.NET 2.0 Core are Here

Thank you for the very nice post.

I am still considering should I start with .NET CORE and you provided just what I needed.

Matt Warren
October 24, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Dotnet run builds the project again and that's seems to be where the issue is as .NET goes through re-packaging the application in order to run it.

Scott Hanselman wrote up a post on this, see SpeedOfDotnetRunVsTheSpeedOfDotnetForPublishedAppsPlusSelfcontainedNETCoreApps, it might have some tips/pointers on how to speed it up

October 24, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Re: build slowness

If you change your build output logging to verbose it shows the reason why it's building each project.

I found I had some resources that were set to Copy Always which meant the build would always be triggered regardless if anything had changed. Changing them to Copy If Newer meant the build was no longer being executed if nothing had changed 😃

October 24, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

One of the nicest features of 2.0 (actually introduced in 1.6) is the new SDK style .csproj Project format.

Actually, it was introduced in .Net Core SDK 1.0. (It's why .Net Core SDK was in preview for a while even after .Net Core 1.0 was released.) No .Net Core-related product I know of ever had a 1.6 version (except for .Net Standard, but that's not really a product).

October 24, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Nice article. Covering ASP Pages is something I've heard about, but now I'm going to rewrite a small web app in ASP Pages, instead of having lots of Controllers that all they do is return one or two views.

Chuck Conway
October 25, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Thanks for the summary of .Net Core 2.0. I have also used .Net Core for a new project. I find the slowness you've talked about maddening. I've tried both Jetbrains Rider on a Mac and a Windows, with similar results. I encounter the slowness on initial startup and while building. My hunch is it's related to Nugut. There is an option to turn Nuget off. I haven't tried this option to see if it is truly the case. In Rider (the latest version, 2017.2.x), I've encountered an issue where the project types of netcoreapp2.0 vs netstandard2.0's versions are switched. So .netstandard is on version 2.0.1, and netcoreapp2.0 is still on 2.0.0, but for some reason Rider switches the versions. Both Visual Studio and Rider grind to a halt. Taking forever to finally display a message along the lines of "Unable to find version 2.0.1 for netcoreapp2". Like you mentioned, I hope they get the tooling dialed in soon. It's a major pain point in working with .Net Core 2.0.

October 26, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Excellent writeup, Rick. I've been hesitant to work in .NET Core for my games and side projects for all the same reasons you have mentioned. We've been using it where I work, but it felt forced -- way premature and we were constantly spinning our wheels with issues when they changed directions unexpectedly. I was put on forking a 4.6 project and hooking it up to the "new stuff" in the Core world. When I tried to pull in anything from the new world targetting the 1.6< Standard, it tried to pull in pretty much everything from .NET Core. Luckily 4.7.1 was just released and once we updated our Standard stuff to 2.0 (last week), everything clicked (really, like night and day). It's beautiful. I can reference their stuff without pulling down dozens of .NET Core/Standard dependencies. I am starting to feel the same confidence in .NET Core that I started to feel in .NET 2.0 when we got (among other things) proper generics. It's maturing before our eyes and becoming truly attractive as a platform to build professional-grade products and services on. Looking forward to the future!

Alexander Batishchev
October 29, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

My (and many's) rule of thumb: wait for version 3.0 of any Microsoft product. Even I work for Microsoft myself, still.

October 31, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Thanks for the detailed post, Rick. You've given me the confidence to start looking at migrating some projects to .NET Core.

Freak Power
December 11, 2017

# re: .NET Core 2.0 and ASP.NET Core 2.0 are Here

Microsoft lost me with all this. .NET is a mess right now, and .NET Core makes no sense at all because MS. didn't clearly explain what is really for.


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2018