Jeff Makes Software

Let me say that Visual Studio 2005 is a huge step forward in a lot of ways, especially for Web developers. What still sucks though is database handling quirks.

For example, I just want to open a query window against a SQLEXPRESS database in my Web project and fire off some SQL. You know, the way we did in the old days. I want to create a table from SQL commands, and it tells me, "The CREATE TABLE SQL construct or statement is not supported." Then below that is says the query can't be represented graphically in the diagram and criteria plane. Well no shit, that's why I turned it off.

So then I figured I'd fire up SQL Management Studio and just attach to the database. Yeah right. I try to attach to the file, and the file dialog doesn't let you type in a path, and won't navigate beyond the user name in the Docs/Settings folder (I happen to have the project on a desktop folder).

I eventually went back to the VS IDE and did a mass check-out from source control, and suddenly the table create query runs. That's not surprising since the database is probably read-only while checked-in, but why didn't VS tell me that instead of telling me CREATE TABLE isn't supported?

Nothing annoys me more than fighting the tools for ridiculous amounts of time to do simple things. And that's the way it always is with Microsoft tools. Usually 95% of what you do is powerful and easy, but then you lose all of that saved time with dumb shit like this.

Perhaps there's some easier way with VSTS's testing, but because I know not everyone has that, I'm trying to write unit tests for the programmatic manipulation of web.config data.

So on one hand, you've got...

System.Configuration.Configuration config = System.Web.Configuration.WebConfigurationManager.
   OpenWebConfiguration(HttpRuntime.AppDomainAppVirtualPath);

in your configuration editing junk. Works like a champ when you call Save() on that object. The problem is that HttpRuntime.AppDomainAppVirtualPath has no value in a unit test. The weird thing though is that you can call the above code from the test and call it's Save() and it throws no errors. It sure thinks it's saving some config data somewhere, but I can't figure out where.

I know I'm being nutty here, but I really want to be able to test this stuff. Any suggestions?

EDIT: Actually, the test is manipulating web.config in the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG folder. That's odd.

My publisher tells me that, despite a lot of good press and strong reviews, my book hasn't sold particularly well.

We have an internal CS blog here at my current gig. You get this when you comment:

"However, due to caching and moderation, it may not be displayed right away."

Am I the only one troubled by this as being generally bad form? In techie circles, sure, whatever, I can deal with that, but would John Q. Pornsurfer care about the technical implementation? And even if they did, why wouldn't the update cache-bust the data anyway?

Maybe one of the Telligent folks can explain the thinking on this.

I would think that blasting through Google I could find an answer to this, but I'm not finding anything useful at all. How does one unit test an HttpModule? I can't imagine that it's not possible. I'm not sure how to fire off and test the various events or simulate the request/response lifecycle.

As you'll see in this post from Scott, app restarts now occur whenever you add or delete a folder. That's bad news. I know of at least one application that I've written that has to add or remove folders from time to time.

We should be able to turn this off. It seems like an arbitrary and not well thought out change.

So if you're scratching your head and wondering what AJAX and Atlas has to do with you, I'm curious to know what it is that you feel you need to learn. There are no wrong answers.

Even though I develop software on Microsoft's platform, I'm still astounded at some of the stupid things they do. Now they're saying that you can't use your Windows license on a new motherboard when you upgrade.