Getting JQuery Intellisense working in Visual Studio 2008

People have been using JQuery in Visual Studio successfully for over a year and there are a lot of links on how to set it up, but I thought I'd write myself a few notes on how to do it since I'm finding myself doing it on various machines (work desktop, home desktop, netbook, etc.) over time and need a quick cheat sheet.

1) Get the latest version of jquery from JQuery at http://docs.jquery.com/Downloading_jQuery. As of this writing it's version 1.4.1. Download the "jquery-1.4.1.js" file (the uncompressed version) and the related Visual Studio documentation file, "jquery-1.4.1-vsdoc.js."

2) Make sure you've got SP1 installed on Visual Studio 2008. You can check to see if it's installed by going to the "Help" tab and then the properties menu to check if the service pack has been installed:



















If it isn't installed, you can get it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=27673c47-b3b5-4c67-bd99-84e525b5ce61&displaylang=en

Note on installing the service pack: Be prepared to give it like 40+ minutes to run, plus have your Visual Studio 2008 release DVD around (or have the install files available somewhere on the hard disk) since it'll be asking for it during the upgrade.

3) Download the hotfix from Microsoft to support Jquery Intellisense:
http://code.msdn.microsoft.com/KB958502/Release/ProjectReleases.aspx?ReleaseId=1736

4) Test it out with a small JQuery project. Create an ASP.NET web project, then add a "scripts" folder to the project and copy both the JQuery files downloaded earlier ("jquery-1.4.1.js" and "jquery-1.4.1-vsdoc.js") into it; add a "script" section to the ASP.NET markup of the page and add a reference to the JQuery file (see illustration) and type "$" to see if Intellisense is up and working -- :
















5) Typing a period after the dollar sign ("$.") should produce more JQuery Intellisense documentation and indicates that Intellisense and JQuery are now working together fine:

Simple PowerShell way to change a string across multiple files

This situation comes up only occasionally and I keep forgetting how to do it, so here it is so I can save myself the time next time:

1) Position myself in the directory where the files are located
2) Type in this quicky applet in PowerShell:

$filenames = ls *.exe.config
$match = "devserver2"
$replacement = "prodserver1"
$filenames | %{
>> $content = get-content $_
>> $content = $content -creplace $match, $replacement
>> $content | set-content $_
>> }

Note that I used the case-sensitive PowerShell replace verb. I wish this could be a one-liner but I haven't been able to figure out how to do that.

Helpful tip when using VS2008 over slow network connection

Disable the animations in VS2008 to improve performance over slow network connections:

Tools / Options / Environment / General -> uncheck the "animate environment tools" checkbox

Installing VS2008 C# services under Vista

There's something wrong with using a Visual Studio 2008 setup project ot install a windows service under Vista.

It's a pretty deep problem (see Alek Davis's post at http://alekdavis.blogspot.com/2007/09/deploy-windows-services-on-vista.html for details) ... and not worth the effort, in my estimation.

Just use INSTALLUTIL under the C:\Windows\Microsoft.NET\Framework\v2.0.50727 directory to install the service the old-fashioned way (INSTALLUTIL ) using the machine's administrator account (make sure to run INSTALLUTIL using "RunAs as Administrator" -- it doesn't seem to work if you try running it with an account with administrator privileges).

I included the Alek Davis link in case I need to actually create a service setup program in the future, here's hoping I don't.

I'm curious as to whether this problem persists in Windows 7.

This is another reason that Vista is not working out for me. If I hadn't gotten that free copy at the Microsoft Roadshow I'd have never touched it; perhaps this is why it was free.

Forcing Tortoise/SVN to refresh icon overlays

I use Tortoise/SVN at a client site as the tool for handling source control. The client's computers are rather underpowered, unfortunately, and often the Tortoise icon overlays can get really out of date (or disappear entirely). It's hard to tell what has been committed, what's changed, etc.

The easiest way I've found to force a "refresh" on these icons is to close the Windows Explorer window and run "TSVNCache.exe" from the command prompt. Give it a chance to run and wait a while (I'm finding that it takes my client's machines about 20 seconds), then start Windows Explorer. The icons should be back and (more importantly) should correctly reflect the status of files/directories.

Checking Session variables during Visual Studio 2008 debugging session

Often during debugging I need to enumerate the current session variables in use plus get their current values. It isn't documented but it isn't hard to do by examining the "Session" variable which is available during a debugging session.

• Add a "Session" watch variable in the watch window
• Under the "Session" watch variable, look under "Keys"
• Look under "Non-public members"
• Look under "_col"
• Look under "Non-public members"
• Look under "_entriesarray"

Each Session variable will be listed along with its current value.

Calling ASP.NET web service methods directly from a remote machine

Debugging a web service on my local machine is easy -- write the web service, publish it to my local machine, and then go to "http:\\localhost\webservice1\service1.asmx" to get a convenient prefab test form for entering simple data into the web service.

The prefab form is great for quick testing but unfortunately when you try and access it from a remote machine you get the message "The test form is only available for requests from the local machine."

There's a simple solution. Add these settings to the Web.Config file of the web service application:

<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>

This opens up a big security hole by letting remote users directly access the web service itself so you'd should naturally never do this in a production environment, but for quick-and-dirty testing it's quite useful.