There's a bunch of intro articles on how to use the new Script Combining feature of the ScriptManager control that was upgraded in the .Net 3.5 SP1 package released this week. However, no one had a good article on how to figure out what the actual Microsoft-supplied, embedded Javascript file names were, so that you could put them in the CompositeScripts block.

Maybe soon someone will write a good tool for this? (Maybe someone has but I couldn't find it? I thought I saw an article once or a codeplex page or something that someone had, but I can't find it now anyway.)

In the meantime, I first used Firebug of course, to see the JS files as they were loaded by the browser on a particular page. Then, I opened up Reflector and looked in the DLL's resource section for the Javascript files that matched. Not too elegant, but it work for the AjaxControlToolkit files real well.

There also wasn't mention of this on most of those intro usage articles, but there are a couple of patterns for usage, IMO. Depending on which controls you drop on a particular page, some pages use more scripts then others. For my current web app, I set the most common scripts on a master page. But on individual script-heavy pages I added the required scripts individually. On regular pages with minimal script usage, I left them as is. Now, this means that on my script-heavy pages, my users will be re-downloading the bits that were in the master page-included script files, since it can only create on CompositeScript. (Feature request MS: Allow for multiple CompositeScripts per ScriptManager.) But not all of my users hit the report page for example, so why download all those bits that not be used this session anyway?

The next approach is to find every possible script you use and put them all in the master page. Your users will only have to download it once (you do have HTTP expires headers turned on, right?!), however, I don't like this method because the browser still has to parse the Javascript each page load. Slower machines (and browsers--*cough* all of them except Opera ;) would start to make that too slow, I guess. (I haven't benchmarked that yet though.) And the third method would be to include the exact, minimal required scripts on each page. However, then they'll be re-downloading bits all over your site (unless maybe its a commonly visited page). Of course, I have a preference, but each one of these patterns may be more useful depending on your application. Good luck.

I spent all afternoon trying to figure out why the new ASP.NET 3.5 DataPager control kept semi-resetting when using various links.

First, the previous/next links wouldn't work. It would always go to page 1 and page 2, respectively. This looked like classic ViewState problems even though both the ListView and the DataPager controls had ViewState enabled. (Which is a waste, but I'm so sick of the current client, I just wanted it done--we'll worry about performance later if they actually sell the product.) I wrote manual versions using TemplatePagerFields, but wasn't real excited about that. Then, I noticed that after using the ellipses (...) to go to another set of pages if there were so many results that there weren't enough page buttons, everything would work except when you then clicked on a page number link button. Then, it would show, for example if you clicked on the 3rd page number on this 2nd set of page number links, it would show the 4th page on the 1st set of page number links. So, it looked like the initial row index was getting reset.

I used Reflector, wrote an overridden version of NumericPagerField, and combed through the ASP.NET forums. Nothing really worked. The closest suggestion was to put a 2nd DataPager control before the ListView--not in any ListView template, even though you're supposed to be able too--and to make it invisible. However, that still didn't work.

But, I did try using my original DataPager and just pulling it out of the ListView template. Finally that seemed to fix everything. It even fixed the previous/next buttons being weird (which really was the same issue).

I still don't know why you have to do this, even after all my searching through the .Net framework code and forums. Not to mention that you still have to handle the ListView PageProperitesChanging event and manually call DataPager.SetPageProperties with the event parameters. A good idea for a control that just isn't ready, IMO.