I'm using a windows 2012 cloud server and running multiple websites on IIS, including a Wordpress site. I'm attempting to set up another Wordpress site and have set everything just like the previous Wordpress site, but it isn't working. When I browse to http://localhost/folder/default.aspx, it browses successfully (I think it's using the default port of 80 correctly)...the default.aspx was my test "hello world" page. But when I browse to the Wordpress start page, index.php, the url is forwarded from "http://localhost/folder/default.aspx" to "http://localhost:50822/folder/index.php" and it fails I get the error "localhost refused to connect". I recently created a completely different project within Visual Studio, an ASP.NET Web Core project and I suspect that that somehow altered something on my server, but am not sure. I did finally notice that the port being used in the VS project was 50822. So I stopped the IIS server to release 80, changed the VS project to use 80, ran the project once or twice to build the project, shutdown the project, and restarted the IIS server. But the result is the same. Any ideas?
Per the suggestion, I've included the relevant portion of the applicationhost.config below:
<listenerAdapters>
<add name="http" />
</listenerAdapters>
<sites>
<site name="WebSite1" id="1" serverAutoStart="true">
<application path="/">
<virtualDirectory path="/" physicalPath="%IIS_SITES_HOME%\WebSite1" />
</application>
<bindings>
<binding protocol="http" bindingInformation=":8080:localhost" />
</bindings>
</site>
<siteDefaults>
<!-- To enable logging, please change the below attribute "enabled" to "true" -->
<logFile logFormat="W3C" directory="%AppData%\Microsoft\IISExpressLogs" enabled="false"/>
<traceFailedRequestsLogging directory="%AppData%\Microsoft" enabled="false" maxLogFileSizeKB="1024" />
</siteDefaults>
<applicationDefaults applicationPool="Clr4IntegratedAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
Found the problem: the prior project, done in VS ASP.NET Core, stored the 50822 port in the WordPress database. So, despite changing the project properties, or even removing the project, every subsequent WP project which logged into the database was affected. The solution was to drop the database schema and recreate it.