Subscribe via RSS

ASP.NET 4.5 has not been registered on the Web Server

As a .net Developer, I have Visual Studio installed and this (usually) includes its own little version of IIS Express. This is all configured out of the box on install and just works.

After upgrading to Windows 10, I started getting this error:

ASP.NET 4.5 has not been registered on the Web server. You need to manually configure your Web server for ASP.NET 4.5 in order for your site to run correctly.

The usual trick is to go to command prompt, find your .NET Framework directory (somewhere near C:\Windows\Microsoft.NET\Framework\v4.0.30319) and then run aspnet_regiis there.

Unfortunately, on Windows 10, this doesn't work. It'll respond with:

Microsoft (R) ASP.NET RegIIS version 4.0.30319.0
Administration utility to install and uninstall ASP.NET on the local machine.
Copyright (C) Microsoft Corporation.  All rights reserved.
Start installing ASP.NET (4.0.30319.0).
This option is not supported on this version of the operating system.  Administrators should instead install/uninstall ASP.NET 4.5 with IIS8 using the "Turn Windows Features On/Off" dialog,  the Server Manager management tool, or the dism.exe command line tool.  For more details please see
Finished installing ASP.NET (4.0.30319.0).

This all makes sense... you instead need to hit the start button, type "programs and features" into the search and then hit the first result that appears.

Once in the Programs and Features window, hit the "Turn Windows Features on or off" in the left pane.

Now scroll down through the tree and find:

  • Internet Information Services
    • World Wide Web Services
      • Application Development Features

...and then check all the relevant features you require. I chose .NET 3.5 and 4.6.

Let it do its work and then you should be back to happy-development-land in VS before you know it. If not, then it could actually be a bug in Visual Studio. Please check the following patches for your version of VS: VS2010, VS2012 or VS2013.

If you could only see .NET 4.6 (or have just updated to it...)

Then you need to patch Visual Studio as per the instructions here. Seems that upgrading to 4.6 won't let Visual Studio correctly see that 4.5 is installed.


net.tcp and IIS Express does not work

I've just spent time trying to rig up a test to get a working net.tcp server. Turns out that, in Visual Studio 2012 (and just about every other VS version), the IIS Express Server that one usually debugs through CANNOT support anything other than HTTPS and HTTP.

Q: Does IIS Express support non-HTTP protocols such as net.tcp or MSMQ?
A: No. IIS Express only supports HTTP and HTTPS as its protocol.

Please do not waste your time... When you hit debug on your net.tcp service, IIS Express will instantiate and you'll be thrown to your favourite web browser, staring at your root folder which is readable. You'll note that you'll also be on a port that has nothing to do with your web.config. This is because IIS Express has generated a random port and not cared one iota for your port configurations in web.config. You'll get nothing but connection refused when you try to connect to net.tcp://localhost:PORT/Service.

I was about to whinge that this tutorial on configuring a net.tcp service on IIS7 doesn't mention anything about incompatibilities with IIS Express. I suppose that one must assume by the header that the article is only for IIS7. A footnote would still be greatly appreciated for those trying to develop their code before deploying it!

If you ever want to get this to work, deploy and test your server on a real IIS instance and run from there... IIS7 preferably.

Note, if you need to debug... bring the server up, hit it with a simple query to make sure the app pool is active, and use Debug -> Attach to Process from Visual Studio. You'll find w3wp.exe way down the list with your Website's 'name' next to it. Highlight it and hit Attach to debug pesky server-side problems.

Once debugging in Visual Studio, you'll then need to open your source files (they can be in any folder, VS initially wont find them automatically) to set breakpoints. Note that exceptions will be caught in VS whilst debugging and will halt execution on IIS for all users. I have, once or twice, accidentally left the debugger attached overnight and had very angry clients in the morning with stalled connections.