【转】Finding the AJAX Control Toolkit in VS2005

本文转自：http://weblogs.asp.net/bsimser/archive/2008/03/10/finding-the-ajax-control-toolkit-in-vs2005.aspx

This might be old information to some, but I wasn't able to find the answer (very clearly) on the web so here it is.

If you're building a new website with Visual Studio 2005 and want to use the AJAX Control Toolkit there are two different variations you can download, one with source and one without. The most excellent videos by Joe Stagner and co. only shows using the toolkit by building from the sources. For most people that just want to use the toolkit, it's a little confusing as to where they can browse the toolkit after installing the VSI package.

The non-source version of the toolkit includes a VSI package that will install a new template (for creating your own AJAX extensions) and the sample website. When you install the base AJAX extensions, you'll get a new section in your Visual Studio toolbox appropriately named "AJAX Extensions". However it only includes the basics (ScriptManager, UpdatePanel, etc.). What about all those mew uber-cool extenders you get with the Control toolkit? Well, you have to add those to your toolbox yourself. While you can copy the sample website somewhere and refer to that copy, there's already a copy of the toolkit installed when you install the VSI.

To add the Control Toolkit Controls to your Toolbox (say that 3 times fast kids) following the bouncing bullet points:

1. In Visual Studio bring up your Toolbox (Ctrl+Alt+X)
2. Right click on it and select "Add Tab"
3. Enter a name for the new tab. "AJAX Control Tookit" works but you might decide to name it something more personable like "Alice" or "Ted".
4. Right click in the new section and select "Choose Items..."
5. Wait about 5 minutes while Visual Studio calls the mothership, indexes your entire hard drive, and makes a Starbucks coffee.
6. In the "Choose Toolbox Items" dialog click on the "Browse..." button. This calls up a File Open dialog to pick an assembly that contains the controls you want to add.
7. Select the appropriate assembly (see below) and click "Open"
8. The new controls will automatically be checked so just click "OK" and they'll be added to your new Toolbox section. If you don't have an .aspx page opened, the tab section won't display anything so it's best to this when you have a page opened up (yeah, another silly quirk with Visual Studio that doesn't make a whole bunch of sense to most carbon based life forms)

Here's the "see below" section from above. The VSI package installs a new template for building new extenders, but new projects built from that template need a copy of the toolkit when they're created. So you already have the toolkit installed if you install the VSI, it's just buried in your Application Data directory. You'll find it in:

{Documents and Settings}\[username]\Application Data\Microsoft\VisualStudio\8.0\ProjectTemplatesCache

Depending on which VSI package you installed they'll be a copy in the "Visual C#\AjaxControlExtensionProjectCS.zip" or "Visual Basic\AjaxControlExtensionProjectVB.zip" folders. If you installed both, it'll be there in duplicate so it doesn't matter which one you pick.

Alternately, you can just install the VSI files (or not) and squirrel away the AjaxControlToolkit.dll away from the Sample Website folder somewhere to refer to later (under the {Program Files}\Microosft ASP.NET\ASP.NET 2.0 AJAX Extension folder where AJAX is installed to is a good place). Just remember to grab the whole tree with all the langauge resource files. You'll find them in the "bin" directory under the Sample Website.

HTH.

<rant number="1">The Application Data directory is something that bewilders me, much like anything Microsoft creates and produces. Let's say you want to do a back up of all your data (for re-imaging or just for kicks). One would think it might make sense to just copy the entire "Application Data" folder to a backup and all is golden. No. Files in here are locked by the OS so even if you shut everything down, you won't be able to copy the folder out (and don't even try to move it, that'll bring down the wrath of God upon your system). In addition the folder is hidden, so for those people (like your father in law who insists on "cleaning up" his hard drive by deleted folders in the Program Files folder) they'll never see it, much less know what it's for. Also, if you manage to make a copy of your Application Data folder and drop it onto a new system, don't expect anything to work right. It's a bad, bad, place I've been to a few times. The Application Data folder is a neat place to put stuff and a good idea on paper, all nice and tidy in a single location but other than a big storage place a little functionally useless when it comes to backups and restores</rant>

<rant number="2">When will Microsoft learn and stop burying important files deep in the OS? More importantly, we need a file system that doesn't have limitatations on path length and applications that won't bomb out because of it. The Ajax Control Toolkit above is, by default, located in a directory with 143 characters in it's name (depending on your user name). It's also a bugger to navigate to. Path lengths are so 1990s so why are we still living with them as a constraint? For example I had a developer who would checkout source code to his desktop. It was convienient because it was right there. Problem is that the Desktop is in reality under the {Documents and Settings}\username\blah\blah\blah folder, so his builds were breaking because by the time you got down into a 20 or 30 character folder/filename combo in our solution, you blew the path length. And Windows wasn't very forgiving on what the error was. You think "Path length too long" would be the approprirate error message but no, there would be some cryptic error from Visual Studio (or maybe the file system, or both) saying "Invalid assembly" or "Corrupted assembly file". Anyways, we need a better file system.</rant>

转载于:https://www.cnblogs.com/feima-lxl/archive/2008/09/24/1297576.html