I started using VSTS Database Edition back when it was called Data Dude and available as a CTP download. Since then I have slowly embraced all its features and I now use it as my complete database development solution from schema management, to data generation, and finally deployment.

DB Edition has its quirks but you learn to understand them and work with them and each new version has new features to improve the workflow. However, as I have been using DB Edition each day, an idea has been steadily stewing in my head for where I'd like to see DB Edition go next. My thought process in a nut-shell follows...

A Database Project allows you to define your schema and data generation and, from a Visual Studio context menu, deploy the database to a chosen server as a new database or as an upgrade to an existing database. You can also use the DatabaseTestService in a test project to deploy the database and test data for automated testing. And finally you can use the SqlDeploy MSBuild task to deploy the database as part of a continuous integration build.

However, all of these methods of deployment require the relative path to the Database Project and all its SQL scripts and some settings in a configuration file. This causes problems in deployed test runs and Team Build test runs where the relative path to Database Project often changes. It also restricts using multiple test databases in a single test project due to the way the configuration file works.

I propose that, at build time, DB Edition could package into a .NET assembly, the full definition of the Database Project along with some standard bootstrap code but minus the deployment configuration. Test projects could then include a reference to the DB assembly and make calls into the bootstrap code, perhaps something in the form:

MyDBAssembly.Schema.DeployTo(someConnectionString, someOptions);
MyDBAssembly.SomeDataGenPlan.DeployTo(someConnectionString);

The DB assembly will be treated as a dependency like any other references would and will naturally be moved around wherever the primary assembly gets deployed and all the necessary information will always be available to perform a completely new database deployment or to perform a schema upgrade on any compatible existing database instance.

If the DB assembly happened to double as a console application, it could be used for ad hoc command-line deployments or even included in batch, MSBuild, or PowerShell scripts for automated deployments.

I am contemplating several ways to hack a feature like this into DB Edition myself but I'm hoping someone else has already done it or maybe the DB Edition team already has it on the cards for Rosario.

Almost two months ago, at the February Adelaide Geek Dinner, I was expressing my frustration at one of my Visual Studio solutions taking too long to build and how I would like Visual Studio to build using multiple processors just like the new MSBuild /m parameter.

Paul Stovell made the comment that even with the improvement that multi-core builds was giving me, my solution really shouldn't be taking that long to build. Given that Paul wasn't familiar with my particular project layout and I naturally didn't have a copy with me, the conversation quickly went onto other topics.

However, Paul's comment stayed with me for days after, bugging me every time I waited for the latest build to complete. Then, while staring at the VS Output window during a build, I noticed that most of the time seemed to be spent running FxCop on each project.

I decided to rebuild the solution but this time disabling code analysis via the appropriate build switch. I watched the build time drop from 40 seconds to just 10 seconds by skipping the FxCop process.

Excellent! But given that our entire team runs with Option Strict On, Treat Warnings As Errors, and the Code Analysis Check-in Policy, how could I possibly revert to such a lax build process for the sake of decreased build time?

The answer is to disable Code Analysis in each project's settings (and unfortunately the check-in policy too) but leave it enabled in the Team Build script so it runs and gets reported via the continuous integration build that runs after each check-in. Luckily we've also been running with FxCop for so long that we tend to avoid writing code that would cause violations in the first place.

I met with Paul over the weekend and mentioned my success with better build times. When I told him I had been running FxCop with every build, he just laughed, amazed.

The nature of the software development profession is such that you need to be constantly learning new techniques and improving your style. A side-effect of always seeking to be better is that when you revisit old code it suddenly doesn't seem as good as it did when you first wrote it.

I was revisiting a large class recently and was struggling to navigate between all the methods to follow the logic. I decided to make use of #region blocks (something I rarely do) to help group related methods together and hide less relevant code from view.

By arranging groups of methods together by their purpose, a pattern started to emerge. Each region started to look like an ideal candidate to refactor the code into a new class with a single responsibility. I already had a set of unit tests in place for the existing code so I felt confident in being able to refactor and being able to verify I hadn't broken anything afterward.

What was originally one class became eight, resulting in greater maintainability, testability, and of course readability, solving my original problem. For this class the refactoring by region worked well because I had grouped code by it's behaviour and partly by it's call chain.

However, I've seen other approaches to using #region blocks. I've seen all event handlers put in their own region. I've seen collections of overloaded methods grouped by name. I've even seen properties grouped together, method/subs group together, and functions grouped together. In these arrangements not only does a refactoring pattern not automatically emerge but it becomes harder to search for one.

As I mentioned above, I'm not a big user of #regions. This is probably because I try to refactor my code before it gets big enough and because of the region anti-patterns I've wrestled with. I think I might have to give them a second chance.

I installed VS2008 Beta 2 on a spare machine on the weekend and I am beginning to use it for development. Today I waded through the Tools, Options dialog setting up the IDE with a few sensible defaults. Several default values have changed since VS2005 and for the better. Unfortunately two settings are still outdated.

VB still defaults Option Strict to Off whilst Option Explicit and the new Option Infer are On. They should all be on by default.

Also, when the new range of Microsoft fonts were released for Vista and Office, an update for VS2005 was released to use the new Consolas type in the IDE. VS2008 still defaults to the non-ClearType Courier New though.

Aside from those two issues so far, I'm loving the new Visual Studio.

I have recently setup a TFS Team Build server for our work projects after realising that the secondary reference issue is not as problematic as first thought. We haven't been using Visual Studio's Remove Unused Reference feature as much as expected and we need to prepare our projects for Visual Studio 2008.

With a build server configured to perform automatic builds every night we are on our way to full continuous integration with builds on check-in. However, there are several other differences between Visual Studio and MSBuild that are creating slight issues for our TFS build agent.

For what I understand of the situation, Visual Studio utilises an in-process variation of the MSBuild engine to support specific features like background compilation but has failed to maintain full compatibility.

For example, installation of SQL Server 2005 on your development machine will offer four new Business Intelligence project types: Analysis Services, Integration Services, Report Server, and Report Model. None of these project types will build from the command line in MSBuild or therefore Team Build. We have had to move these project into separate solutions that we exclude from the build server's automated processing.

Also, strongly-typed DataSets and other designer-based project items are usually based on a metadata file (like an XSD) and use a custom tool to generate an appropriate VB or C# code file before the project is compiled. The project files contain the information about which generator tool to use to update the code files from the metadata but again MSBuild does not support it. Any changes to the metadata that is checked-in will not be reflected in the Team Build output.

The idea to have an IDE and a build engine based on the same technology and file formats is brilliant. The need to only manage build settings in one place is the biggest reason for not moving to NAnt or another offering where I'd need to maintain both the Visual Studio projects and the third party scripts manually.

Unfortunately I feel that Microsoft made two major mistakes with MSBuild and Visual Studio:

• APIs were provided to allow Visual Studio to be extended to support new project items and project types but the API doesn't force the extension to be callable by MSBuild.
• Microsoft then utilised this API to extend Visual Studio for SQL Server projects and others too and also ignored MSBuild compatibility themselves.

Yesterday I managed to crash vstesthost.exe, the program that runs Visual Studio Unit Tests when you press Ctrl+Shift+X. A few tests in my suite would run and pass, then BAM, fatal error. I ran the tests again, this time in debug mode and the tests broke into the debugger with a StackOverflowException, due to a poorly implemented interface in a mock object.

According to some searching, some exceptions including StackOverflowException, just cannot be caught in .NET 2.0 and I'm not sure it would be smart to try. Unfortunately when it happens in testing, the whole suite fails. In my case, I was able to pave over my mistake in the code and move on with my life.

The vstesthost crashing problem also happens when an exception is through on a secondary thread though. Testing asynchronous UI or background processing code could also kill the process when any exceptions occur, and these might be expected exceptions for a particular tests.

I haven't needed to use it yet, but there is a workaround to avoid the whole test suite falling over. It involves editing the vstesthost.exe.config file to enable the legacy unhandled exception policy as used by the earlier CLR versions. You will need to be careful to synchronise your threads though to ensure any exceptions are assigned to the correct test in the results.

Microsoft now has a collection of Virtual PC/Virtual Server VHD images to trial a decent range of their enterprise products. They currently have Windows Vista, Visual Studio 2005 Team Suite, Windows Server 2003 R2, SQL Server 2005, Exchange 2007, and several others. These should be really useful for testing their new products without requiring a spare machine and also for testing your own software against their various platforms. Hopefully they will continue to keep their images up to date and expand on the packages available.

We often use Strongly-Typed DataSets in our applications at work. They can be a useful tool but they have their limitations too. Today, I'm not going to discuss the pros and cons of DataSets versus some other DAL concept. Today I'm just writing about a useful tip for working with growing DataSets.

As changes are made to tables and relationships in the DataSet Designer, eventually all the diagrams become unordered and relationship links begin to wander like vines. Unfortunately, I have never been able to find in Visual Studio an option to re-layout the diagram automatically for optimum table sizes and minimum relationship intersections. You don't have to shuffle them around manually though, there is another way:

1. Open the project containing the DataSet and Show All Files in the Solution Explorer.
2. Ensure the DataSet designer windows are closed.
3. Open the DataSet's .XSS file in a code window (it should be XML with <Shape> elements among others).
4. Clear the entire contents of the XSS file, leaving it blank.
5. Save the XSS file and close the window.
6. Open the DataSet's designer window, you should find all the tables and relationships nicely arranged.

It's been a busy day but I should have another overly long post ready in time for next week.

I have been wanting to make use of Unit Testing in my personal projects and my projects at work. So far I've read a lot about unit testing concepts and implementations and even written a few tests to get a feel for it. The majority of the material that exists about unit testing in .NET refers to the NUnit testing framework. The is presumably because it was one of the first .NET unit testing frameworks and based on the well established JUnit. However, now that Visual Studio 2005 includes it's own unit testing framework, why wouldn't you want to use that?

Jean-Paul Boodhoo once blogged¹ that when a new developer joins your team they should be able to Get Latest from source control, build, and be ready to work. I agree and using tools included in Visual Studio means one less dependency for a new developer to install on their workstation. However, there is the possibility that Visual Studio's Unit Testing, as a version 1.0 product, might be lacking important functionality to be found in established testing tools. A quick Google for "visual studio unit testing vs nunit" leads to a few notable issues.

Jason Anderson explains that only Visual Studio Team Suite includes the Unit Testing tools and that Visual Studio Professional misses out. We all use Team Suite at work so this isn't a problem but I can understand that unit testing should be available developers in all team sizes. Thankfully, Naysawn Naderi says that we can expect Unit Testing in Visual Studio Pro when Orcas is released.

Roy Osherove also has two posts about choosing between Visual Studio Unit Testing and the alternatives. Roy's comments makes VS Unit Testing seem completely useless and claims some parts are broken and even says "how this one went by into the release is a mystery to me". However, I recently had the pleasure of working with VS Unit Testing briefly when contributing to the BlogML project and some of Roy's claims just felt wrong. Surely it can't be that bad. Considering we will want to decide on a testing framework for projects at work soon, I decided to verify these problems.

Roy's first complaint is that there is a bug with the ExpectedException Attribute checking the type of the Exception only and not checking the Message. This is in fact a misinterpretation of the VS Unit Testing ExpectedException Attribute and assuming it was designed the same as NUnit's counterpart. NUnit takes an Exception type and message and verifies that the right Exception is thrown and that is has the matching message. VS treats the message parameter that same as an Assert statement and uses it as the display message to the user when the test fails, admittedly the MSDN documentation is very poorly worded. However, achieving the same behaviour as NUnit is often desired and there is a quick solution:

[TestMethod()]
[ExpectedException(typeof(InvalidOperationException))]
public void ExceptionWithMessage()
{
    try
    {
        MethodToTest();
    }
    catch (InvalidOperationException ex)
    {
        Assert.AreEqual("Expected message.", ex.Message);
        throw;
    }
}

Roy is also disappointed that ExpectedException doesn't work with the base Exception type. Sure it's something the unit testing framework doesn't support but you shouldn't be throwing Exception objects and you shouldn't be catching them either. You can also use the Test Results window to group by Result (ie Passed/Failed), Class Name, and Full Class Name (ie Namespace too), this makes locating the tests your interested in much easier and also negates Roy's corresponding observations with regard to Test Driven Development.

VS Unit Testing isn't perfect though and that's to be expected for a first release. As Roy points out, you can't easily get to the failing production code from a failed test result, it doesn't have quite as many included Asserts as NUnit does and you do need to have Visual Studio installed to use the MSTest command line test runner. For the time being, our requirements don't push VS beyond it's capabilities, Orcas should improve on the weaker points when it's released later this year (?) and it is really easy to convert between NUnit and VS Unit Testing if we need to.

So, if you're looking to choose a unit testing framework, don't be put off by some of the articles flying around about VS. Give NUnit and VS Unit Testing a go and maybe MbUnit and some of the others too. Ultimately you'll find something that you and the rest of your team are comfortable with and fits your process. I can't say that any of them are perfect, nor are any flawed beyond useful. And, if you've managed to read this entire post, thanks for putting up with my ramblings ;).

---

1. Update: Added link to Jean-Paul Boodhoo's article.

I am a VB.NET developer, I have been for a long time thanks to my background with old VB3 and BASIC before that. However, I like C# and I use it whenever an opportunity arises but due to business requirements the primary language with both my last employer and my current employer is VB.NET. It shouldn't matter much though because, due to IL, the Framework library and the Common Language Runtime, both VB.NET and C# compile down to very similar results.

Sadly, the VB.NET developers experience differs from the C# developers experience even though they now share the same IDE. It seems more and more regularly that I find myself making the comment to my colleagues at work that some particular issue would be easier to deal with if we were using C#. Here are some that come to mind:

C# has the ternary operator (<condition> ? <trueresult> : <falseresult>). This is a minor difference but can simplify some otherwise verbose code. VB.NET has the IIF function but it always returns Object instead of the type of the result, thereby requiring a cast, and it is not short-circuited, making it less effective at avoiding NullReferenceExceptions. Apparently, in Orcas, the IIF function gets the same behaviour as C#'s ternary operator.

C# has automated refactoring included. Thankfully, Microsoft arranged for DevExpress to provide a free version of Refactor! for VB.NET so we don't miss out completely. Unfortunately, it doesn't completely bridge the gap. A notable omission is the "Generate Method Stub" refactor that C# includes.

At work, we are slowly adopting Unit Testing where we can to help detect issues sooner in the development cycle. Exposing your production code for unit testing also helps to refactor it for better maintainability. Sometimes you can't easily test internal code but luckily the framework includes the  InternalsVisibleToAttribute which can allow a separate (unit testing) project to call Friend/Internal methods in another project. You can apply this attribute to any VB or C# code but only the C# compiler looks for it meaning we would need to write our unit tests in C#. Again, apparently Orcas has updated the VB compiler to fully support this attribute to.

As well as adopting Unit Testing, we are trying to establish a Continuous Integration system to discover the full impact of changes as they are checked-in. Unfortunately, while the VB IDE is smart enough to infer references beyond the first level, the MsBuild tool used by most CI systems does not, and therefore all builds fail. We could manually add the second level references to each of our projects but any well-meaning developer who uses the Remove Unused References button will undo the hard work. C# requires the second level references to be specified for even the IDE build so it doesn't have this issue. Apparently Orcas changes the VB IDE behaviour to match C# and MsBuild.

VB doesn't completely lose out though. VB has background compilation which makes on-the-fly error detection and Intellisense much more productive. It can slow things down in large solutions and it tends to be the cause of most of the IDE's crashes but in C#, where there is no background compiling, it is sorely missed.

In Visual Studio 2003, VB was behind C# in other ways. The VB team at Microsoft ensured VB received all the missing bits in Visual Studio 2005, however the C# team bounded forward with even more features for C#, thereby still leaving VB behind. With Orcas in Beta 1, we can see that VB has caught up again with the features C# already had. And once again, C# in Orcas has even newer features.

No Sir, I don't like it.

My new home office machine has arrived and I am setting myself up for the most pain possible with my chosen configuration. Firstly I am installing Visual Studio 2005 on Vista Business Edition. Microsoft has only just released a patch for Visual Studio on Vista and it isn't perfect. Add to that running as a restricted user in Vista which introduces more problems. Finally I've chosen the 64-bit edition of Vista which complicates working with Visual Studio and software in general.

Reading the many articles and forum posts about problems with Vista and 64-bit will discourage most people from trying but so far I've found the experience to be quite pleasant. The first road-block is the need for new Vista 64-bit signed hardware drivers but Windows detected everything but the onboard sound and I was able to very easily find drivers on the HP web site for that. Two vital utilities, Daemon Tools and UltraMon, are already available with Vista x64 versions.

Vista has streamlined .zip file handling so I don't need any archiving software and the usual problems with new OS burning software are gone because Vista writes to CD and DVD out of the box. The small problem of burning disc images is solved by the free ISO Recorder, updated for Vista x64. I don't need MakeMeAdmin anymore because Vista's UAC temporary privilege elevation features have solved the problem. And, of course, Microsoft Office works beautifully.

I could rant for hours about the wonders of this new system but there were some issues. I managed to crash Visual Studio while setting the options for the first time but this is an easily avoidable documented issue (thanks Jim). I upgraded SQL Server 2005 to SP2 via Vista's built in AutoUpdate tool so I needed to run the User Provisioning Tool manually afterward to be able to connect. Also, a minor annoyance, Windows x64 has a separate Program Files folder for 32-bit and 64-bit applications and some installers were defaulting to the wrong folder.

I'm keeping a list of issues I encounter with Windows in general and developing with Visual Studio and SQL Server. I'll write about my experiences further on this blog as time passes and as I start pushing the boundaries of compatibility. At this point I have no regrets moving to Vista and 64-bit. I sure don't want to go back to either 32-bit or Windows XP and I'd recommend anyone with similar needs to my own to do the same.

At work we are currently developing a suite of applications that are expected to work on Windows XP and, I assume, eventually Windows Vista. The entire development team refreshed their workstations just after Vista went RTM and was available to MSDN subscribers. At the time Visual Studio 2005 wasn't fully supported in Vista and there were too many unknowns so an executive decision was made to stay with XP on the dev machines. I feel it was the right decision at the time.

However, there was one particular reason for staying with XP that I wasn't sure I could agree with. There was a concern that by developing under Vista we might lose touch with XP and find ourselves developing a product that has accidentally used facilities only available in Vista or that differ in Vista. The result, of course, is that we may lose compatibility with XP and discover the problem too late in development to solve it without large time, effort, or cost consequences.

I have decided to use my blog as a place of discussion for reasons why this concern is, or is not, valid. My bias is that the concern is unnecessary but I invite comments on anything I haven't considered.

Acceptance Testing

For each iteration of a product that we produce it goes to our testers to find bugs and usability issues before it can be considering for release. Our testers utilise a clean Windows XP environment inside Virtual PC to perform the suite of tests against the product. Any problems in our software that are specific to XP should be picked up here.

Visual Studio Limitations

Visual Studio 2005 was released well before Windows Vista was close to completion. As a result the IDE itself is not aware of any new features in Vista. In fact, it doesn't even fully support all the features introduced in Windows XP, one aspect that comes to mind is correct rendering of 32-bit icons. Any Vista specific features that are used will have be done so explicitly and presumably with prior consideration.

Framework 3.0

The new .NET Framework 3.0 features are included out of the box in Vista. Updates have been released for Visual Studio 2005 to provide project items and designers for the new WPF, WCF, and WWF components. However, just as we need to ensure that our XP clients need to install .NET Framework 2.0, version 3.0 is supported on XP and Server 2003, and is redistributable via the same methods as 2.0.

Features Lost

One of the primary focuses of Windows Vista has been to improve security. Many popular applications have required (or still require) an update to support Vista due to a change in the operating system's default behaviour. I believe there is a greater risk of utilising a Windows XP feature that will break under Vista because security has been tightened or the feature has been removed altogether (anyone still using WinHelp?).

Practice

With these points in mind I am in the process of building a Vista 64-bit development machine for the home office. With this configuration I intend to experience first hand what issues there are in terms of application compatibility and problems with the development process itself. Anything I find along the way that supports or disproves my beliefs above will help to decide when the development team should migrate to Vista, if at all.

If you have any experiences yourself with this situation I would appreciate your input.

With Windows XP, I find I don’t need to reinstall my system as often as I did with previous versions. As a result there are large gaps between each installation of Visual Studio and my memory fades during this time.

One of the decisions to be made when you run a fresh install of Visual Studio for the first time is how you want the environment to be configured: General Development, Visual Basic, Visual C#, etc. Your choice here will determine default window positions, menu and toolbar items and keyboard shortcuts among other things. Each time I am faced with this decision I am not sure what I chose last time. Should I use the Visual Basic settings to suit my preferred language or should I use General Development settings so the environment is ready for me to jump around between languages and project types?

When I installed Visual Studio 2005 in November I chose Visual Basic and I have since been annoyed by the difficulty in finding the Build Configuration Manager and the quick Debug/Release chooser on the toolbar. I had assumed that this was a simple change in the UI for VS2005 so I customised the menus and toolbar to include the missing items. I intended to blog about this problem when I first noticed but it was delayed until now.

I was reminded the other day when, wandering through the .NET documentation, I stumbled across a couple of articles about hidden debug commands in the IDE. I was shocked to read that the build menus and toolbars are limited only when Visual Basic is chosen for the environment configuration. Considering in VS2005, Microsoft brought the VB language much more into line with C# and introduced low-end Express Editions for beginners, I was surprised they decided to take a step backwards and hide build configurations from VB users in the Professional version. Just when I thought Visual Basic had been promoted to a first-class language in the .NET range!

For anyone else who was baffled by this change in the new version, here is the MSDN article explaining how to get control of your builds back.