Kevin Dente's Blog

The Blip in the Noise

June 2004 - Posts

SSE, Visual Studio, and XCOPY deployment

The VSData team blogs about new database features with SQL Server Express and Visual Studio 2005. Apparently when an SSE database is added to the VS project and the project is built, the MDF gets copied to the build directory along with the EXE. When the application runs, the framework automatically finds the MDF in the application directory.

This sounds great for quick and dirty development. But is it really what you want when building a real application? If the application is installed into the Program Files directory, non-admin users won't be able to edit an MDF in the application directory (I'm assuming that the MDF doesn't just hold static data here). Aren't applications supposed to use the “Application Data” or “My Documents” folders for this kind of information? Is it just as easy to deploy the MDF to an AppData directory and have the framework automatically find it there? Do VS installer projects know how to automatically deploy MDFs to an AppData folder?

I haven't installed SSE/VSb1 yet to try it for myself. But right now this isn't sounding like a “pit of success” feature.

Posted Tuesday, June 29, 2004 10:27 PM by kevindente | 6 comment(s)

Unit testing in Visual Studio 2005

A couple of weeks ago there was quite a bit of discussion about adding unit testing support to all versions of Visual Studio 2005. OK, so I'm late to this party, but here's my 2 cents.

I think Jamie Cansdale nailed it when he said the unit testing should be part of the BCL, not just Visual Studio. If you buy in to test driven development (as I do), then unit testing is a core part of your development process. With the .NET framework SDK, Microsoft has touted the ability to write .NET code without an expensive IDE (call it Notepad Driven Development if you must - plays on TDD seem to be all the rage right now).  If unit testing is a core part of that development, wouldn't it be natural to put a simple unit testing framework in the BCL and the .NET SDK? After all, according to TDD'ers, there can be no development without unit tests. Include a simple (even console mode) unit test runner in the SDK, and NDD/TDD lives.

The response to all of this from Microsoft seems to be a combination of “the benefits of Team System is the integration and reporting” and “hey, we need to make money selling products here”. The way I see it, including unit tesing in the BCL and Visual Studio would actually help sell Team System. Why? Because the more people are unit testing, the more value Team System adds. People won't buy Team System to get unit testing - they don't need to. But once they have their test suites, Team System, with its checkin policies, change management, reporting, etc adds even more incremental value. In other words, include unit testing in VS2005 to up-sell developers to Team System.


Posted Monday, June 21, 2004 11:29 PM by kevindente | with no comments

Generics and CLS Compliance

Dan Fernandez blogs a reminder that generics are not CLS compliant in the .NET Framework 2.0. Apparently to make them so would put too large an onus on CLS language developers. This news worried me back when I first heard it, and it still worries me. It worries me on two fronts. As a component developer, it forces me to make some decisions when designing my APIs. Let's say I have an API that could take advantage of generics to make it more extensible or elegant. So do I

  • Go whole hog and use generics, knowing that I'm preventing COBOL.NET or whatever languages don't support generics from calling the API. Given the fact that C#, VB.NET, C++ and J# probably represents 98% of the .NET code being written, maybe thats just fine. Of course, the moment I do this I'm virtually guaranteed to have some huge client will insist on support for Scheme.NET (or whatever).
  • Don't use generics, knowing that the API will be compatible with the greatest number of languages. In this case, generics do me and my customers no good.
  • Provide dual APIs or alternate methods, one using generics, the other not. Yucko. Anybody remember the days of Powerbuilder's half-assed COM support? Our COM APIs are still littered with hacks that provide alternate versions of methods to support partially compliant programming environments. I'd rather not go there again.

Frankly, none of these options are all that appealing.

On the second front, as a user of the .NET framework class library, I worry that the BCL developers are facing the same choices. What will they do? Will the .NET framework team be restrained from using generics to provide least common denomenator support (I haven't looked through the 2.0 framework enough to figure out the answer to this yet)? Will 3rd party control and component vendors?

I wish that at least support for consumption of generics was required for CLS compliance. Then I wouldn't have to make these decisions.

Posted Monday, June 21, 2004 10:07 PM by kevindente | 2 comment(s)

Running Assembly Reflector Add-in

Like most .NET developers, I use (and am eternally grateful for) Reflector for .NET. Aside from Visual Studio .NET and NUnit, it's the most used tool in my development arsenal.

Something that I do fairly frequently is run a web or windows application, and then decide that I want to Reflector it (yes, Reflector has become a verb in my vocabulary). That means that I need to figure out where the application is running (which isn't always easy), and navigate there in Reflector's open file dialog. After the umpteenth time doing this, I decided to automate the process. Fortunately, Reflector has a fantastic extensibility model, so I was able to scrape together an add-in to do just this.

The add-in adds a new menu to the Tools menu called “Open Running Assembly“. Select it and the add-in displays a dialog that displays a list of managed processes running on the system. You can select the process, or any managed assembly loaded in that process, and the selections get loaded up into Reflector.

It's still pretty rough (call it version .5), but usable enough that I decided to post it. If you're interested in trying it, you can download it from here. Just unzip it into the Reflector directory and add it to Reflector's add-in list.

Update - it seems that people are being directed to the .5 version (described in this post) rather than the newer .6 version described in a subsequent posting. I've updated the link here to point to the newer version.


Posted Sunday, June 20, 2004 3:49 PM by kevindente | 14 comment(s)

DataTips in VS 2005

Jim Gries blogs about the enhanced Datatips in Visual Studio 2005 (damn it's hard to stop saying Visual Studio .NET). Somehow this improvement had escaped my attention previously. All I can say is - wow, wicked cool. Even his screen shot doesn't do the feature justice - this is one of the coolest debugger enhancements I've seen in a very long time. I use QuickWatch a ton, and I can easily see this replacing QuickWatch for 90% of my debugging needs. It definitely gives visualizers a run for their money as the coolest debugging enhancement in VS2005.

Posted Monday, June 7, 2004 10:25 PM by kevindente | with no comments

Audio editing - the Audacity of it all
This weekend I had the need to do some very basic audio editing. I had no software for doing this, but a quick Google turned up Audacity, an open source audio editing package. It let me do everything I needed to do, and is quite easy to use. Recommended.

Posted Sunday, June 6, 2004 3:51 PM by kevindente | with no comments

Windows XP flakiness - solved

About 8 months ago, I got a snazzy new development machine at work. From the get-go, I had a peculiar problem – when I opened a bunch of Internet Explorer windows, my machine started going wonky. Actually, the problem wasn’t caused just by IE, but it seemed like IE triggered it more readily. The issue manifested itself as a progression of increasingly worsening UI problems. The first sign of trouble is that the IE toolbars would rearrange themselves. Specifically, the Links toolbar would move from the bottom of the toolbar stack (where I like it) back to the default location (collapsed, to the right of the address bar). If I kept opening windows, the problem would progress to where new IE windows would display without a menu bar, or would sometimes hang and would need to be killed. If I (foolishly) kept opening windows, things really went haywire. Windows became incapable of popping up any new windows. Context menus wouldn’t display, the Start Menu wouldn’t pop up, grouped start menu items couldn’t be selected, etc. Closing open windows would usually restore the system to some semblance of usability, but I usually ended up rebooting at some point, if only for my peace of mind. Needless to say, this was very frustrating.

Maybe this would all be understandable if I were trying to open 200 IE windows, but I would see it trying to open as few as 10, depending on how many other apps I was running at the time. On a machine with 1GB of memory, this is a pretty absurd limitation. I suspected some sort of resource leak – perhaps some app was exhausting GDI resources. Now, IE does chew up a lot of GDI resources, but according to Task Manager it wasn’t completely out of control. I thought maybe the video driver was the problem, but upgrading to newer versions didn’t help. I even burned down and rebuilt the machine, but still had the problem.

Finally, during my umpteenth round of Googling, I ran across a thread that described a problem very similar to my own. One of the responses in the thread mentions a registry setting that increases the size of the desktop heap. According to a somewhat dated but still relevant MS KB article, “this static value is used to prevent ill- behaved applications from consuming too many resources”. Well, apparently it IE meets the “ill-behaved” criteria, because it seemed to cause Windows to bump into this limit, and Windows wasn’t handling it very gracefully. Anyway, to make a long story longer, when I bumped up the desktop heap size (from its default of 3MB up to 8MB), bingo, all of the problems magically disappeared. Whew, what a relief.

To make this change, navigate regedit to HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\SubSystems. The “Windows” value contains a big honkin’ string, and one part of it is “SharedSection=xxxx,yyyy,zzzz”. The second number (yyyy) is the one that you want to increase. Standard registry editing disclaimers apply, YMMV.

Posted Friday, June 4, 2004 2:51 AM by kevindente | 60 comment(s)

Whidbey Unit Testing Generated Code - yikes

I was just poking around in some of the code that the Whidbey Unit Testing framework generates, and was shocked at what I saw:

public Form1Accessor(object target) {
        m_privateObject = new Microsoft.VisualStudio.QualityTools.UnitTesting.Framework.PrivateObject(target);

Huh? “m_”? Hungarian? Methinks Rory will be most displeased. ;)



Posted Thursday, June 3, 2004 5:38 PM by kevindente | 1 comment(s)

VSTS Unit Testing

James Newkirk blogs a Hello World unit test sample for Visual Studio Team System. I'm guessing it's no accident that the test code looks a lot like NUnit test code - making it easy to migrate unit tests from NUnit to VSTS makes a lot of sense. However, if I had my druthers, I'd change one thing. I've never liked the fact that the comparison Assert methods (e.g. Assert.AreEqual) take the expected value as the first argument and the actual value as the second. That just feels backward to me. Assert.AreEqual(9, theValue) reads to me like “if (9 == theValue)”. I just don't think that way, and I frequently find myself reversing the parameters inadvertantly. Unfortunately, that change would complicate the migration from NUnit to VSTS, and so probably isn't feasable.

One thing that I hope does carry over from NUnit is the convention that methods that start with the word Test are automatically flagged as test methods (I haven't found documentation about this either way). I like that behavior because it's one less thing to forget - and accidentally leaving off the TestMethod attribute is easy to do, hard to spot, and very impactful. Expansions may help here.

Posted Wednesday, June 2, 2004 8:58 PM by kevindente | with no comments

More Whidbey Help comments

A couple more cool Whidbey Help System features that I just ran across:

  • Help favorites are no longer just IE favorites, mixed in with your regular IE favorites. THANK GOODNESS. I've always hated that - maybe I'll start using help favorites again. Folders/subgroupings would make it even more useful
  • It looks like the help system will support saved searches, which is very cool. I haven't found a way to actually create a saved search yet, but some day...


Posted Wednesday, June 2, 2004 6:45 PM by kevindente | 3 comment(s)

More Posts Next page »