Ok, this is one of those really weird errors that seems like the machine's just messing with you.
We have 2 websites, ASP.NET, both were 2.0, and we upgraded them both to 4.0.
They're the same exact codebase, but the web.config files are different, they point at different databases, and they run as separate web apps in IIS.
After the upgrade, one works and one doesn't.
The one that doesn't work will throw a bunch of javascript errors around the Microsoft AJAX Control toolkit like 'Sys is not defined', 'Type is not defined', and '__nonMSDOMBrowser is not defined' (in firebug). When I use the Scripts panel in firebug it lists all the different '...ScriptResource.axd?d=IOBqtxq...' scripts, but when I ask to look at them, many of them will return 'Failed to load source for: /ScriptResource.axd?d=IOBqtxq7p...'.
A couple of them do come back with the CodePlex copyright and some javascript, but many of them don't. And the truly weird thing? If we recycle the app pool for the broken site, we don't get those errors the first time we hit the site. The postback works, we log in, etc. Then we go back and hit it again, javascript errors are back and no postbacks.
Any ideas?
Ok, I hate answering my own questions, but since no one else is weighing in, this is the best we've come up with.
There's a setting in IIS for the website that specifies Web Garden Threads, which I assume is how many threads to use if the site is in a load balanaced web garden. We had this new site set to 7, which is how it was in .NET 2.0. Apparently 2.0 is more forgiving (or ignores it), but 4.0 freaks out. The single request to the site is a request for lots of different resources, which end up being handled by different threads, which as you can imagine makes for chaos. And it's different every time depending on which threads do what.
So, unless anyone else has an explanation for this, I'll close this.
Running many applications out of the same app pool can cause really strange ajax behaviors. Often times you'll see this with apps sharing the DefaultAppPool.
Try creating a separate app pool for the application.
Related
I have several projects in asp.net and in all of them I have the same problem. The first time I access an aspx page the load is very slow. Once I close the page and reopen it, the load is very fast. Why is the first load so slow? Can I change any settings in IIS?
Thanks
I have read a lot of documentation but I am not an expert in this and I have not gotten any progress.
By default, asp.net web pages and code files are compiled dynamically when users first request aspx page from a Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
More information about asp.net dynamic compilation:
Understanding ASP.NET Dynamic Compilation.
How to: Precompile ASP.NET Web Sites for Deployment.
Ok, so several issues here.
You don't mention if you are talking about your developer computer - say hitting f5 to run the site.
next up, are you deploying a asp.net web site, or a asp.net web site application?
With a application then the compile of the code and pages occurs on YOUR computer, and the .dll's are built by Visual studio (VS). So, at deploy time, then there is a first-time delay, but it not all that long - maybe 5 seconds, and that's as app pool etc. spools up.
However, if you deploy a asp.net web site? Then unlike an "application", the source code (vb, or c#) pages for code behind are included, and deployed to the web site. And this means that IIS does the compile of pages - and often on the fly. This deployment model is often preferred by many, since you can open even the live files on the server, edit one line of code behind, hit save. On next page use, it will re-compile.
If you use an application, then as noted, IIS does not do the code compile, and in fact not even the source code is deployed during a publish. Of course, while there are many benefits to an "application", the ONE big downside is of course that you require a full site re-publish EVEN if you change just one line of code behind.
So, while an application has "some" delay for the first site use, it tends to be considerably less of a delay compared to when using/deploying a web site. (Since then, IIS has to compile the code, and in fact has to compile each page used).
You don't mention/note which deploy model and approach you are using here.
As noted, while the web site option is certainly less efforts to make a change to one page or a bit of code, I still far prefer the "application" approach, since things like "referencing" additional class library and code, and even being able to say use the Rosyln compiler (which may well not be on the server and available to IIS). As a result, I prefer and use an "application" despite the extra efforts required come publish time, but the benefits at developer time far outweigh the downsides.
And of course, one benefit of the "application" approach, is you do as a general rule get far faster web start up times.
I have a problem with an old application in asp.net.
This application runs on a server with windows server 2012 and is used by hundreds of people at the same time (same app but which is pointed to by different domains).
The problem is this: every time I modify an .asp file, the page takes a lot of time to "recompile" the code and this causes damage to the users who use it.
This problem does not occur with the exact same application but running on another dedicated server used only by one user.
I've been researching for days, the only noteworthy thing found is that, in the server iis, if I recycle on application pool -> select the application, it has exactly the same effect.
I don't know much about windows server so I ask you for help.
Thank you!
You have two types of deployment models.
First is what we call a asp.net web site,
and then second, is what we call a asp.net web site application.
They sound the same - but they are not.
So, while most perfer using a "application"? The ONE down side is that you have to re-publish the WHOLE site if you say change some code behind. This is good, and bad. The good part is that your code is re-compiled BEFORE you publish. (and in fact, you might even want to re-name "app_code", since that does re-compile by the web site.
However, for the most part a web applcation is "harder" to make a small update, since when you publish, you have to re-publish the whole site. But, the good part is that all code tends to be compiled down to ONE .dll. In effect the the site is pre-compiled before publishing. And with a applciaton, then you can add/change and do more things. In effect, the web site "applcation" allows you to do things like create say a custom logon provider. In most cases, this means the WHOLE site is under your developer control. It also means that code behind (source code) is NOT pushed up to the site.
Then you have what is called a asp.net web site. This allows you to say modify the code (code behind) of one page and then push that one page (and code) up to the site. The web site will thus re-compile that one page. You will note the "delay" that you experiance - but it ONLY occures the first time that page is published.
So, for a "application", you will in Visual Studio open up the project (and a sln file) is used.
For a web site, you from Visual Studio go open->web site.
I hands down prefer web applications, but they are MUCH harder to deploy a small change, since as noted, you have to re-publish the whole site.
However, the two different choices would thus explain the "difference" and as to why the other site don't experience the delay as much as you are. However, usually on first load - there can be a one time delay after a re-publish. And this quite much means the site is down for this time to re-publish.
Also, do keep in mind that if you do modify some files (such as web config), then this WILL cause the app-pool to re-start. (and if you not using sql server sessions, but in-memory sessions - they get blown out when you do this).
It also somewhat possible that the server with one user has more memory, more CPU and a much lighter load - so the reduced delay after making changes might well be the light load on that server.
However, the above two different publishing models and types of asp.net sites would be the first thing or at least the first issue to be aware of.
First, you need to determine if it is a website or web application project (https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1). Default for web application is rebuild for single page changes while default for website does not force recompilation except if special folders or files are modified. You may check to see if any settings for the app pool differ-- in particular "Disable Overlapping Recycle". You may also check the web.config as there may be a setting that is forcing rebuild. You want also want to look at Explicit Complication/pre-compilation option.
You may want to reference the following resources: https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/determining-what-files-need-to-be-deployed-cs
https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1
Optimization setting
https://learn.microsoft.com/en-us/archive/blogs/davidebb/a-new-flag-to-optimize-asp-net-compilation-behavior
I have tried looking at "related" questions for answers to this but they don't seem to actually be related...
Basically I have a VB.Net application with a catalogue, administration section (which can alter the catalogue, monitor page views etc etc) and other basic pages on the customer front end.
When I compile and run the app on my local machine it seems to compile fairly quickly and run very fast. However when deployed on the server it seems to take forever and a day on the very first page load (no matter what page it is, how many stylesheets / JS files there are, how many images there are, how big the page markup is and so on). After this ALL the pages load really fast. My guess is this is due to having to load the code from scratch; after that, until it is recycled, the application runs perfectly fast. Does anyone have any idea how I could speed this part of the application up? I am afraid that some customers (on slow connections such as my own at less than dial-up speed) may be leaving the site never to return as a result of it not loading fast enough. Any help would be greatly appreciated.
Thanks in advance.
Regards,
Richard
PS If you refer to some of my other questions you will find out a bit more about the system, such as the fact that most of the data is loaded into objects on the first page load - I am slowly sorting this out but it does not appear to be making all that much of a difference. I have considered using Linq-to-SQL instead but that, as far as I know, does not give me too much flexibility. I would rather define my own system architecture and make it specific to the company, rather than working within the restrictions of Linq-to-SQL.
If you can, the quickest easiest solution is simply to configure the AppDomain not to recycle after a period of inactivity. How this is accomplished differs between IIS 6 & IIS 7.
Another option is to write a small utility program that requests a page from your site every 4 minutes and set it up as a scheduled task on another PC that is on all the time. That at least will prevent the timeout and consequent AppDomain recycle from happening. It is a hack, to be sure, but sometimes any solution is better than none.
The proper solution, however, is to precompile your views. How exactly to accomplish and deploy that will depend on the exact type of Visual Studio project your web site is.
We recently migrated a large ASP. website from framework 1.1 to framework 3.5 and in the process also migrated from a website to a web application.
On the surface everything seemed to work fine, but now we are discovering that none of the "pages" are doing what they used to.
The site is made up of one default.aspx page that loads all the "pages" as user controls. (I am guessing this was to achieve the same effect as having a master page before master pages were invented.)
I think we missed a trick (or twelve) during the migration. What are the big stumbling blocks that other people have experienced
Update
We managed to find the problem that was making our pages stop working, but can not figure out why: When we cleaned up the code of the main page, we added whitespace (a newline) between the open and closing tags of the control that all the other "page" user controls get loaded into. Once we removed the newline everything started working again. Can anyone explain this?
I have experienced problems during manual copying etc. that has lost the connection between the GUI controls and the event-methods in the code behind. There are differences between the different versions of ASP.NET on how the event handling is coupled, and there are even more than one way of doing it (automatic based on names or explicit in code), and this is easy to mess up when changing from one "standard" to another, which is what you do converting to a differen version of .NET. It is also an additional source of confusion for Visual Studio when you also converted from Web Site to Web Application.
I am guessing that the trick was just to do some editing in Visual Studio, and VS might have automagically re-attached event handlers etc.
One things you should know is that if your new server is 64 bit. There is a chance that the controls on the page will be loaded concurrently with the page. In a sense there will be a lot of timing issues. If you are not using 64 bit server however this is not relevant.
I have several servers to test new code on. I primarily push out asp.NET web applications. Last week, I had an issue where I installed a newly developed web application on three servers. The three servers all run in separate environments. The application worked fine on two of them, but consistently crashed on the third server with each web request. The problem was eventually traced to an in-house developed .dll file being out of date on the third server.
I'm certain that this kind of thing happens all the time. However, there are numerous things that could go wrong to cause this kind of behavior.
I spent quite a bit of time tracing this problem. I would like to make a list of things to be suspicious of next time this happens?
What are the most likely reasons that a web application would crash on one of my servers while identical code runs fine on another server?
You can start off with a Beyond Compare directory comparison between working and non-working servers. That can tell you what, if anything, is different in deployed files. That would have found this particular problem very quickly.
http://www.scootersoftware.com/
ELMAH is a good way to keep a pulse on the errors on production applications
http://code.google.com/p/elmah/
Especially if you run it at the server level so that all the errors are posted
You could use Web Deploy to compare the site configuration, content, and if you define the right manifest it could even check for things in the Registry, GAC, COM objects, etc.
It will work for sites running in IIS 6 and IIS 7+ and it can even compare hybrid setups (ie IIS 6 vs IIS 7).
http://blogs.iis.net/msdeploy/archive/2008/02/02/using-ms-deploy-to-compare-sites-or-see-what-components-your-site-uses.aspx
Furthermore it can help you syncronize them as well in case anything is out of date with a single click (command line).