No Executable Found Matching Command “dotnet-projectmodel-server”

Are you getting the error as seen in the title when creating a new project in Visual Studio 2015?

The following error occured attempting to run the project model server process (1.0.0-rc4-004771).

Unable to start the process. No executable found matching command “dotnet-projectmodel-server”

And in image form :

Chances are this scenario has played out in the past day or so.

• You have previously used .net core tooling using project.json in Visual Studio 2015
• You installed the latest .net core tooling (RC4 or higher) that uses csproj files
• OR you installed Visual Studio 2017
• You are now using Visual Studio 2015 to create a new project

There are two ways to “fix” this.

The “I Don’t Really Care” Method

If the difference between .csproj and project.json tooling is beyond you and you really don’t care. Just use Visual Studio 2017 from now on to create .net core projects. Yes that seems very silly, but it is the much easier approach and for many it’s not going to make too much of a difference. You can still open existing project.json .net core projects in Visual Studio 2015 (Provided they have a global.json. see below), just not create new ones.

The “I Want To Actually Fix This” Method

So the reason this error occurs is that Visual Studio 2015 is not able to use the very latest .net core tooling (Currently RC4). When you create a new project *or* when you open an existing project without a global.json file specifying an older tooling version, .net core tries to use the latest tooling SDK installed on your machine.

I highly recommend reading this article on running two versions of the .net core tooling SDK side by side to get a better idea of how this works. It will allow you to fix these issues in the future. 

The fix to actually getting your project to open is by creating a global.json file in the root of your solution with the following contents.

{
	"sdk": {
		"version": "1.0.0-preview2-003131"
	}
}

Where the SDK version is your previous SDK version you were running. Again, if you are unsure about this please read this article on running two versions of the .net core SDK tooling. It’s actually super surprising how many issues can be resolved by knowing how the SDK versioning works.