Archives / 2004 / June
  • 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.


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



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


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


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


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


  • 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. ;)




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


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



  • Whidbey Object Test Bench

    The Whidbey May CTP documentation describes a new IDE feature called Object Test Bench. It sounds like this allows you to create instances of objects and poke at them in the design environment, without having to create a test project and write code. Looks neat, but either it isn't hooked up yet or I just can't figure out how to work it. Anybody know?

    I'm not entirely sure how much I'll end up using this feature, as I've grown accustomed to keeping code explorations in NUnit test suites that I refer back to when I need to. But it seems to be worth a look, anyway.