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?
Related
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.
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.
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 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.
I'm new to ASP.net but not to C#, .net or Web Development.
In PHP it was nice to be able to go right to the browser and refresh whenever I made a change. Using ASP.net with VS08 however seems a bit awkward.
Should I launch a development server and keep it open, refreshing the browser when I make a change or should I close the development server between editing code?
Sorry if this sounds silly but I'm just not sure what the "accepted" practice is here.
When developing with Cassini, I always just let it run as it saves the startup time whenever I want to debug. It doesn't hurt to do so, it'll always reflect the current built DLLs and works pretty well.
You have two options when going from Visual Studio to the browser. The first is to debug the application by pressing F5 and running it. The second is to choose the "View In Browser" command (or use the keyboard shortcut Ctrl+Shift+W). The latter doesn't attach debuggers to the web server which makes it much faster than debugging but doesn't support things like code-behind break points or breaking into code upon unhandled asp.net excpetions.
For fastest development, minimize the number of times that your web server is started and how many times you attach the debugger to the web server.
I launch my dev server and then leave it running all the time. Instead of closing down the dev server, I detach the debugger, and when I need to step through code I attach it again. This gives me the best of both worlds: saves me the web server startup time AND runs pages fast most of the time.
Depends what stage of development I am in.
If I am adding lots of files (something that you can't do in Debug mode), changing lots of code in App_Code (which will reset the app) or adding lots of components from the toolbox, then I will tend to leave Debug off.
Once I start actively debugging a site, then I will leave it on as much as possible.
I use IIS even for development so there is no "launch" of the web server at all. That being said, I will typically alt-tab between code I'm working on and the browser window while I am fine-tuning HTML, Ajax calls, or the code behind. Bigger changes require a restart and you will receive a message that the code is no longer in synch with the web site (during an exception) when you must restart.
The bottom line: you can debug while running in an ASP.NET application and, as long as you can get away with it, it is an effective way of tuning your software.