I am having problems accesing the session after upgrading a web project to .net 4.5
firstly, I had a functional .net 3.5 web forms project which I upgraded to .net 4.5 on my dev machine. This compiled and worked well locally
Secondly I modified the application pools on my dev iis server to use .net 4.0 in preparation for running the new code deployment
Finally I deployed my upgraded project to the dev web server.
The problem is that I am getting an error straight away where I am being told I need to enable session state to access the session variables.
Background:
I have a master page which checks for the existance of a session variable. I have put this code in the page_init event of the master page to ensure it runs before the page_load of the content pages etc.
This technique worked fine under .net 3.5 and works well under 4.5 on the local dev machine. But does not work on the iis server.
I have followed various threads telling me to set enablesessionstate=true in the config all to no avail.
Could it be that there is either a problem with .net sites runnning .net 4.5 on iis with regards to sessions, or am I missing something more obvious.
Please help as this is very frustrating
Well, I have no idea what was causing this?
I have fixed the problem by creating a brand new .net 4.5 project and importing assets / pages from my preexisting site.
Remarkably doing it this way caused no issue with the session after deployment to the web server, Very odd indeed. I can only assume that the project upgrade process that I initially used left some odd configuration in place which upset the server ???
Anyhow, have invested enough time in this now, thanks for taking the time to comment.
Related
I used to develop my web-apps using ASP.NET 4.x and host them in full IIS already during development, because:
1) I use multi-tenancy (site1.me.local and site2.me.local point to my app) and IIS express can't handle that AFAIK
2) Most of the times I do not need a debugger -> I just (re)build my app and refresh the browser - restarting IIS Express and the VS debugger wastes some time
Now I tried my first web-app using ASP.NET 5 aka Core 1.0 and I wasn't able to get it to run in full IIS to continue using my known workflow. I found out I can start IIS Express without debugging and just rebuild to solve #2, but #1 is still open.
Is full IIS even supported for ASP.NET 5 / Core 1.0 during development? If so is there some documentation on how to set that up around?
All documentation for full IIS I found is for publishing, but not for development.
You may actually not event want to use IIS in development with Asp.Net Core. Asp.Net Core has been separated from IIS and even in production IIS will only act as a reverse proxy passing requests to your AspNet.Core application. Asp.Net Core uses Kestrel as an application server and it is much easier to use just this during development. To get a similar workflow you had before you would use dnx watch/dotnet watch during development which will watch code files of your application and if any of the files changes it will stop the application, rebuild the project and restart the application. This is when you can refresh the browser to see changes (note that this is even one less step that you had before where you had to rebuild the application yourself).
It still should be possible to use IIS for development if you really need it but if you don't have a specific scenario that requires IIS I don't think IIS for development will give you any benefits.
The integration mode with full IIS has been changed several times (from Beta to RC1 and now to RC2), which messes up the documentation,
https://github.com/aspnet/Announcements/issues/164
You probably need to wait till RC2 is available to see the latest official steps.
I have a web application which has been having a strange issue ever since I moved it to a new server. Users will be able to use the application for some time, but after a few page requests, they will be redirected to the default page and asked to log in again. For some reason, this issue occurs less and less the more the application is used. The issue then starts occurring again over night. The application was formerly running on a windows 2003 server and it worked fine there, so I believe the issue has something to do with the settings on the new server.
I am currently running the application on a windows 2008 server with IIS 7.
I looked through a bunch of different settings in IIS and changed many different things, but none of them seemed to solve the problem. But today, I tried changing the application pool to run under a v4.0 .NET Framework, and that seemed to solve the problem. The application pool formerly ran under a v2.0 .NET Framework.
I do not understand how changing the framework solved my problem. I do not see any connection between the .NET Framework version and my application redirecting to the default page.
Can anybody explain how / why this change in settings solved my issue? Any insight or help would be greatly appreciated.
Thank you
Back in October we upgraded one of our sites (on IIS 6) from .net 3.5 to .net 4.0. Since then we have been getting the following warning and error pretty much everyday:
Warning:
ISAPI
'c:\windows\microsoft.net\framework\v4.0.30319\aspnet_isapi.dll'
reported itself as unhealthy for the
following reason: 'Deadlock detected'.
Error:
It is not possible to run two
different versions of ASP.NET in the
same IIS process. Please use the IIS
Administration Tool to reconfigure
your server to run the application in
a separate process.
We have checked all applications and ensured that they are running on the correct versions of ASP.NET and also in their own separate app pools.
We have looked at the IIS logs at the time the errors are recorded but this doesn't give any clues as to the issue. Is there a tool available that could give us more information as as to which application is causing the errors and what was happening at the time?
The discussion here might be helpfull for you as well:
You can configure the application pool to orphan the worker process rather than kill it when this condition happens - you can then use adplus to collect a hang dump of the worker process which can be analyzed to figure out what in the process is deadlocked.
(...)
It means that the asp.net thrads have not returned from whatever activity they were doing for a very long time and asp.net has run out of threads - this would normally indicate deadlock. This kb also talks about how to generate dumps for analysis for this condition.
I had the exact same error, and it was due to a .NET 2.0 custom error page that my .NET 4.0 app was referring to.
I had set up a custom error page that was developed in .NET 2.0 and it was applied at the top level of the IIS web site.
The .NET 4.0 application was using a unique MVC URL routing scheme, and for some reason just that application kept locking up and eventually those deadlock errors would come up.
I got rid of the custom error page setting which pointed to the .NET 2.0 web page and switched it back to the default "Not Found" static error. I restarted the application pool and the web page started working without issue.
Hope this helps someone else out there.
http://adamantinewolverine.blogspot.kr/2012/10/running-iis6-in-32-bit-mode-on-64bit.html
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.