I seem to start getting this message after working on a .NET Core 1.1 Web API project for several days. I do not know the *right* solution to the problem, (and if I do i’ll update this page accordingly), but for now, I have found a workaround.
(Edit 07/07/2017: I have a suspicion that my problem may have something to do with running Windows 10 inside of Parallels 12 on a Mac with Home Folders sharing turned on. This creates an interesting scenario where IISExpress configuration files get stored in the host filesystem. Every once in a while I find that accessing files in this fashion seems to fail? I will investigate as I can. Its only a flimsy hunch at this point.)
On my machine, dotnet.exe is located at C:\Program Files\dotnet\dotnet.exe. You may have to search around if your configuration is different.
You may want to try these things first, before you resort to my work-around:
- Deleting
project.lock.json
- Deleting the
.vs
folder - Repairing the .NET Core install
- Repairing the VS 2015 install (or 2017 as in my case)
- Uninstalling and reinstalling .NET Core/SDK/Tooling
- Rebooting
What I Do To Workaround the missing dotnet.exe problem
- If you’re building and running a debug version of your service on your local machine, find the file appsettings.Development.json and move it to the location where your service DLL gets built. (e.g. c:\mydevelopment\mysolution\myproject\bin\Debug\netcoreapp1.1).
- Rename appsettings.Development.json to appsettings.json (only in the copied location – leave the original alone).
- Open a command prompt. It does not need to be administrator.
- Change your directory to match where the service .DLL is being built (e.g. CD c:\mydevelopment\mysolution\myproject\bin\Debug\netcoreapp1.1)
- Manually run the dot net.exe on your .dll:
"C:\Program Files\dotnet\dotnet.exe" MyService.dll Hosting environment: Production Content root path: C:\mydevelopment\mysolution\myproject\bin\Debug\netcoreapp1.1 Now listening on: http://localhost:5000 Application started. Press Ctrl+C to shut down.
Debugging
For debugging, I had to resort to using “Attach to Process”. On the Attach to Process window, there is a check box to Show processes from all users. Using this approach, I was able to find the dot net.exe process that is running my debug build, and debugging seems to work normally after you attach to the appropriate process.
Comments?
Please comment if you’ve found a better solution!