Google-like Suggest Textbox

We all love the Google search real-time suggestions. 

It is possible to implement a similar feature in your own web development using the asp.net ajax toolkit. 

Inside the toolkit you will find the AutoCompleteExtender.  Below I will detail how to get this difficult extender working.  

Don’t bother looking at the documentation on www.asp.net, it is more or less worthless.

First, associate the autocompleteextender with your text box.

As you can see, you must specify a ServiceMethod and a ServicePath.  This is where it gets tricky.  

You must create a web service (I used an asmx file) which strictly adheres to calls from the autocompleteextender. 

The service will look like the following:

This should get the service up and running.  Notice the query itself must strictly adhere to the number of records you want it to return.  You can also play a few formatting tricks via CSS.  Mine looks as follows:

The final product looks as follows:

Some tinkering needs to take place to make the textbox size equal to the div size of the autocomplete box. This can be done in the css for the text box, making sure there are not extraneous borders or margins.

Using jQuery to call a Web Service in XSLT

Transforming XML into HTML or the like using XSL Transforms is a powerful tool.  The biggest problem I faced when I began transforming certain XML tags into HTML controls is that the controls don’t do ANYTHING!  Fortunately I figured out a way to use jQuery inside of the XSL transform to call an .asmx web service.  I started by taking some XML, maybe something like:

<highlight>yellow</highlight>

In the XSLT when I find the <highlight> tag, you can do something like this:

This gives you a drop down style box, with the appropriate option selected, of course there will be a few more xsl:when options, and a an otherwise option that acts as a try:finally.  Now that you have a functionless drop down, its time to add the code behind that you want the drop down to execute on, say a change of selection.  So make yourself a Web Service (.asmx)  maybe something like the following:

Now for the trick: calling this web service using jQuery.  Of course, this jQuery must be in your XSLT, making it even more tricky to trouble shoot.  I used the jQuery.ajax() function.  It will looks something like this:

Now you have a fully function Control generated by XSLT. Enjoy!

Dynamic Help Removed in VS 2010

If you are like me you love and cherish the dynamic help feature in Visual Studio. In fact, I never actually learned how to write code because this feature is so useful. I would just click on a class I had no idea how to use and up pops links to the msdn documentation, which probably holds the code I need to write already.

This feature has been removed from VS 2010. Though you are still free to locally install the msdn documentation, there is no dynamic feature. Today is a sad day.

Installation order for Visual Studio and SQL Server

If you plan on installing the full version of SQL server (instead of the express version) with Visual Studio, I prefer to install Visual Studio first, preferably without the express instance of SQL server.

If you’re doing a fresh install of VS 2008 and SQL 2008 on Windows 7, install in this order:

1. VS 2008, WITHOUT SQL Server Express -> requires doing a ‘custom’ install
2. VS 2008 SP1
3. MSDN Library for VS 2008 SP1 (if you’re so inclined)
4. SQL Server 2008
5. SQL Server 2008 SP1

Comparing AD custom classes to AccountManagement

When developing code for an Intranet setting, where users must log in to be granted access to a client computer, it is often best practice to utilize Active Directory to obtain user information for your application. This saves administrators from having to maintain and update a separate user database in SQL or otherwise. Though this is an easy route to take to take while your network is small, it will become increasingly difficult to keep a separate user database as your user base grows.

Recently, I had to switch some existing web based applications from an SQL common user database onto active directory. To say the least, calls to the SQL user database were used liberally. Initially, I didn’t think anything of it, and simply switched the code in the data access layer of the application to get the info I wanted from AD instead of SQL queries.

In testing, the application proved to be very slow, taking literally minutes to load each page. I had to assume that the problem existed within the LDAP queries to AD. I started to do some research and read that the classes I had written using the System.DirectoryServices namespace (had to be compatible back to ASP.Net 2.0) were now available in ASP.Net 3.5 in the System.DirectoryServices.AccountManagement namespace. I decided to set out to see if these new classes would be more efficient than my own hand written ones. I do have to say one thing; the code is much easier, no more clunky strings with LDAP queries. Code that once looked like this:

Now looks like this:

Though not terribly impressive for getting a user by login name, the ease of getting groups is much more pronounced over the older DirectorySearcher methods. Makes me wish I didn’t spend all the time figuring out the LDAP queries for these things, though many were available via web searches.

In order to see if the queries were going to be more efficient, I took advantage of an existing test harness I had prepared for my old ASP.Net 2.0 AD classes. I wrote a few new methods using the AccountManagement namespace that would return comparable information, such as the two get user by login methods. One test harness compared the UserPrincipal, the other compared the GroupPrincipal. A summary of the tests are bulleted below.

• Test harness was utilized to analyze time taken for multiple calls to active directory.
• For loops were utilized with both 30 and 60 calls to AD.
• Difference was taken between the time before the for loop and after the for loop to quantify the total time for the loop to execute.
• Comparison of my classes to those of the System.DirectoryServices.AccountManagement which is built into ASP.Net 3.5 & 4.0

The results are detailed in the charts below.

• My classes are 42-46% faster for returning the User
• My classes are 20-22% slower for returning the Group
• Either way, access to AD is incredibly slow and expensive!

The result is that weather I use my classes or the new AccountManagement classes, getting info from AD is slow. Though I have searched, I have been unable to find exactly why the queries are so slow. Making a long story even longer, I decided to go with the AccountManagement classes for 2 reasons. One, I am lazy and hopefully Microsoft will make the underlying classes faster with coming releases of the framework. Two, the GroupPrincipal is much faster than my own methods for retrieving group info, and the majority of what I do is checking to see if a user is in a group. I only have to get the user once, but I have to go get group membership info more regularly.

A partial solution to the inefficiency of these queries is to get the majority of the information you need all at once, and store it in session state. It seems that it is more efficient to go get a ton of data from AD and stash it away somewhere than to repeatedly go get little tidbits of data. I typically create a session wrapper class to keep my session variables strongly typed, but that is for another blog entry.