I've been helping a client rebuild a website that is hosted on a IIS 6 (I think) after he fired its IT Director.
One of the tasks was to change all the passwords for DB access, which went just fine.
Given this, we had to recompile the web application/site to reflect these changes (new user/password) and we tried rebuilding the web site (which went fine) and then placing the files on the same folder as the previous ones were, basically replacing what was on the server.
But now, the site won't work at all giving just a bad request and I can't seem to be able to fix this.
I've never used IIS before and the configurations done are the very basic ones (almost nothing really) so I can't seem to understand why this doesn't work.
Could anyone give a hand?
Thanks,
BR
Well, turns out this problem was split in two parts that were causing the problem.
Number 1 was that the Web.config file wasn't properly setup to a production environment and thus causing inaccessibility problems.
Number 2 was that for some reason IIS was set to use ASP.NET v2 and the website was built using .NET 4. Although this shouldn't be a problem it was causing some other problems.
IF someone ever gets caught in the same problem, it's worth checking out these two items, at least, and do a IIS Reset.
Related
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.
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.
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).
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
I have been programming in php for a while, and recently I started a new job ago where I am now programming in c#/asp.net.
While asp has decent performance when deployed, there is one thing that has been bugging me for the past few months. After any code change it takes about 30 seconds for the page to reload for testing.
I guess it is doing the JIT compiling or something. But it can be REALLY frustrating, especially if I am concentrating, and want to test out several incremental changes as quickly as possible, only to have to stare at a blank page for 30 seconds.
Does anyone have any tips to speed this process up?
In Visual studio 2005 every reference you add adds a .refresh file that makes sure the reference did not change since last time and if so brings the new version - if your references stay the same, you can just remove it!
also see here for more tips for VS 2005
Two things I have found:
Try alternating between the "User Visual Studio Development Server" and "Local IIS Server" in your project properties / Web tab. Depending on your project, one may be faster to start and attach to than the other.
If you have projects in your solution, such as CLR-based SQL procedures, they take a few seconds to deploy to the SQL server. If you can afford to remember to turn them back on, or make a separate project config, disable them in the build so they do not get deployed every time you press F5.
Doing those cut my "F5 to live" time from about 20 seconds to 4.
I guess that can be frustrating coming from PHP.
Thirty seconds sounds far too long though. Ensure the basics like free ram etc..
A couple of tips.
1. You do not have to run the debugger in order to run the site. Once you have the site up with the built in VS web server or IIS, you can make your code changes, build and just refresh the page in your browser. No need to hit play and have VS start the whole debug process. If you actually want to debug though, you don't have a choice.
2. Changes to an aspx page do not require a rebuild. I make changes and simply refresh the page to see the result instantly.
Check out the web tab in the project settings to configure how you want VS to handle serving the site. There are some options in there to hopefully help you suite it to your style. ex. I don't let VS launch a browser for me whenever I want to debug. I set the option for it to just wait for a request. Then I can just use the browser of my choice to get started.
Good luck
I feel your pain.
Personnaly I like the ASP.NET website project better for speed of developing.
I don't know if you have that possibility though..
In visual studio do file->new website.
For this project type you don't need a rebuild all the time and you can just refresh a page in your browser when you have changed it. (no rebuild/debug necessary)
I've had similar experiences, it can be slow to recompile at times, but varies based on where and what code is being changed - ie if it is app_code or just page specific.
What sort of hardware are you running on? VS can be a memory hog, and anything less than 2GB seems to make it slow.
Our website has a very long load time due to actions which only occur during the Application Start phase (when the ASP worker process starts). In particular loading commonly used objects from a database into memory was causing a significant delay. We found that using compilation symbols to disable some features when debugging eg security and user roles, helped a lot.