I am working on bringing a working web application onto a new computer running Visual Studio 2022 version 17.4.2 and .NET Framework 4.7.2. When running on local IIS (version 10.0) host there is a "local host redirected you too many times" issue. It suggests clearing cookies which has been done with no effect.
The same code works on other machines with no issues. Is there anything in IIS set up/configuration or that may be missing from Visual Studio or other installations? Thanks in advance.
So far we have tried debugging the code and including breakpoints for where the issue may be occurring, ensuring that the installations of windows feature and IIS management is the same as another where the program is working. Also created a .txt file that can be reached on local host and is in same location as the rest of the project.
Here are a few things you can try:
Try on another machine.
Try to remove as much rules as possible from web.config and keys and so on. Or if it's a single page you're having the error with try to remove as much code from it especially if there are redirect codes. And add breakpoints and debug.
Check the LOCAL application pool version if it's set same as the online .net framework version.
I was witching and had my first few ASP.NET Razor Pages projects, debugging locally, publishing after, and everything went fine.
But now I temporarily took over a project from somebody with health issues, can not ask him things at the moment, maybe next month.
The projects run on two physical servers, five IIS-applications running, like API, Video-Handling, IndentityServer and a "WEB" for the user-interface. Endpoints defined in the "appsettings", I get it.
I changed some minor things at the User-Interface (WEB-Application), published it directly on the server and everything went fine. Pfff..
But... now I want to make some bigger changes and test them locally before publishing, but still using other unchanged IIS servers on the two servers, which do the "heavy-lifting". So I put some breakpoints like always, run "Debug" on Rider, express IIS server starts successfully, but I noticed the application redirects to the project on the remote server and then of course does not meet my breakpoints anymore, it is just running the old version on the server. Now I am missing something..., looked at several configuration files, how can I configure it, when it starts with the local IIS express server instead of the remote server? I want to stay on the local IIS express server, since I want to test the changes of course.
Hope I explained my issue well enough, did not know how to tell exactly.
Greetings to all!
I have a problem deploying a .net core application via FTP which is hosted on IIS.
The main DLLs (core application) that I want to update just wont upload, FTP just gives me a generic permission error message. I think the reason is because they are in use because then I stop the application pool, upload and restart it works just fine.
But this isn't really a solution, are there any other methods of publishing that will alleviate this problem?
Edit:
"open for write: failure"
Is the only error I'm getting. I can't find anything online and the only solution I have is restart the app pool.
I found an answer and I figured it should be here for future Googling.
The issue is as I first expected IIS proxies the request to kestrel and that means the process is in use as far as Windows is concerned. There are three solutions.
The Good Solution
Have two (or more) VMs on azure behind a load balancer. Have a script which turns off the sites one at a time, does what it needs to do and turns them back on. Do this right and no downtime!
Intermission
Before I talk about the other solutions a little explanation. I have not been working with .NET for a long time but apparently there was this thing you could do where you add a app_offline.htm and it will temporarily take down the site for you.
In the context of IIS and .Net Core it also releases the process, which is really useful as it solves my problem! Although I had to visit the web page first for it to take effect, unless I'm mistaken.
The Bad Solution
Use an automated script to rename _app_offline.htm to app_offline.htm. Do the upgrade and then revert that change. Takes your site down, kind of ugly but scripting is always better than...
The Ugly Solution
You only have access to FTP, no remote admin or proper deployment process because... reasons.
Upload an app_offline.htm, upload as little as possible and hope it doesn't break anything before deleting or renaming app_offline.htm.
Also you would have to perform any DB migrations by using EnableAutomaticMigrations = true because you have no server access or scripting methods.
Is it possible to debug (with VS 2008) a site at my host? I have no particular control of the server, I'm only allowed to upload my website files to the server. I can however upload .pdb files etc.
The reason for me wanting this is because the site works fine on my dev machine, but refuses to show even the first page when deployed on the server (404-error).
Maybe a long-shot, but in my experience the "works-on-my-machine-but-returns-404-on-the-server" problem is often a consequence of that the WebServer Extension "ASP.NET v2.0.50727" is prohibited.
As Ganesh R points out, it may sound like your application never gets startet.
As for the debugging part, I don't think you would be able to pull that off...
Debugging requires that certain debugging components are installed and enabled on the server. This is highly unlikely to be the case on any production hosting platform.
Contact your hosting provider - they will usually be quite willing to help you diagnose the problem you are encountering.
I've found that on some occasions I can edit the source while debugging. Are there any other advantages of using the Visual Studio built-in webserver instead of a virtual directory in IIS?
I'm using Windows XP on my development environment, and a local instance of IIS 5. I work on several projects, so I use multiple virtual directories to manage all the different sites.
Are there any disadvantages?
The built-in web server for Visual Studio is called Cassini and here are a few of its limitations...
It can host only one ASP.NET
application per port.
It does not support HTTPS.
It does not support authentication.
It responds only to localhost
requests.
It is slow startup compared to IIS
All the previous responses are great answers - here's one gottcha with Cassini that might require IIS on the destkop.
Cassini runs in the context of the developer, not as the IIS user (IUSR_, IWAM, or in WinXP x64, the w3wp process). This can be a bit painful if you've got a web site that is accessing external files or creating temp files. It is most evident when your developer is running as an Admin of their desktop.
When you move to the server IIS, something that you would have had access to in Cassini doesn't work the same. CACLing with the IIS_WPG usually is all it takes to fix, but if your developer is not thinking about this, they will quickly get quite frustrated with their deploy.
Cassini does not support virtual directories.
It looks like a third option is coming soon:
IIS Express.
Another disadvantage I've run into is on a Forms authenticated website using custom IPrincipal/IIdentity. Cassini will switch the AppDomains without warning (or notice).
Check this blog post for more.The headache on this made me drop Cassini and stick with IIS.
The Visual Studio web server is less forgiving about // in the path.
It will refuse to serve a link like
http://localhost:52632/main//images/logo.jpg where IIS will do.
That's pretty obscure, but it means we have a lot of fixing to do to get rid of all the // occurrences.
The built-in server works well for larger corporations that don't want to give developers any administrator access on their own machines to configure IIS.
There's a bug in the way the built-in server handles HTTPModules - there is a workaround, but I hate having to put in code that'll never be needed in production.
You need to have Visual Studio running to use it (under normal circumstances)
It only responds to localhost, so you can't give the link http://simon-laptop:37473/app1 to a friend to view your site over the network
Big disadvantage: it's harder to get fiddler working, because localhost traffic isn't sent through the proxy.
Using http://ipv4.fiddler:37473 is the best way to get Fiddler working with it.
You cant use virtual directories :(
Cassini also does not support ASP Classic pages. This is only an issue for legacy projects where old ASP Classic pages still exist (like our web application at work).
The built-in server means the developer doesn't have to know how to set up IIS to test their site.
You could argue this is a disadvantage, and that a Windows developer should know at least that much IIS. Or you could argue that a developer who isn't a system administrator shouldn't be messing around with the web server at all.
If you 'web reference' the URL for web services that are on the built-in webserver, the port might change. Unless you have set a "Specific port" mentioned in menu Project → Properties options page.
This is something I've gotten used to now. I always set a specific port. Now when sometimes the webserver crashes (I've had that happen), I simply change the port number, and all is well. I reckon restarting will also fix this.
If you do hobby work at home using XP Home, you can't install IIS locally.
When you use IIS in Vista or Windows 7 with UAC enabled, you must run Visual Studio with administrative rights. If you do this, you can't drag an drop from your shell to Visual Studio (even if you run an instance of explorer.exe as administrator).
For this reason I use Cassini for most projects.
FYI, Windows XP 64-bit comes with IIS 6.
This is an old thread started 2 years ago. I just stumbled upon UtilDev Cassini while googling. Looks promising to me. At least it has the ability to run multiple sites simultaneously. That feature is really useful for me, because I work on 2 different sites and have to continuously switch between them using IIS.
Here's a reason for a third way: although UWS Pro is probably closer to IIS than Cassini (although inspired by Cassini and is from the vendor of the UltiDev Cassini fork), its main purpose is to be redistributable along with ASP.NET applications.
Cassini is meant to be a lightweight test webserver. The idea is that a developer does not need to have IIS installed and configured to test his/her application.
Use IIS if you are familiar with it and you have it set up and your box can handle it. Cassini is not meant to be a replacement.
I often take the best of both worlds and create an application in IIS, and use the built-in web server for more efficient debugging.
The built-in server isn't as configurable, and it runs on an odd port, so if you're counting on specific behavior it can be troublesome.
Install IISAdmin, and you can setup separate sites in IIS 5, instead of using virtual directories.
The built-in webserver is a little less robust than IIS, but requires no setup so it is just a tradeoff.
You may not always want your development projects exposed on your IIS server (even your local IIS server) so the built-in server is good for that.
However, if your application is going to access resources outside of the norm for a web app then you may want to debug frequently in IIS so that your app will run with restricted permissions and you can see where the pain points will be.
One difference I've found is that the development server handles uploading files differently than IIS does. You can't trap the error if the file being uploaded is bigger than your Max_File_Size setting. The page just dies and returns a 500.
Another dis-advantage is that it sends every request through the gloabal asax file which includes all requests for images and stylesheets. This means if you have code in there which does things with the file names, such as a look up, then the auxillary files willget processed too.
Also via IIS, you don't have to worry about automatically remembering and setting a stupid port number in your localhost url. That's something funky directly relied upon with Cassini...big pain in the ass. Who wants to remember some abritrary port number. Just run the damn site in IIS..plain and simple.
We've also seen some issues with Visual Studio built-in server regarding some third-party controls which put their scripts in the \aspnet_client folder.
Since the folder isn't there when you're not running under IIS, the controls didn't work. It seems a lot simpler to always work with IIS and avoid strange problems.
If your project resides in the IIS directory you can still edit code. It just depends if it has been published or not.
You will run into so many issues on the Cassini vs. IIS when you are debugging certain permission based scenarios, like Kerberos and NTLM authentication as well as issues like server compression, etc. All in all, the Cassini is still okay to develop with, but make sure you do extensive testing when publishing to IIS.