got a weird question for you based on some weird happenings on our site. We have four .DLLs in our ASP.Net solution (ie. managed code in the /bin folder). This morning we updated all four of them, the site was tested and worked fine.
This afternoon I uploaded a new version of one of the DLLs, and it took the whole site down, much to our dismay. I quickly swapped out the new one for the old one, taking the site back into the state before I'd uploaded the DLL, but the site was still down. We were forced to restart the entire server, but still no joy: As far as we were concerned, the site had been returned to exactly the same state it had been in before I'd uploaded anything, and it still wasn't working.
So, after a bit of investigating we discovered that it was a bug in one of the DLLs that had been uploaded that morning (i.e not related to the DLL I'd uploaded in the afternoon).
What we seem to have discovered is that, for some odd reason, the AppDomain didn't recycle properly when we uploaded our DLLs in the morning. Some of the changes made to the site went live, but at least one of the DLLs remained cached, instead of being updated.
When I uploaded a DLL later that afternoon, it caused an AppDomain recycle which then included the bugged DLL that was uploaded this morning.
Has anyone else had problem with the AppDomain not recycling when it should? Or possibly have another explanation for what it could be? AFAIK the AppDomain should be recycled every time there's a change made to any file in the bin/ folder... If so, how did it accidentally cache an older version of a file and not recycle properly?
Here's Scott Forsyth talking about AppDomain recycling: http://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-2D00-AppDomain-recycles_2C00_-more-common-than-before.aspx
Sometimes the site won't recycle if it is under load as IIS thinks it is better to keep running than take everyone down for the amount of time the site requires to restart.
At most places I've been the best practice is to always issue an IISRESET after updating the site files. This ensures everything gets recycled after a deployment.
Related
After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).
When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.
Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.
Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.
The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.
Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.
Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –
A bit late to the party, but maybe it'll help someone. For me it was because I accidentally mapped two IIS sites to one directory. This resulted in two IIS background worker tasks and Application Application_Start() being called twice even though the second site was marked as "Stopped" in IIS.
Bit of a weird one. For some reason one of my DNN modules keeps being converted into an Application in IIS7 in my development environment. Meaning when I try to view a page that contains that module it can't find the module correctly. It's ok if I go into IIS and delete the application, then restart the site but is a bit of a pain and am little worried it might do this when uploaded to the live server and disable the whole site.
Anyone encountered anything like this before? Any thoughts?
This is a common problem with my VS templates, though not for everyone, and it doesn't happen all the time. It stems from Visual Studio, so it shouldn't ever be a problem on your production servers, unless you upload source and try to compile there, than it might be an issue.
HuwD,
A good resource might be my module template installation video which gives good information on setting up your development environment and debugging issues (regardless of the template you use). Check out between 1:30 and 5:00 minutes for the environment setup, and after 19 minutes some of the troubleshooting.
A couple common problems I see Visual Studio doing is creating an unwanted virtual directory on the DesktopModules folder and/or creating an unwanted web.config in the module's root.
Another good resource is Dnnhero.com. In the development section there is a series on DNN7 environment and template setup.
You may want to give a try a free module called Users Importer - A bit old but worth a try.
Here is a paid alternative: Bulk User Manager
I recently ran into some strange problems. Changes to files that are not code-behind (and not gets compiled to a DLL) should not require you to recompile the whole website, and this has never been I problem for me. These should actually get compiled dynamically when you first access the resource, e.g. the first time when browsing an updated aspx-page in the browser.
But yesterday, during development of a website, I noticed that even the smallest changes in html, javascript or anything in the .aspx-files doesn't get reflected when I save and reload the page in my browser. Rebuilding doesn't help either, actually I'll have to do a "Rebuild All" (in Visual Studio 2008) in order to see the changes. This applies to all aspx-files in my project.
I tried with minor changes on files in another web application project on the same server, and there it works as it should. Something must has happened to this particular application, but I cannot figure out what.
Do you have any ideas on how to solve this?
Best regards
Not sure if this was the solution, but I noticed that I was running out of disk space. After some cleanup it started working again...
I have a solution with 2 projects in Visual Studio 2008 SP1, .NET Framework 3.5 SP1.
a ASP Web site.
a Class Library (dll) project.
I have a reference from the Web Site to the Class Library, as the Class Library is my data layer. But anyway, the thing happens only with this basic setup, a solution with these 2 types of projects and a reference from the Web Site to the Class Library.
Now, each time I modify something in the Class Library and I build it, Visual Studio creates a file called app_offline.htm and then deletes it (it sends it to the Recycle Bin).
This is really annoying because at the end of the day I end up with a full Recycle Bin and me, being the perfectionist I am, I want to keep it clean. I'm not the only one with this problem: here and here.
I know now the cause of the problem, but still not how to fix it. If you didn't hear about app_offline.htm before, here's ScottGu's article on app_offline.:
Does anyone know a solution to the problem? Some setting in VS to delete the file forever after the Build process? (I really don't want to set my Recycle Bin to do that, as I do delete things unintentionally from time to time and I'd like to be able to recover those.)
This file does not go into the Recycle Bin for me. Perhaps you have some draconian utilities installed, which do this? Many anti-virus tools and general system utility suites used to do this back in 2000 but I do not have experience with later versions.
Update: You can use Process monitor to find out which process moves this file to the recycle bin.
[Disclaimer: I'm adding an answer firstly because I hope it will get the question seen by more people (I admit it) and secondly because I have no characters limit on an answer, as oposed to a comment.]
I followed Sander's suggestion and used Process Monitor to track which process moves this file to the Recycle Bin.
It was indeed devenv.exe.
There are several events where it makes operations like: QueryDirectory, QueryOpen, CreateFile and CloseFile. And devenv.exe is the only process that has anything to do with app_offline.htm
Still... How could I make Visual Studio stop filing up my Recycle Bin? (way to go, Dan, putting a question in the 'answer' (: )
I started seeing the same problem shortly after we suffered a VSTS server problem. The VSTS server went down for a day so I had to open the solution in offline mode. After the VSTS server came back online, I had to reopen the solution under source control, and the app_offline.htm files start occurring non-stop every time I recompile my web projects.
THIS IS REALLY ANNOYING!
I am not sure how to stop it yet, but I know how to reliably recreate the problem on my environment:
Windows XP Pro, VS2008, SourceGear (Source Control System).
Whenever I perform a checkout, the app_offline.htm file is instantly created and deleted in/from the root folder. The source control system is using SQL Enterprise, so I am not sure it is related to some references from posts people are making about SQL Express.
Again, still don't know how to stop it, but maybe this will help other figure out how/when the file is generated and deleted.
Use Web Application projects, not the Web Site templates, those are for 'dummies'. :)
I had this problem because I published directly to Azure Web Service from the dev machine.
The answer here with another possible workaround here.
This is all I could find on the subject. Unfortunately it's also speculation.
http://petermcg.wordpress.com/2008/05/12/silverlight-app-offline/
I have a pretty weird situation here, and i came up with a very strange conclusion, the thing that makes me think that i got it all wrong, that i have cured the scratch with hcl or something !
Anyways, two days ago i found out that all the pages in a certain directory on a web app that I work on stopped working;
When I tried to debug, iis shout out an exception at my face, the exception was kinda weird (and very ambiguous to me), it says
"type Global is declared in an
assembly that is not referenced here"
and the cursor pointed to a line of code in the generated asp.net temp files, so i checked up my bin directory and compared the live version (the broken version) to my own local version (the working version) and found a couple of dlls missing on the live version
i copied those dlls from the local to the live, and everything went just fine!
the question is, where did files go in the first place, and if the temporary asp.net files were corrupted, is there is any way to fix them without having to reinstall the framework, or rebuild the app?
The Temporary ASP.Net files are created whenever your web asp.net app has to compile. (If you search this site or Google, you will find many descriptions and information on how this works.) They can be safely deleted at any time, so long as the original files are available to recompile. No reinstallation of .NET framework needed.
I doubt that anyone is going to be able to tell you where they went. Your best bet is to put some auditing on the files and log the deletes to the event log.
Its possible that ...
someone else who has access to the server deleted the files accidentally or on purpose.
you deleted them accidentally
you were hacked
your files were deemed viral and were quarantined by an anti virus.
Probably a few other reasons I cant think of too...