Visual Studio vs mIRC - John C. Kirk — LiveJournal
Mar. 25th, 2007
01:56 pm - Visual Studio vs mIRC
I'm doing some ASP.NET development in Visual Studio 2005 at the moment, and I've spent the last half hour beating my head against the wall because of an obscure error message:
ASP.NET Development Server failed to start listening on port 1651.
Only one usage of each socket address (protocol/network address/port) is normally permitted.
This happened whenever I tried to run the application, or use the ASP.NET Configuration utility. (The idea is that Visual Studio has its own webserver built in, so you don't need to have IIS or equivalent installed on your development machine.)
This was working fine last night, and the only thing I changed since then was the permissions on the folder that stored the source files. I saw that there was an unrecognised SID in the list, presumably left over from when I had to recreate my domain recently, so I removed that to tidy up a bit. Since things no longer worked, I suspected that it might have been important after all, so I (temporarily) gave the "Everyone" group full control over that folder. However, this didn't fix the problem, so I removed the Everyone permission.
Taking a different approach, I went to a command prompt and ran "netstat -a" to see whether anything else was using that port. Port 1651 wasn't listed there, although 1652-1654 were. I ran the command again as "netstat -a -b | more" to find out ownership info, and it turned out that mIRC was using those nearby ports. So, I closed mIRC down, and was able to run the ASP.NET apps without any trouble.
Curiously, I then restarted mIRC, and I can still run the ASP.NET apps. Running netstat again, I see that "WebDev.WebServer.EXE" is using port 1651 and "mirc.exe" is using port 2064. So, there's probably a random element to port assignment.
Anyway, I doubt this will interest many of my regular readers, but hopefully it will be useful for people doing Google searches in the future. Even if you aren't using the same applications as me, the basic principle should still be valid (e.g. if Apache is conflicting with iTunes).