Startup Project keeps reverting to IIS Express for debugging - asp.net

In my solution I basically have two projects, the one I'm coding on, and the startup project, Startup.csproj. I have Startup.csproj configured to use Local IIS for debugging, and I normally just attach to the worker process to debug.
However, at random intervals, the Startup.csproj defaults back to IIS Express for debugging. It does not show as a change in the Startup.csproj project file, and sometimes even still shows Local IIS but fails with a "Cannot list contents of directory" error.
I'm running VS 2017 v15.9.15. What could be causing this annoying little phenomenon?

I thought I am going crazy. I found the settings driving that behavior in the project file. I set the UseIISExpress to 'false' and the other one all the way at the end of the file project UseIIS to 'true' and when reloading still set to use IISExpress.
Turns out there's a <ProjectFile>.csproj.user that will overwrite default settings. Search for the UseIISExpress in this file and set it to false and Voila! problem solved.

Restart your IIS and try as above
and go to the root directory and delete .vs directory if exists.
or
In the Processes window (Debug -> Windows -> Processes), right-click on the name of the process you want to detach, and on the shortcut menu, click Detach Process.:

Another scenario may be that the port that IIS is using for your application is already being used by another running application. Try changing the port and see if it works for you.

Related

Windows Process Activation Service Error 2:The system cannot find the file specified

IIS on my development computer stopped working. I just installed the latest update to windows 10 (1803) and now when I try to start the "Windows Process Activation Service" I get an "Windows could not start the Windows Process Activation Service on Local computer. Error 2: The System cannot find the file specified" error. Things I have already tried:
Reinstalled IIS and Windows Process Activation Service, several times
I verified that I do have a "C:\inetpub\temp\appPools" folder
Not sure what to do next.
I have had this problem twice after a windows update. The issue seems to be, that windows adds an incorrect parameter to the WAS service startup parameters. I fixed the issue using the following steps:
Start regedit (just type it into start)
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters
Delete the NanoSetup variable. This variable is preventing WAS from starting
Start the WAS service using task manager or by typing "net start WAS" in Command Prompt
Start the W3SVC service the same way
You can now start your website in IIS again
I had the same problem and nothing in here was the solution for me for a long time. So i rolled back windows also. Today i found the solution working for me - Navigate to:
C:\Users\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys\
find these 3 Key-files...
d6d986f09a1ee04e24c949879fdb506c_*
76944fb33636aeddb9590521c2e8815a_*
6de9cb26d2b98c01ec4e9e8b34824aa2_*
... then in Security-Settings:
first, you have to set your User as OWNER
close Properties Dialog - and open again
Then in ACL set "full controll" for SYSTEM
After that: WPA can be started...
Hope this helps; see also thread here: https://social.technet.microsoft.com/Forums/en-US/315841e1-b8b2-4084-8224-580ef3d13420/upgrade-to-windows-10-1709-iis-fails?forum=win10itprosetup
I had this same problem after installing the Windows 10 1909 update and the nanosetup variable was NOT in the registry. I ended up doing a variation of Sascha's fix.
I took ownership and gave administrators full control of the MachineKeys folder in C:\ProgramData\Microsoft\Crypto\RSA. Then I removed the 3 files in Machinekeys that begin with:
d6d986f09a1ee04e24c949879fdb506c_*
76944fb33636aeddb9590521c2e8815a_*
6de9cb26d2b98c01ec4e9e8b34824aa2_*
The Windows Process Activation Service (WAS) started as expected.
It just has a simple solution, you don't need to reinstall Windows or removing updates, It worked for me so sharing it with all of you,
if you already using IIS and have site's configurations and files in C:\windows\system32\inetsrv\config and C:\inetpub\wwwroot, Back up all files from the folder C:\windows\system32\inetsrv\config and C:\inetpub\wwwroot, if you are installing ISS for the first time then you don't need to have a back up.
On Taskbar right-click on Start button select 'Run', type appwiz.cpl hit Enter.Click on 'Turn Windows features on or off'.
Uncheck 'Internet Information Services' and 'Windows Process Activation Service' click OK button.
After restarting Windows, Delete 'inetpub' folder on C: drive.
Open 'Turn Windows features on or off window' again.
Check 'Internet Information Services' and 'Windows Process Activation Service' click OK button.
After restarting Windows open folder C:\windows\system32\inetsrv\config.
Right click on the file named 'applicationHost' Select Open with Notepad.
In Notepad, Copy all the content of the file.
Select New in File Menu and Paste all the content in the new file.
Save this file in C:\windows\system32\inetsrv\config with the name 'applicationHost.config.tmp', Don't forget choosing 'All Files' in the 'Save as type' box.
Otherwise, file will be saved as applicationHost.config.tmp.txt which will not work.
Type 'Services.msc' in Run, Find 'Windows Process Activation Service' in Services window.
Watch running the service successfully without any errors after clicking on start.
I finally had to give up and rollback the windows build. To do this follow these steps:
Go to settings (Windows+I)
Click on "Update & Security"
On the left click on "Recovery"
Then under "Go back to the previous version of Windows 10" click "Get
started"
It rolled back to "1709" and now works fine.
If you find yourself installing an application on a drive other than C: and that application relies on IIS, the path for inetpub temporary files may be missing. Even if they are present on C:, this may just confuse you into thinking they are present and thus not the issue.
Create the following empty directory structure, replacing G: with the drive letter that your application is installed to, other than C:.
G:\inetpub\temp\apppools
Then, start WAS, from an administrator command prompt:
net start WAS
If this has to do with IIS, restart for good measure, from the same prompt:
IISRESET /restart
This solved my problem when installing a third party application.
I received the same error after update, but on Windows Server 2022 Standard 21h2.
Tried all steps without success.
In my case WU deleted all params in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters
so i took it from old ControlSet002:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters]
"AccessDeniedMessage"="Error: Access is Denied."
"InstallPath"=hex(2):25,00,77,00,69,00,6e,00,64,00,69,00,72,00,25,00,5c,00,73,\
00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,69,00,6e,00,65,00,74,00,\
73,00,72,00,76,00,00,00
"MajorVersion"=dword:0000000a
"MinorVersion"=dword:00000000
"ServiceDll"=hex(2):25,00,77,00,69,00,6e,00,64,00,69,00,72,00,25,00,5c,00,73,\
00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,69,00,6e,00,65,00,74,00,\
73,00,72,00,76,00,5c,00,69,00,69,00,73,00,77,00,33,00,61,00,64,00,6d,00,2e,\
00,64,00,6c,00,6c,00,00,00
"GenerateKeys"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS\Parameters\ListenerAdapters]

Problem with built assembly not matching source when debugging under IIS 7.5

I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.

Why won't my VS 2005 hit the break points?

I'm going crazy and wasting a lot of time. I am running in DEBUG, checked the web.config to ensure debug=true is there, checked the code to ensure I am reaching it, cleared all temp files and pdb's. The only thing that works is to continually kill the solution, create a new solution and add all the projects again. I shouldn't have to do this every day.
If you're using Windows Vista, try launching Visual Studio as an Administrator. Even if you're already running as an Administrator on the machine, still right-click on Visual Studio and select "Run as Administrator."
Right-click the solution node in solution explorer end select Properties. Check the configuration settings in there.
If you are attaching to a process sometimes this can be caused by symbols not being loaded. If you see the code skip over your breakpoint hover over the breakpoint it will tell you if symbols were not loaded. If that is the case Here are several potential solutions to your problem.
Clear out all files in C:\Windows\Microsoft.NET\Framework\v2.0.50727\ASP.Net temp files.
Ensure you deployed the *.pdb files to the bin folder of your application.
The web process has not loaded your assemblies at the time you attach your debugger. Reset the process and wait a little longer before attaching to the process to give the process a chance to load your dll's.
Actually your visual Studio is not attaching your project with process WebDev.WebServer.EXE
Do the following Steps:
click on Debug Menu
Click on Attach to process WebDev.WebServer.EXE
Now your Debugging is enabled.

Visual Studio Development Server using wrong port

Related to a previous issue that I thought was resolved and actually isn't...
My Visual Studio 2008 installation may be a bit messed up, I think.
When my ASP.NET project is set up to use VS Dev Server with a fixed port, I get the "Port in use" error described in the linked question.
When my project is set up to use a random (auto-assigned) port number, it works, but it launches the browser using a port number 3 less than the actual Dev Server port number (e.g. if the port number is 1903, the browser launches to http://localhost:1900/)
If I make changes to the project settings, they do not "take" until I save and restart Visual Studio.
Any ideas how to track this one down?
Thanks!
I had a similar problem which hit my 2 main machines at the same time. On investigating I found it to be related to the Eset personal security (guessing a recent update messed something up). To solve it I excluded VS2008 from the active browser filtering - this is in:
setup -> advanced firewall setup -> antivirus & anti spyware -> web access protection -> HTTP -> webbrowsers
Deselecting vsdev in here fixed the problem - interestingly enough disabling the firewall and antivirus / antispyware did not solve the issue, so it is worth looking for a similar setting if you are running different security software
First try to kill all "WebDev.WebServer.exe" processes.
In Solution Explorer, click the name of the application.
In the Properties pane, click the down-arrow beside Use dynamic ports and select False from the dropdown list.This will enable editing of the Port number property.
In the Properties pane, click the text box beside Port number and type in a port number.
Click outside of the Properties pane. This saves the property settings.
Hope this helps
I do absolutely agree with Macros' answer. Just want to share solution for Eset Nod32 v5
In ESET NOD32 v5 to allow Visual Studio to run Development or IIS Express server you must uncheck Visual Studio in Nod32 Advanced Setup => Web and Email => Protocol filtering => Web and email clients
Weird!
The port number is stored in the .sln file. So, I'd blow that away the solution file first, re-create it and see what happens. If that doesn't help, I'd then move onto the web.config file and blow that away and start again too.
I also encountered the same error message:
Unable to launch Visual Studio development server because port [xxxx] is in use.
However, I do not have ESET installed. Instead, I had recently installed GlassFish server on my machine and that was causing the problem. Therefore, in Windows Task Manager, I killed the process it runs under which is java.exe and it fixed the problem.
This also applies to Visual Studio 2010.
And there is more to it.
Symptoms:
A Web (Services) project is configured to run at a specific port, e.g. 10080.
After a while Visual Studio compains “Unable to launch the Visual Studio Development Server because port ’10080′ is in use”
The reason is still unclear. It might have something to do with the webdev server crashing.
Restarting the pc doesn't solve the problem.
Netstat doen’t show an entry for the port 10080
Manually startin WebDev.WebServer40.exe at port 10080 works fine.
Since I'd like to start from within Visual Studio, I moved to port 10081, then to 10082, and today to 10083. I’m running out of ports.
Solutions that did not work:
Restart Visual Studio
Tweaking Trendmicro security settings (couldn't access them)
Disabling Forticlient antivirus/firewall
Workaround that DOES work:
Configuring my project to manually start the server
Right click the project, choose properties
Click the tab "Web"
Pick for start action "Start external program" and point it to Webdev.Webserver40.EXE
(for me: C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\WebDev.WebServer40.EXE)
Command line arguments: /port:10080 /path:C:\Solution\Project
Working directory: C:\Solution\Project
Under servers check "Use Custom Web Server"
Do not check any debugger checkbox
Side effect: my project thinks break points are not getting hit. ("no symbols loaded"). Turns out they work like they should.
I hope anybody ever finds a definitive solution, but up until then this workaround does the trick for me.
To solve your problem, just restart your PC. I've had the same problem, I did the same thing.

Replicate IIS setup from one machine to another

Looked for an answer to this and didn't see it.
This is for IIS 6.0 / Windows Server 2003.
I'm working with an extremely large ASP/ASP.NET application and I'm trying to get my development environment to match my team members environment. This process is basically trial and error: get an error, go into IIS, make a change, hope the error is fixed. Ugh. I'm hoping to find a way to replicate a set of IIS directories and their configurations on one machine onto my machine.
I did find a script that will iterate through and give me a list of all virtual directories on a machine. It helped, but not a lot since I still have to go in and set up all those virtual directories (I think there are like 20 of them ballpark). The whole process is complicated by the fact that we're mixing ASP and ASP.NET applications in the same application which spans many solutions and projects. Getting the whole thing up and going seems like way too much work but I've never heard of a real solution to this.
Would Powershell be helpful here?
You should export and import IIS metabase.
These might help:
IIS Settings Replication
IIS Metabase Backup and Restore
Fortunately, in IIS7, ASP.NET config is integrated with IIS config so the job is done by copying Web.config.
Here's Microsofts' documentation for iiscnfg. iiscnfg documentation
When I ran it the first time, I got an error that said "This script does not work with WScript." If that happens to you:
1. Click OK.
2. At the "Would you like to register Cscript as your default host for VBscript?" click Yes.
3. At "Successfully registered Cscript" click OK.
4. Run the command again

Resources