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....

Time to make this thing interactive. I have a moderately strong opinion on something and need to know the performance ramifications.

The topic is SQL. Sub-topic: inner joins. Very, VERY often, I will see SQL such as:

This is, of course, valid SQL. And I hate it. Here is how I would write it:

Both will return the same results but I like the second much better. The reason is thus: the filter is blatantly obvious. In most cases, I know the inner joins will be for stupid little tables that were included for the sake of normalcy and I can ignore them. I don't want to sift through all that crap in my where clause just to find out what data I really want. This way, I can quickly see where my data is coming from (i.e. the inner joins) and how it is filtered (i.e. the where clause). It's not all munged together for the sake of saving a few keystrokes.

This is especially true for complicated procedures and ones that involve outer joins. I never remember what direction += goes and it's not an easy thing to search for. Enter += into Google (or better yet, Google Groups) and see for yourself.

Here's where the interactive part comes in. Which one performs better? Note that in most cases, I'll go with the second one anyway because I don't think the performance is that much different as to make a noticeable difference either way. And I do prefer maintainable code over more-performant-than-anyone-will-notice code. But if I'm ever doing work on Amazon's database, I'd like to justify my astronomical rate.

So don't be shy. I'll be judging answers based on clarity of thought, support for my position, and potential clients.

The Coding Hillbilly has been through some trials and tribulations of late in the SharePoint world and wishes to turn his misfortune into fortune by increasing his page hits for potential profit. (Oh, don't look so shocked. I gots childun to feed.)

First up is the SharePoint development environment. As in, how should you set one up? That one's easy. Bil Simser's already described my ideal way. You set up a virtual machine on your computer with everything you need and have at 'er. But individual virtual machines are not always an option so if you're up for reading about second best in my world, let's chat.

The basic idea is that there is a central SharePoint server with several portals on it, preferably one per developer so that they aren't stepping on each others' toes. You can use the same host header for each portal but change the port numbers. This has caused some issues for when I needed to run the SharePoint Restore utility on it but it's usually easier than trying to rip a new host header out of the Grand Poobah of the DNS in your organization.

You create the portals like you would any other but I'll suggest not including developer names in the names of the portals. Developers come and go and you never know if Billy Bob isn't quite stable enough mentally to handle working on a portal called Bobby Jo's Moonshine Portal after Bobby Jo gets arrested for shirking his child support duties. I generally use the same name and add the port number to the end.

Once you have created your portals, assign a developer to each one and they can go about their business pretty much in the manner described in almost every book or article I've read about developing on SharePoint. I do have one suggested deviation, though.

Usually, the documentation says you should configure Visual Studio to compile the project to the server where the assemblies reside. I'm not a fan of this because I usually have references to at least half a dozen assemblies that never change and I'm sick of waiting the extra 2.6 seconds for them to copy over when I do a full re-build. So instead, I leave it set to compile to Debug\bin and set up post-build events on the projects that actually do change. The events are pretty simple: copy MyWebPart.dll Z:\bin (assuming, of course, Z: is mapped to your particular portal's location). One advantage to this is that each developer can map his or her Z: drive to a separate portal and the build event doesn't need to change.

Another suggestion: you'll probably want a separate portal to act as the main holding cell for the latest version of the entire project. It's essentially a build server.

There is a potential disadvantage to this if SQL Server is not on the same server: Going back to square one isn't as easy as restoring a virtual machine's snapshot. Theoretically, you could take an image of the server and a backup of the config database and all the portal databases and restore them all if the worst happens. You could also theoretically restore only the three databases associated with a single portal if only one portal has failed. You could also theoretically go backwards in time to the point where you screwed up your portal which, from my own experience with SharePoint, would have a higher probability of success.

So a lot of jawin' just to say "create one portal for each developer" but it's a setup to a post hopefully in the near future where I talk about how to copy the contents of one portal to another on the same server. Hint: I've seen more automation in cave drawings.