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...
Related
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'm working on a system that embeds various JS and CSS resources in the project dll, and access them using WebResource.axd. This all works fine locally, but if I download and install the app from our nightly build server, all our WebResources report a 404 error.
We initially though it was because the downloaded zip file was blocked, and for a while, unblocking the downloaded zip before extracting did work, however, now, nothing seems to work.
Swapping the downloaded dll with the one created locally makes the WebResources work, so it sounds like something is going on with the dll (either on the download server, or during the download process).
Anybody got any ideas what it might be?
So I managed to find the culprit myself, which was that the Modified Date timestamp on the DLL's was set to the future (our build server is in a timezone one hour ahead of ours), so for some reason WebResource wasn't picking them up.
Hope this helps someone in the future.
This normally occurs if you are using AJAX/3rd party controls. Most probably it is not a problem of missing WebResource.axd but some other reference / resource pointer is missing. Try debugging using the information provided on this site
We recently migrated from VS 2008 to VS 2010. The migration went fine, except for our web project. Before, in VS 2008, the site showed up as http://localhost/Website. Now, it appears as C:...\Website. It appears that when we did the migration, VS started to treat it as a file system website.
I've tried removing the existing site and re-adding it as an existing website, but it still displays it as C:...\Website. Is there any way to convert it back to show it as a http://localhost/website, and run through IIS, as opposed to the default ASP.NET Development Server?
Special thanks to John Dundon at Microsoft for helping me resolve the issue. Here's what he said:
Thanks for all the details. This actually sounds like a quirky behavior
in VS that I think I can help you work
around.
I believe the reason it’s remembering
to use the local development server is
because it got stored in the SUO file.
So there are two possible ways to fix
this:
Re-open your solution from source control as an administrator on the
machine with IIS installed and
everything should get downloaded to
its right place
If you close VS, delete the SUO file (note – this will erase some
settings about the state of your
solution but shouldn’t cause any real
data loss), and then re-open the
solution, it should ask you to
re-download that particular web site
and will try to make it an IIS web
site again.
Note however though that since your
virtual directory already exists on
your machine, it’s going to ask you if
you want to use it – I’m assuming you
do, but it will overwrite any files
when it does.
Let me know if this works for you (and
while you technically shouldn’t need
to, it may be a good idea to back up
any work you’ve done in this
enlistment that hasn’t been checked in
prior to trying this).
I followed his advice and removed my SUO file and re-opened the solution. The website was automatically fixed as http://localhost/Website and it also checked out the .SLN file as well, and when I checked it in, it fixed the issue for other developers as well. Hope this solution helps out others as well with this quirky issue.
Look in the project properties, on the Web tab. You'll be able to select whether to use IIS or the development server, and which virtual directory to use.
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.
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/