Using an External Javascript File with ASP.Net

I came across a very strange problem and a solution that I think others will benefit from.

To make things more modular I've started placing all commonly used Javascript functions into an external ".js" file. When using AJAX, the only thing you have to do to define each such file in the ScriptManager:

But here's the weird thing: Say you have a Javascript function called "abc" setup and working. If you then decide to rename it to something else (perhaps something more descriptive) you'll discover that you get an error, even when you've rebuilt your solution.

The reason is because these Javascript functions are cached in your browser, not in Visual Studio. So you need to clear your cache, which is often referred to as deleting all temporary files. Once you do that then your app will be able to find the newly named Javascript function.

"Does not exist in the current context"

The fun & games with Visual Studio continue! I generally love the package but sometimes it frustrates me to no end.

So there I was testing a simple web page, adjusting this & that. Suddenly, when I tried to recompile it I got this message:

labelTagLine does not exist in the current context

This control resides in the header on the Master Page of my project. There's nothing fancy or special about it. I did a comprehensive search and found lots of others who had encountered similar problems with controls suddenly not being recognized. I tried all of their solutions but to no avail.

So eventually I copied main.Master and main.Master.cs outside of the project folder and deleted these two files within the project. Then I created a new, blank version of them. Slowly, I started copying the markup code and C# code back into their respective files, being sure to perform a "Rebuild Website" every so often. Lo and behold, when every last line of code was back, it worked! Something internally must have changed but nothing in my code files did. Another 2 hours wasted. :-(

Debugging with Visual Studio 2005 in Windows Vista

What a Microsoft level headache I encountered this evening. That's my code for, "it should work but it doesn't because of something Microsoft didn't take care of properly".

I wanted to do something similar: Debug a simple ASP.net 2.0 web page in Visual Studio 2005, running on my Windows Vista Ultimate 64-bit machine. I added a Debug.WriteLine statement in the Page_Load event handler of default.aspx.cs and sit it as a breakpoint - as I'd done thousands of times before with Windows XP.

I pressed F5 and looked at the code screen, naturally expecting the app to stop on the designated line. And . . . it didn't! I tried again, but still no go. So I shut down VS2005 and cleared all the DLL files from the bin folder and all the files from the obj folder. I restarted it, recompiled, and tried again. Still didn't stop!

Then I did a ton of research and via Scott Gu's [excellent] blog was taken to this page. There are a LOT of steps. After following the instructions in the last one I tried again but it still didn't work! So then I examined this series of articles by Mike Volodarsky. I followed the VS2005 link and carefully went through the steps needed to get debugging working. I didn't actually go as far as running the app through IIS7 as I intuitively couldn't believe that the internal web server in VS2005 wouldn't debug properly in Vista.

I did some more research and came across this ASP.net forum posting. Note that the second fellow, from Lahore, Pakistan insisted to check the web.config file and be sure that debug is enabled. "Of course it must be", I thought. But when I checked, it was not! So I changed it to:

I hit F5 again and ... it worked!! I don't know for sure whether all those other steps were necessary though I think that installing the hotfix was probably a good idea.

In conclusion, I must say that situations like this are all too common with Microsoft development products. This should have been a "5 minute" thing to fix, but I wasted 90 minutes of my time on it. I simply don't accept that such things should be happening from a paid for product built by a multi-billion dollar company.

Though with the introduction of this blog, I hope to help others save countless time in the future by documenting situations like this and having it picked up shortly by the search engines.