The Problem:
ADFS2 requires that a RP Trust uses https. The RP trust being https://localhost:44310/PAWS/. With that said, I need to have IIS Express use SSL locally. So, when I configure my ASP.NET MVC4 project to use IIS Express.
When I check this in to TFS (source control) and another developer on the team gets latest. The project will not load for them.
Visual Studio 2012 will display the following error messages when opening the solution:
This is because IIS Express wont automatically read the project file and add the HTTPS binding to the site configuration.
This is the configuration that VS adds to IIS Express' applicationhost.config file
<site name="PAWS.Web-Site" id="2">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\Users\larsene\Documents\My Web Sites\PAWS.Web-Site14" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:44310:localhost" />
</bindings>
</site>
But I need it to have the binding protocol set to HTTPS like so:
<binding protocol="https" bindingInformation="*:44310:localhost" />
I can either manually enter that into the applicationhost.config. Or I can run the appcmd.exe like so to configure it.
"%ProgramFiles(x86)%\IIS Express\appcmd.exe" set site /site.name:PAWS.Web-Site /bindings:https/*:44310:localhost
But either of these 2 methods is not what I want. I don't want to have to explain to every developer that works on this project to have to manually edit their IIS Express settings before they can even load the project.
How to recreate the problem:
This is easily re-createable by first closing VS2012. Then deleting the config folder for IIS Express located in
%USERPROFILE%\Documents\IISExpress
and then open VS2012 and also open the solution to the MVC4 project that's configured to use IIS Express with https. Now, VS2012 will fail to load the project and complain about no secure bindings.
What am I doing wrong or how can I fix this so that people who get latest on my project will just be able to run it?
I have recently come across this same problem, and I've been able to determine why it's happening.
Visual Studio is using the Project Url setting to set the IIS Express http binding, and then it looks at the IISExpressSSLPort setting to set the https binding.
However, if you've changed the Project Url to an https address, that is when Visual Studio gets confused. For the purposes of IIS Express binding updating, it assumes that you've entered an http address for the Project Url and doesn't seem to be able to handle an https address being there.
This complicates things since changing the Project Url to an https address is the only way I've found to make Visual Studio start debugging the https url by default.
So, this seems to be a problem in how Visual Studio is handling the IIS Express binding updates. I'm not aware of a good workaround that allows both the automated binding updates and to start debugging with the https address loaded.
I can confirm that Visual Studio 2013 is free from this issue.
Upgrading from VS2012 to 2013 solved the problem for me.
This looks like it might be a bug in VS2012...
The only way I've been able to handle this is by hand editing the IISExpress configuration file: applicationhost.config, located under C:\Users\YOUR_USER_NAME\Documents\IISExpress\config. Then under 'sites' I modified the block for the specific application's website:
<site name="YourSite" id="1">
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="c:\..." />
</application>
<bindings>
<binding protocol="https" bindingInformation="*:YOUR_PORT_#:localhost" />
</bindings>
</site>
Change the 'binding protocol' to 'https' and make sure you start Visual Studio 2012 with Admin privileges, at least until the site is created/modified in IIS Express.
Hope this helps...
You need to set SSL Enabled to True in the project's properties list in order to have that binding show up automatically. (per Scott Hanselman)
Have you tried opening the project as an admin (run VS2012 as an administrator)?
Usually when you get the above errors (configuring web xxx for ASP.NET 4.5 failed...) and (creation of the virtual directory xxx failed) is because visual studio does not have enough privileges.
May not be your problem, but it doesn't hurt to try.
First of all, thank you for providing the steps to reproduce this on your local machine. Other team members were having this issue, but since I created the project, I did not experience it. This allowed me the opportunity to experiment with some different solutions.
What I have found works best in the current environment (no fix from MS) is to leave the project url as the http value, but change the start url to the https value. Most developers should be comfortable changing that in VS.
This works on new machines without requiring someone running a bat file to configure the https site. You do have two bindings in IIS Express (http and https), but other than that, it seems to work well enough.
Have you tried to manually configure the port in the .csproj file? Once you've configured it there, it should carry over to other workstations:
<IISExpressSSLPort>44310</IISExpressSSLPort>
Also, the project's user file can still cause issues even with the "Apply server settings to all users" option checked. I normally just delete the user file when I fix SSL issues with IIS Express, because it's much easier to just reconfigure my user settings after I've fixed my issue.
I have recently had a very similar issue and came across this post when trying to resolve.
One thing I have noticed is that IIS Express seems to get very distressed if more than one site is set up with a HTTPS binding in the applicationhost.config file.
In my case, I had 2 sites set up to use the same SSL binding to port 44300, changing the port number on one of the SSL bindings on one of the sites caused errors similar to the ones in the OP. I ended up having to remove one of the sites, which is not ideal.
After a little more digging, I tried toggling the 'Require SSL' property from true to false, and back to true. This triggered an update the applicationhost.config which created a new SSL binding with a new port number.
I got into this mess because I had copied an existing project and my config was trying to share ports between 2 sites.
I see two options:
Enable the Apply server setting to all users (store in project
file) option on the Web tab to move binding configuration into your
project file.
or
Add your project's user file to source control.
Either approach will allow users to get latest and run without issue.
I recently had a very similar problem with VS 2019 and IIS Epress. I tried to change the http to https so that I could use ADFS.
Ce site est inaccessible localhost n'autorise pas la connexion.
After a little more research, I tried to switch the 'Require SSL' property from true to false and back to true. This triggered an update to the applicationhost.config file (... . Vs \ ProjectName \ config \ applicationhost.config) that created a new SSL binding with a new port number for the https protocol. So, I modified all the links with the proposed new port (in the web property of the project, the config file and the ADFS config) and it works.
Conclusion, it is not necessary that the http port is the same as https same for the same site.
Related
I was trying to answer this question "How to host Office Add In with IIS" --> https://stackoverflow.com/a/70616170/5079799 and I did by installing IIS and configuring it to serve site.
It seemed to work fine then, switching between IIS and VS, but after perhaps a reboot or regardless, today, I can't seem to get VS to use its own webserver. It seems to be serving the files under IIS webroot C:\inetpub\wwwroot, not the files in the project as I can navigate to URLs in my webroot, but if I open IIS, it doesn't show running.
Any ideas?
Update:
I tried completely uninstalling IIS from Programs and Features, but VS (2017) still seems to serve the webroot vs the project files.
Shortly after, VS didn't seem to load anything, neither the project, or the webroot was available after running solution
It seems URL/Ports have been changed somehow in the settings under my vbprojec files
Well, I found some settings that VS seems to have changed on me and one setting I changed that messed everything up.
I had hard coded the --> ~remoteAppUrl/ to be localhost:port.
I did manage to get things to work, two times, but adjusting settings, but I couldn't reliably reproduce so I did a hard reset and tried adjusting the localhost:port to ~remoteAppUrl/ in the xml and it worked, using a different port then before. This is probably the best route to go as I had already created a "localhost" xml and a prod xml so I can leave the VS xml with ~remoteAppUrl/. I'm guessing VS noticed that IIS was using the port it had before, even though IIS was off, it decided to use a new port to avoid conflict?
Here is some settings I changed to get it to work:
In Web.vbproj
<IISExpressSSLPort>44342</IISExpressSSLPort>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>57161</DevelopmentServerPort>
<IISUrl>http://localhost:57161/</IISUrl>
Became:
<IISExpressSSLPort>44367</IISExpressSSLPort>
<AutoAssignPort>False</AutoAssignPort>
<DevelopmentServerPort>44367</DevelopmentServerPort>
<IISUrl>https://localhost:44367/</IISUrl>
In Web.vbproj.user:
<IISExpressSSLPort>44367</IISExpressSSLPort>
Also I noticed that my GUID had changed somewhere along the line, so make sure that all lines up.
I also changed the URL in the Web Properties.
Viewing the properties gave me some insight as well.
If I attempt to launch my .net core app I get this message. I realize there are many posts out there claiming to fix this but I have tried every method they suggest and none are working.
If I go into the project properties under debug and change the port, then it will connect 1 time. Then if I attempt to connect again, it will give me the same error again. I can then switch the port back to the original and it will load one time, then it will fail any time beyond that, until I switch it again. Anyone have any ideas or fixes they used?
Thanks!
I had this problem. There is a hidden folder in directory of project that name is '.vs'. Close the Visual Studio and delete this folder. The problem will be solved.
I installed core 2.0 and updated VS 2017 to 15.4.3 today, had the same error.
I ended up changing the application to run on a different port, it worked for me.
I have tried to delete the vs folder but did not work.
Hope it helps.
I know there is already an accepted answer to this question, but none of the solutions worked for me and my solution may help someone. I am using VS2017 with an ASP.NET Core 2.0 Razor Pages project.
The error just started appearing for no obvious reason, and I tried the solutions posted here.
I ran the web app from the command line using the dotnet run command to see if that would bring up any meaningful errors, and there was a warning about the URL not being correctly bound. I looked in my projects Properties\launchSettings.json file and noticed that the applicationUrl properties were different.
Change the values for applicationURL so they are the same
Close the project and close VS
Delete the hidden .vs folder (as mentioned in the accepted answer)
Start up VS as Admin
Your app should work fine.
I was having this issue with Visual Studio 2019 with a clean branch from master. Restarting the PC solved the problem.
My colleague said he is having the problem about 2 times a month and other tries for solutions did not work.
It could also just be that there are iisexpress.exe processes hanging around in task manager which were running on the same port.
I've just found a couple and killing them solved this problem for me without needing to delete any .vs folder or changing ports or anything like that.
I gave up, and chose to run the project as self hosted, instead of 'IIS Express' in the play/run drop-down box.
In my case, the problem was caused by the port for HTTP and HTTPS being the same:
The ports must be different:
In a solution if you have multiple projects using ASP.NET Core in Visual Studio 2017 and you are trying to use the same port number you will get this error. You must have unique port assignment in your solution.
Go here in your project: Properties/launchSettings.json open this file and edit the port numbers here. Note: This is where you change the SSL port (two places).
Reason: VS/IIS Express maintains bindings to all the ASP.NET Core projects in your solution that use IIS Express as the server. For example if you use Kestrel or some other server you will not have this problem. VS creates a new port for each app when it is created in the solution to ensure you do not have port conflicts.
If you are trying to use Azure AD registered applications reply ports and trying to "reuse" your app registration, you might think to simply change the "app's" port so that you don't have to register it in Azure; this will not work. If you are just testing apps and want to reuse a registration then you must make sure that the app you are currently working on is the ONLY one on the port - manually. If you need to test two or more apps then you must register them in Azure AD individually as you would in production.
What worked for me and it is really simple:
Right-click project
Properties
Debug
App URL: change port to 5000
Done, hope helps someone.
Changin https -> http in my applicationUrl solved this issue in my case.
I have solved this issue by
adding exclusion to file devenv.exe in windows defender (anti virus, Win10)
how to know this is the issue;
when you load project defender will notify in notification unauthorized changes blocked. if this is the issue just add the exception as above mentioned.
For me above solutions did not work
But changing the IIS Express Bitness to x64 worked
I encountered this issue. Running VS in admin mode solved this issue for me.
Go to properties - select debug tab - change the App URL - e.g. to http://localhost:57520/
Something else can be running on your port that interferes.
This worked for me!
For me with VS2019, faced this same issue on start running our project.
So right clicking on IIS Express icon in notification pane near by DateTime pane in our laptop/Desktop. It will show up all running application, at last can find Exit. Click Exit there and run your project should work. That worked for me, without closing VS19 project.
After playing with netsh configuration trying to make the server accessible from outside, I added a new iplisten entry. The IISExpress showed the error Unable to connect to web server 'IIS Express' which was fixed after deleting the iplisten entry using:
netsh http delete iplisten <ip-address>
You can view the current list of iplisten entries using
netsh http show iplisten
They require running an elevated (administrator) command prompt.
It seems like IISExpress has no error message in this a case.
If you're hard-coding a specific IP address (not localhost), check that it hasn't changed.
Tried all. didn't work above.
changing host in applicationhost.config fixed.
change localhost to 127.0.0.1
<binding protocol="http" bindingInformation="*:50740:127.0.0.1" />
<binding protocol="https" bindingInformation="*:44381:127.0.0.1" />
It works after I reenter username and password for the application pool's identity account
Setting "Enable SSL" to false in project properties\Debug section worked for me.
It may not completely direct your case, but I just had to restart my (windows) system. The diagnosis of #Turneye may very well be the reason and his solution might accomplish the same result.
I added the localhost option on the applicationhost.config file and run visual studio as administrator and it worked for me.
<binding protocol="http" bindingInformation="*:6873:localhost" />
<binding protocol="https" bindingInformation="*:44320:localhost" />
<binding protocol="http" bindingInformation="*:6873:192.168.137.1" />
Some times running visual studio as administrator solves this issue.
For me worked by changing the applicationUrl in launchsettings.json file to different port number and that url to be same for all places inside this file.
In my case (VS 2019), all I have to do is Rebuild the code before I re-run the app after each code modification.
P.S. I am coding server-side Blazor.
If you've used netsh http add urlacl url=http://localhost:<port>/ user=everyone to add a specific url acl using the problem port then you'll need to delete it with netsh http delete urlacl url=http://localhost:<port>/ user=everyone.
Another solution is to run Visual Studio as an administrator which allows it to override the urlacl.
I was facing the issue multiple times in VS2019, then I realized when I make small edits and restart the IIS Express this problem is more pronounced. Some of the discussion above about ports make me think since I was closing the app by just closing the browser. So I believe the port was not released and it failed the start next time around.
I started closing the debug by clicking the "Stop Debugging" button in the VS2019. The issue didn't occur again for me.
I solved this by restart my laptop.
Rebuilding the solution fixed this problem for me.
For those of you using .Net Core 3.x and still struggling, like myself, I finally after days of searching found a hint to the problem https://weblog.west-wind.com/posts/2020/Jan/14/ASPNET-Core-IIS-InProcess-Hosting-Issues-in-NET-Core-31.
In .NET Core 3.x InProcess hosting for IIS is the default. OutOfProcess hosting externally runs Kestrel.exe and has IIS proxying requests into the external Kestrel HTTP host. InProcess hosting uses a custom IIS Module that bootstraps a custom .NET Core host right into the IIS host process which provides better performance and a smaller footprint.
Changing to "Out of Process" (Right Click Project > Properties > Debug > Web Server Settings > Hosting Model), closing visual studio, deleting the hidden .vs folder (as described in previous comments), and then running IIS Express in VS finally worked. If you ever change it back to "In Process" for testing and it doesn't work, you'll have to delete the .vs folder again after you change it back and close the project.
If you're like me and that got you over one hurdle and into another....
My next issue was i was getting this error This webpage is not available (with error code "ERR_CONNECTION_RESET") when running a request to ping the server in powershell (Invoke-WebRequest -Uri:https://localhost:{port}/{endpoint}). This thread mentioning the error lead me to a thread that mentioned a missing iss express development cert, which mentions solving it by running ./IisExpressAdminCmd.exe setupsslUrl -url:https://localhost:{port}/ -UseSelfSigned in the IIS Express program files directory in an admin powershell terminal.
I'm also gonna post my first issue here when trying to run IIS Express from Visual Studio, which was Cannot find C:\Program Files\IIS Express\iisepxress.exe. IIS Express was for some reason installed not only in my Program Files (x86), but in my second drive (D:\Program Files (x86)). After realizing that there is just no way to change where Visual Studio is looking for IIS Express (even though it's also installed on the D drive), I uninstalled IIS Express (which is probably how my dev cert got removed), in RegEdit changed my Program Files directory back to the "C\Program Files" folder (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion > ProgramFilesDir key), and reinstalled IIS Express from Microsoft.
Finally, I can run my .Net Core API locally using IIS Express.
Good luck all!
Some history...
For some time now I've been using VS2010 with TFS developing a web site which I work on using multiple workspaces; for example, workspace DEV1 might have code for a partially implemented new feature, so I'll fire up a 2nd instance of VS2010 and open the same solution in workspace DEV2 to fix a bug.
Within the solution file, the port number is fixed so that if I open one instance in any workspace the URL for testing starts http://localhost:8251/Core/.... If I opened a 2nd copy, then VS2010 detected the first instance, checked out the solution file and assigned a random port number. Hence the URL might now start http://localhost:12345/Core/.... Obviously, the port number was unimportant most of the time, but it's convenient to have it fixed for testing.
All worked well under VS2010 using its 'internal' webserver (Cassini). I could open multiple instances of VS2010 using solutions in difference workspaces and there was never any 'cross activation' where opening a page in one instance accessed files from a different workspace.
...End of history.
We're now moving to VS2013 and the 'internal' webserver has been removed so IISExpress has to be used for testing. The question is how to configure it so that it works for multiple TFS workspaces where the port number may be dynamically assigned.
The first thing noticed is that the stored startup page "Default.aspx?param=..." doesn't work right and IISExpress under VS2013 then tries to open http://localhost:8251/Default.aspx... omitting the project name. So after an initial failure, I need to enter a new URL. Clearly, once we fully migrate to VS2013 from VS2010, I can change the startup page to "Core/Default.aspx..." and all should be well.
I've also been told that I can configure the file "IISExpress/applicationhost.config" in my Documents (?) folder to include the lines similar to...
<site name="Core" id="3">
<application path="/" applicationPool="Clr4ClassicAppPool">
<virtualDirectory path="/" physicalPath="C:\Working\DEV1\Core" />
</application>
<application path="/Core" applicationPool="Clr4ClassicAppPool">
<virtualDirectory path="/" physicalPath="C:\Working\DEV1\Core" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:8251:localhost" />
</bindings>
</site>
This seems to work for the first workspace, but it's not clear how to extend it for multiple workspaces, especially given that the port number will be dynamically assigned for the 2nd, 3rd, etc solutions. Simply duplicating the above for DEV2, DEV3, etc, suffixing the site name and changing the id as neeeded, seemed to work initially, but further investigation indicates that IISExpress actually uses the DEV1 workspace! I.e. it's using the first matching application. Do I have to name the sites individually by workspace? Do I have to hardcode the port number for each instance? How do |I then refer to each one? It all seems to me to be a complete mess after the simplicity of VS2010's handling of multiple workspaces!
In short, what I want is the be able to open one or more instances of VS2013 using multiple workspaces referencing the same solution and be able to run multiple copies of the application side-by-side, possibly using dynamically assigned port numbers, and know that each instance is using its own folders. If there's only one instance open, it should use the default port number, but it that's already in use, it should just assigned a random port, and not interfere with the other solution.
Additionally, while testing, it seems that something rewrites this file. Is this normal, since once I have a configuration which works, I don't want it altered! [Update: it seems I'm not the only one with this concern as others have asked about this here! However, there doesn't seem to be a solution given which works.]
It would be so much simpler if MS hadn't removed Cassini... :SIGH:
Update: Seems this was difficult in VS2012 as well as other have a similar problem!
Have you tried setting the configuration file using the command line parameter?
When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.
I have an issue that seems to be identical to this question. I am unable to add a service reference to any project in Visual Studio. I went so far as to format the entire computer, re-install Windows (Windows 7 Ultimate), and VS2010 Professional. Twice. This is a work computer that I inherited and I find it odd that, even after formatting the drive and reinstalling everything, I cannot add a service reference to any project on this computer.
I am 100% certain that .NET 3.5 is being targeted in my project's settings and even created an empty project to try it out. Same results. I am not sure what I am missing. I am pulling the original solution from TFS (nobody else has this problem) so it's not like I'm missing something in the solution.
Any thoughts?
Edit:
I just created another account (Admin as well) and I can add service references to projects under that account. Am I missing something? My original account has an apostrophe in it--would that mess things up?
Edit 2:
While this has been fixed, I am not happy with the fix-action. I will be opening up a bug with Microsoft later, but I am curious to understand what caused this in the first place and how to avoid it in the future.
Edit 3:
I opened a bug report with Microsoft (here).
Work Around:
My work around, as posted in my bug report, was to create a new Windows user account on the machine (making sure not to have an apostrophe in the name). For whatever reason, this new account is able to add service references but the original still cannot.
(If somebody can post a solution that allows the original account to be able to add service references, I will change that answer to the selected answer.)
Same thing happened to me. My original account has an apostrophe, so I created a second DevUser account which works fine.
I finally solved ,
I realize that Extention Manager can't reach Online Gallery.Beside I could add a service reference in my domain. In my case this was an internet connection problem.
I opened devenv.exe.config file and found the proxy it shows our tfs address,but I can't beleive that! How could it be? I commented it and everythings seems fine now.
here is the answer Cannot connect to any online resource
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<!--proxy bypassonlocal="True" proxyaddress="http://tfs.mycompany.com.tr:8080/tfs/productdevelopmentserverxxx"/-->
</defaultProxy>
<settings>
<ipv6 enabled="true"/>
<servicePointManager expect100Continue="false" />
</settings>
</system.net>
Also have a look at this
Be sure you are not in debug mode when you are trying to add the service reference!
This one caught me!