3

The question says it all.

I had a QA site and PROD site on a Win 2003 server with IIS 6. I moved the sites to a new server, Win 2008 R2 with IIS 7. On the new server, I set the app pool to 2.0 for the two new sites. I tested the sites a bunch before updating the DNS to point to the new server and the sites were working fine. So I sent my client an email letting them know they could update the DNS to point to the new server.

When I got home, I started getting alerts saying the site was down. After some investigation, I found the version of .NET for the app pool had been changed to 4.0 for both sites. This brought the sites down. The client does not have access to the server. None of my other developers changed it. I didn't change it myself. It seemed to have changed by itself.

Is it possible for the .NET version of an app pool to change by itself?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
DougCouto
  • 530
  • 1
  • 3
  • 18

6 Answers6

1

I know this is an old thread, but we recently had a server where after applying windows updates all of the .net 4.0 app pools changed to .net 2.0. I found a thread that claims that when resetting a server that the app pools can change to whatever version the DefaultAppPool is set to. On our server, the DefaultAppPool is set to 2.0, so this makes me believe that this could be possible. https://community.spiceworks.com/topic/467973-iis-application-pool-net-randomly-changes

Jeff Joy
  • 31
  • 3
  • This resolved my issue. I still dont know what caused defaultapppool to change to 2.0. This resulted in other apppools changing to 2.0 as well. Changing them to 4.0 resolved the issue – raj'sCubicle Aug 07 '19 at 18:52
0

In answer to your question. No, it is not possible for this to change itself.

I would also ask why your app will not run on NET 4.0 based on the fact that it is backwards compatible with NET 2.0.

ChrisBint
  • 12,773
  • 6
  • 40
  • 62
  • Chris, thank you for your reply. The app was built on .NET 2.0. I didn't know .NET 4.0 is backwards compatible that way. Also, I just noticed that more sites on this server are down. These are not Production sites, so I haven't received any alerts for them but they are down. I've now noticed that EVERY application pool in this IIS 7 server has been switched to 4.0. Any ideas how that could have happened without someone doing that manually? – DougCouto Jun 20 '12 at 13:50
  • Chris, let me clarify. I understand .NET 4.0 is backwards compatible with .NET 2.0. Yes, my app _should_ work in .NET 4.0, however, I'd have to, at a minimum, open it in Visual Studio, change the .NET version to 4.0, rebuild and hope everything just compiles nicely. Since I'm on a crunch to get these sites moved over, I don't have that time to do this now. – DougCouto Jun 20 '12 at 14:00
  • Normally a rebuild isn't even necessarry... it should just run. Unless you have mixed dll's ( dll's that contain unmanaged code) – Schwarzie2478 Jun 20 '12 at 14:32
0

I am not familiar with deploying apps/ sites to IIS, so please bear with me.

The question reminds me roughly to a blog article by Microsoft's Scott Hanselman: ASP.NET MVC Beta and RC Upgrades - Confirm your Expectations and Version Numbers in Production Environments

In this article Scott explained about differences in the version numbers of the used assemblies. He had not known about it before the the production site behaved differently from the development version. Possibly this article might help you to dig a bit deeper into the cause.

The article also refers to a tool named MvcDiagnostics (Link to NuGet page). MvcDiagnostics will allow you to get lots of information about your environment, paths and version information, for example.

In Scott's case, he found out that the local version of System.Web.Mvc.DLL was newer than the one on his server and running from the GAC instead of running locally.

Perhaps that can give you a starting point for your examinations.

Jens H
  • 4,590
  • 2
  • 25
  • 35
0

You can try to do that executing external PowerShell script:

Set-ItemProperty IIS:\AppPools\<pool_name> managedRuntimeVersion v4.0
Community
  • 1
  • 1
abatishchev
  • 98,240
  • 88
  • 296
  • 433
  • abatishchev, thanks for the reply. This is a script that would have to be run manually right? Or, maybe in a Scheduled Task or something... right? As far as I know, no one on my team ran a script like this on the server. – DougCouto Jun 20 '12 at 14:32
  • @Barbosa: You can run it manually or from server-side code of any kind – abatishchev Jun 20 '12 at 15:15
0

I did have this happen once, never found a reason, updated it back to 4 everything worked, client happy.

Was IIS7 but I can not remember any other details. Having dealt with hundreds of site deployments to various IIS versions on different windows platforms I was very surprised that this setting 'appeared' to change automatically. I'm not adverse to the possibility that someone else changed it, but it seems very unlikely, my project, my site, my deployment, had worked previously, rare for other users to change ANY settings on the server in question.

rob
  • 8,134
  • 8
  • 58
  • 68
-1

It shouldnt change itself, however, someone may have gone in and inadvertenly changed it as a default on the server

BugFinder
  • 17,474
  • 4
  • 36
  • 51
  • Thanks for the reply BugFinder. I'm starting to think the server was restarted and when IIS started up again, all of the app pools were set to the IIS default, .NET 4.0. Is that possible? – DougCouto Jun 20 '12 at 14:15
  • Unlikely, it would be more likely someone else went to change some website and changed the lot by mistake. – BugFinder Jun 20 '12 at 18:39