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'm using Visual Studio 2010 and working on an ASP.NET 4.0 web application. At the moment, a co-worker and I are tweaking CSS, which means constantly changing and saving CSS files and then refreshing the running page in a web browser.
Every few saves, the application restarts, causing a considerable delay while we wait for the app to start up, log in again, and return to the page we were working on. In an IIS production environment a CSS file wouldn't go through the ASP.NET ISAPI, but apparently when running with VS2010 and the developent web server this doesn't matter... or something.
Is there any way to prevent this from happening? Thanks!
Instead of using the built in web server in Visual Studio (casinni), you can install IIS on your workstation and specify visual studio to use IIS as the development web server that runs your project. I do this for the same reasons. The Casinni server crashes or fails to start pretty regularly for me.
You could also use IIS7 Express. Not only will the server be faster but it will also be more like your production environment. This should help you iron out any issues before you deploy. Its also not hard to get VS to debug a local IIS instance.
After migrating my app to .NET 4 it's not starting. When i'm trying to load it in browser it endlessly loading it and nothing else happening. There is no errors or timeouts, just loading.
Please help. What should i do? What reasons there might be? I'm using IIS6 btw.
Did you register .NET 4 with IIS? Do you need to call aspnet_regiis.exe from the 4.0 directory?
Are you sure the app is using the correct Application Pool? Is the pool set to .NET 4? Is it integrated?
What does your web.config look like? Does the compilation node contain targetFramework="4.0"? Are you referencing 4.0 versions of the assemblies you need?
Unfortunately there is a ton of places to look into.
After some weird combination of IIS restarts, site stops and appPool recycles everything began to work fine.
We have an ASP.NET application running on a webfarm. When we release a new version and copy it to the production servers, occasionally it happens that after a few hours the application reverts to a an earlier code base.
Have anyone else experienced something like this? Would sharing an application pool between two applications running different versions of the code make this happen?
Additional information:
3 x web servers running w2k3/iis6
ASP.NET 3.5
I've had this happen rarely on non-precompiled sites and the solution was to stop IIS and clear out the temporary cache at:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Is not a long-term solution, but will address the immediate problem. If not already, it is worth considering deploying the site pre-compiled.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.