In my last post, I made a reference to my taskbar so I thought I'd write a bit about it. Here it is (click for a larger image):

There are a couple of things I like about this setup that others may not know. Firstly are the Administrative Tools, Control Panel, and Desktop menus in the bottom right. If you right-click the taskbar and select Toolbars, you'll see a list of toolbars you can add. If the one you want isn't there (e.g. Administrative Tools), click New Toolbar... and browse to it. I put a lot of stuff on my Desktop so I love having it available without having to minimize everything.

This is also handy at some client sites if you are constantly using Remote Desktop to get to various servers in different environments. In this case, I'll create a folder (called, say, Remote Connections), then place an .rdp file in it for each server. Add a toolbar for that folder in the taskbar and voila! Remote desktop access to any server in two clicks. I also had a toolbar for my Links folder at one point, too, but I didn't go to it often enough to justify the real estate. But if you do, that's another good candidate toolbar.

The other nice thing is the address bar embedded in my taskbar. This lets me type in my URL without having to open my browser first. It will open your default browser, too, so it works for Firefox. I also use the TweakUI power toy which allows me to create keywords for sites I search regularly like Google, MSDN, and IMDb. So I can click in the address bar, type: “imdb glengarry glen ross” (without quotes) and have the results show up in my browser without having to open it explicitly. NOTE: You'll probably want to uncheck the “Reuse windows for launching shortcuts” option in the Advanced properties of Internet options if you decide to do this yourself.

Of course, this is kind of moot if you already use WinKeys or SlickRun to their full potential but it has the advantage of having your URL history available at the click of a button.

I believe I have some goodness happening finally but first, I want to clarify something from my last point. And zeroth, I want to plug www.calgarycodecamp.com, mostly because I'm presenting at it.

My second complaint was a little vague and upon reflection, not a fair annoyance. What I can do in ASP.NET 1.1 is launch my web app in IE while the project is open in Visual Studio 2003. Which, of course, you can do in version 2005. But when I press F5 in Visual Studio 2003, it will launch whatever the start page is for the app but the debugging process also attaches to my existing instance of IE. This means that I can refresh my existing IE page and if there is a breakpoint on it in VS, it will be hit. I like this because 80% - 90% of the time I don't need breakpoints so I work normally in IE. But when I DO need them, I don't need to change my start page. I can just set a breakpoint, press F5, then refresh my existing IE instance.

In Visual Studio 2005, web projects, by default, launch in their own little web server that I think gets created the first time you launch. The web server uses some random (and I assume open) port on your machine and I remember reading somewhere that you could specify the port used for the web server but I haven't got around to looking into that. So my whiny little complaint was that I can't have the app open in IE on localhost and have the debugger attach to it because Visual Studio will launch the app on a different port on its own web server.

If you haven't figured out why this is a stupid, petty thing to bitch out, here's why: If I have the app open in IE, then obviously I've created a virtual directory for it in IIS. So why not just have Visual Studio open the URL in the default web server instead of its custom server? It's moments like these that make me wish my pappy didn't marry Aunt Bobbi-Sue.

As for my SQL problems, they've gone away, too. How? By scrapping SQL Server Express and installing the Developer Edition of SQL Server. I spent last night having one more kick at the Express cat and I just couldn't connect to the database in more than one app at a time. When I loaded it in IE, I had to disconnect in Visual Studio. When I loaded it in Visual Studio, I had to disconnect from it in Management Studio.

So as I regale you with this story, my machine is currently and concurrently connected to my database in three different ways. Not only that, my Profiler is back! Maybe later I'll tell you how much fun it was to debug a grid that returned absolutely nothing without using SQL Profiler.

So hopefully, I'll finally be able to get more technical in this virtual hootenany in the coming days. 'Cause I gots lots to say about this Atlas thingamabob.

So I've been developing in ASP.NET 2.0 and SQL Server Express and I'm happy with them in general. Some of the changes are a little jarring, though. To the point where they're starting to hinder my progress enough to waste time complaining about them:

Firstly, is the idea of web sites being a different type of project. I.E. There's no .csproj file. I read about why they did this and promptly forgot because frankly, I don't care. What I do care about is the fact that when I download code samples, there isn't anything I can double-click to open it in VS 2005. Yes, I can open VS 2005 and select Open Web Site... You can also click File | Close to close most of your apps but when was the last time you did that? What if you were forced to?

*UPDATE* Thanks to www.hanselminutes.com for pointing me to this little number to fix this annoyance. Some great-looking additions, too. Like the ability to create a virtual directory from within VS2005 and publishing to an FTP server.

Secondly is the method of debugging. I like that you don't have to create a website in IIS for every web project you're working on. But here's my problem with that: I don't generally run web apps through VS 2005. My method of debugging is old school. I open the project in Visual Studio and I open the site in IE. I make changes in Visual Studio, recompile, refresh the page in IE, and repeat. Takes too long to start the formal debugging process in VS just because I have a typo in a property somewhere.

If I do need to debug with breakpoints, I usually have a benign starting page that loads quickly. I hit F5 until that page loads and I now have the benefit of having the debugger attached to my IE processes. I can now go back to my real IE instance and refresh the page to hit the breakpoints.

This isn't possible without doing things the .NET 1.1 way and creating an IIS site for my apps in progress. I believe, but have not verified, that I could get around this by starting the app from VS 2005 once which will create the web server port I need for that session. I also believe this port will go away when I close Visual Studio. Again, a workaround that slows me down.

Related to this is my final beef. I'm constantly getting “cannot open user default database” errors. Not when I start the project from VS 2005 but almost always when I load the site up directly in IE. The error goes away if I disconnect the database in VS 2005 but that is NOT a workaround I'm willing to put up with. As far as I can tell, the same thing happens whether you work with the database in VS or in SQL Management Studio. For now, I'm able to things going by using a SQL login in my connection string. Again, not the ideal situation but at least I can go back to work.

If anyone has details on any of these issues, don't be shy.

So thanks to exactly none of you for filling me in on the SQL Server 2005 connection pooling thing. I hate having to look up stuff myself...

Just a couple of tidbits today. I've started getting into podcasts of late now that it's dawned on me that I have some unused downtime to and from work every day. Still listening to the http://plumbersatwork.com/ who have released another overdue but entertaining entry. And on their suggestion, I've added Scott Hanselman and .NET Rocks to my list. The .NET Rocks ones are decent enough but could use less product placement and more editting. In the one on test driven development, I think it was at least ten minutes before Jean Paul Boodhoo, the guest speaker, even said hello. Hanselman, on the other hand, is the type of guy I'd like to stick a microphone in front of and just say, “Go!”

But lest we forget there is non-.NET technology out there, I can now add OpenText Livelink to my resume thanks to my current contract. But methinks it won't happen unless I go at least six months without finding other work. That development environment...hoo boy! Found three bugs in their product in my first two weeks. But credit is due for providing access to the source code, even if it's in their own archaic little language. At least I was able to provide the specific line numbers where the errors were occurring when I reported them. (And as a general rule, being able to add properties to a data structure at random without first declaring them is good only if you have the utmost faith in your team's ability to spell.)

Finally, work begins on building a software consulting practice in the Bahamas. So if you're in the Bahamian area and are looking to build some software, there's a new game in town.

Finally starting to look at .NET 2.0 (unless you are a potential employer in which case, I've been working with it for weeks, nay months). And like many people, my first victim is a pet project. I'm converting an app I wrote for my brothers in a weekend over five years ago to get them off my back. You know the kind. I was a young ASP punk with an attitude and I was into AJAX (of course, back then the technology didn't share a name with a household cleaner). And so, consequences be damned, I wrote it using XSL, the XML DOM, javascript, and ADO's XML schema not knowing just how dependent my brothers would become on the app.

Back on topic: part of the app is a search screen that displays results in a grid. Perfect chance to check out the GridView. And it is at this point that I stumbled across ScottGu's blog. Specifically, his example on paging a GridView.

This example is pure gold. Not only does it explain how to page a GridView, it does so using Atlas. And using the ROW_NUMBER( ) feature in SQL Server 2005, a feature I had never heard of. And it uses Atlas to essentially mimic Google Suggest functionality. And it shows how to reference the Atlas library. And it binds the GridView to an object data source. And it uses Master files. And that's just what I've seen after a fifteen minute scan. Jayzus knows what other goodness lies within.

Finally caught up with the podcasts by the Plumbers @ Work. It's the only podcast I've listened to so far (where do people find the time to listen to these things en masse?) and it's great. On their website, they list all the links referenced in their ramblings which is some sort of minor genius because after listening to them, you have some context around the links and you can follow-up on the ones that sounded interesting. Much better than having some random list of URLs next to your posts.

My only minor beef: not enough disagreement in the group. C'mon guys! Windows Live can't be all that great. What do you REALLY want to say? I perked up when Bil started in on IE7 but he backed off before the slag alarm went off at Master Gates's Manor. Good to know it won't work with SharePoint though (yet).

Incidentally, I tried Live for about four-and-a-half minutes total. And I spent four of those minutes swearing at the computer because it would freeze whenever I tried to do anything with the weather gadget.

All right, I'm tired of spewing knowledge (or whatever it is I spew). I've heard rumours of a feature in SQL 2005 that might interest me and I'm in no mood to look up the details.

I was recently involved in a discussion where someone wanted to connect to a database from a web service. In it, he wanted to use impersonation (for obvious reasons) but also connection pooling (for obvious reasons). Essentially, the requirement was to use the user's credentials for everything within the web service except database actions where he would switch to a single user to allow for connection pooling. Yes, it's possible with a SQL user but we don't want to do it the easy way, do we? We've always been told SQL Authentication is bad (even though we use it anyway for demos and prototypes and never get around to changing it in production).

Anyway, I don't care about the solution to this problem. We drilled the use of the LogOnUser API. We talked about trade-offs 'twixt connection pooling and security measures. We discussed scaling in more detail than a Head & Shoulders commercial. In short, I don't care if you have a clever solution.

What I am interested in is this new-fangled (and, to me, unconfirmed) feature thingy in SQL 2005. Apparently, there is a way to use the following scenario:

1. User authenticates to web application/service
2. Web app/service connects to SQL using a single pre-defined Windows account
3. Web app/service passes user's security context to SQL
4. SQL impersonates authenticated user for all database actions

This is some kind of wackiness, it is. So, my loyal and, I pray, giving readers. Is this possible? The Coding Hillbilly wishes enlightenment.

In a previous post, I suggested setting up several portals on a server for developers to monkey around with while building their web parts. One of the challenges I came across recently is how to copy one portal to another. I was going to add "easily" to that sentence but when I'm done pontificating here, you'll consider yourself lucky that it's possible at all, let alone "easily".

First, the scenario. This is a full-blown SharePoint Portal Server portal, not a WSS site. It contains a few subwebs, some WSS sites, and more than a few collaboration sites. There isn't a whole lot other than that. No personalization. Very little customization. More than our share of web parts on the portal itself but the WSS sites and collaboration sites were pretty much out of the box.

Before I start, I won't be describing how I eventually did copy the portal yet. I think it's important to understand what I did try so that you people looking for shortcuts don't mess things up the way I did. But I promise, I'll get to it.

Our initial idea was to copy the portal as it exists in production to one of the developer sites, then copy that one to the other four we had set up on the same server. Our first stop: the SharePoint Backup and Restore utility. The drawback: The utility doesn't work if the portal to which you are restoring resides anywhere other than port 80. It just doesn't appear as an option when you are restoring.

So why not create the portal on port 80, restore it, then change the port? Good call. A downside to that is that when you display your list of portals in the Admin tool, it will ALWAYS display as the initial URL you used to create it, even if you change the URL (e.g. by changing the port to something other than 80) later. So in our scenario, we would create one portal on port 80, restore it, then change the port. Then create another portal on 80, restore it, then change the port. The net result is that when we displayed our list of portals, it would show five identical portals, even though when you clicked on them, they would go to different places.

Cosmetics, you say? OK, try this one. You can't restore the same backup to more than one portal on the same server. The utility shows some message like "this portal has already been restored on this server" or some such nonsense.

Never tried the spsbackup command-line utility (or spbackup, can't remember what it's called and now that I think about it, I'm pretty sure both exist although they do different things). If that overcomes these problems, spill your guts.

So at this point, we had a functioning, albeit improperly named portal. Seemed to work at first glance so I set about figuring out a way to copy it to the other portals on the server (since the restore utility wasn't going to help us).

My next test: backup and restore the three databases associated with the working portal and try to do a restore on those databases for the second. No such luck. I think the error was "Error Code 0xEE00FC0: You weren't expecting it to be THAT easy, were you?"

So I looked into SMIGRATE and STSADM as possible solutions. It seemed, though, that they'd only work on WSS sites, not on portals. Still, that "backup" option on STSADM was too tempting to pass up...

I ran STSADM -o backup on one of the WSS sites first and did the subsequent STSADM -o restore on the second portal. Worked like a charm. Tried a second site. Again, no errors! Time to get cocky: STSADM -o backup -url http://myrootportal -filename inyourface.stp -overwrite. Glorious! The file was created and it looked like it might have some data on it. How much harm could I do trying to restore it on to the second portal....

I don't recall the error and I'm risking tremendous psychological damage even relating this part to you. Not only did it not work, it left the portal in some kind of mutant stage where sometimes it would appear as a WSS site, sometimes as a portal, but usually as a hideous mutation not unlike the one seen in either version of The Fly. Seriously, the portal was completely trashed. Couldn't edit its properties, couldn't view it, couldn't even delete it. It was like a tick in the middle of your back. You can tell its there and that it's sucking the life force from you, but nothing short of a bath in molten lava is going to get rid of it.

Casualties were surprisingly low. We were lucky in that the server had just been freshly minted and could be wiped clean and re-built without too much hassle. The network admin promptly went into a coma when he was finished but I'm sure he'll come out of it soon.

Final note: I used words like "will" and "doesn't" a lot in this post. What I really mean, though, is "appears to" and "it would seem that you can't". What I mean is: Don't take any of this as gospel. It's my experience in a technology that Bil Simser accurately describes as "a hydra with heads growing out of places you wouldn't believe". But by the same token, I couldn't find answers for what I was doing on my local haunts so if I can help someone else out, well, it still won't have been worth it....