Team Build IsA MSBuild?

I had one of those Aha! moments this weekend. You know, the ones that Oprah is always talking about (not that I watch, it just happens to be on sometimes when I’m in the room…) It turns that somehow in my dealings with Team Foundation Build (i.e. “Team Build”) I had always maintained this subconscious assumption that Team Build was really just MSBuild++, or rather, a proper superset of the functionality that MSBuild provides. I probably wouldn’t even have balked had someone shown me a UML diagram like this:

The assertion there being that Team Build is just a realization of MSBuild, extended to work in a broader, team environment. A follow-on assertion (that certainly I made) is that the team who created Team Build started with MSBuild as a basis and worked out. My “Aha! Moment” was realizing that in fact it is not an IsA relationship at all, but rather a pure HasA relationship:

Could you be a Tranxcoder?

We’re hiring. No, really, we are. I realize you know three developers who either recently lost their jobs or are fairly confident it’s about to happen, but despite the downturn, we are hiring. Even more striking is that these are new positions – not replacements! That’s right, on the cusp of what some are predicting will be the worst U.S. economic slump since The Great Depression, we are growing our engineering team. Have I made this clear yet?

Why dwell on economic troubles in a job post? Because sometimes we hear that good developers hesitate to look at small companies because they want “stability”. Well I would just like to point out that while most of the major corporations in the country are gearing up for hiring freezes, pay cuts, lay offs, and who knows what else; our tiny little company is as strong as I’ve ever seen it and shows no signs of slowing. Come get your stability while it’s hot.

Customizing “lookful” WPF controls – Take 2

Last week I posted a technique for customizing controls in WPF that don’t offer a replaceable ControlTemplate – I described them as “lookful” controls because their behavior and appearance are tied in with their functionality. My approach involved creating a custom control that derives from the one being targeted. That solution has some significant downsides, though, including that if the control is part of another (composition) then you have to modify the parent control to tell it to use your new custom control as a child – it works in most cases, it’s just not ideal. I figured someone might call me out on it eventually and, sure enough, the day I posted it fellow WPF’er “John” ruminated in a comment about using attached properties to accomplish the task instead. That got my wheels turning and I decided to put together a solution that, frankly, doesn’t stink…

Showing ToolTips on a trimmed TextBlock (WPF)

[UPDATE: This solution has been superceded by a much better implementation in this later post.]

I recently downloaded the WPF Toolkit for which Microsoft posted the first DataGrid CTP. That DataGrid is their attempt at responding to what is likely one of the most requested missing features in WPF. Many people have suggested that WPF doesn’t need a DataGrid and may be better off not to provide one, but I and others disagree – we do need a DataGrid, but it must be lookless! Anyway, I’m getting off topic.

While I really appreciate the work that went into building such a flexible and feature-packed control, I was quickly disheartened to learn that it has no mechanism built in to handle the scenario where column data (text) gets cut off due to size constraints. Actually there is one means, wrapping the text, but for the task I’m currently working on wrapping is really not an acceptable approach.

Customizing “lookful” WPF controls

[UPDATE: This solution has been superceded by a much better implementation in this later post.]

If you’ve spent any time reading material about WPF, it’s inevitable that the term “lookless” has come up at least once. Ironically, that’s not actually a word, at least not according to Webster. However, the term has been drilled into the minds of WPF developers the world over and will likely be added to the Windows dictionary at some point. Microsoft even used the word several times in this patent application which describes in precise detail what it means. In case the practical meaning isn’t clear, in essence “lookless” equates to “has a flexible UI”. In other words, lookless controls are focused on functionality, not appearance or even visual behavior. Of course most controls do have a default appearance, but lookless controls are, by nature, almost completely customizable (limited mostly by imagination and time.)

Matt Duffin of the UK even suggested we all grab a pen and write “All controls in WPF should be lookless” over and over until it becomes ingrained. Not sure I would go that far, but clearly the overwhelming guidance for WPF designers is that most controls should have a stylable and/or templatable appearance which is independent of functionality. Being aware of that guidance just makes it even more frustrating when you run into a control built into the framework which violates that tenet.

The particular control I’m referring to in this case is the TextBlock. Recently I had a desire to enable ToolTips on a TextBlock when (and only when) its text is being trimmed. I’ve written a separate post which goes into the solution to that specific problem in more depth, but getting there required a lot of foundational work which can be applied to address any number of issues.

Disposable C# Snippets

Visual Studio code snippets were brought up a couple times today.  Which reminded me of the only two snippets I’ve ever written and used.  I think they’re useful to save me some typing.  In C# whenever you have some class that is holding onto unmanaged resources, or even a lot of managed resources, you really need to make it IDisposable.  The problem is it’s a fair amount of repetitive typing to get there. 

A Generic Factory in C#

There is this really popular OOP design pattern that we at Tranxition, and other developers elsewhere, use frequently.  Years ago, after reading about the factory pattern in the GOF book I immediately thought of some possible uses for it in my work.  I was really excited to code it up… the first time.  After having writing the code for one factory though, it was clear to me it should just be a library and there were some things overlooked by most example implementations.

Testing a Task

In my previous post I described the creation of a custom MSBuild task to aid in building WiX projects under TFS. However, one thing I have always disliked about most of the code nuggets found on blogs and magazine articles, which I find highly inexcusable in today’s development landscape, is that they rarely include any tests to prove that their code actually works. Therefore, this post is intended to demonstrate that throwing in a few simple unit tests with code samples is easy and goes a long way toward helping readers understand and trust the code being published.

A custom task for building WiX under MSBuild (TFS)

My name is Shawn (Hempel) and this is my first submission to the Tranxcoder blog, which is a little ironic since I think it was my idea in the first place. Nonetheless, at least now I am officially “on the board” (and the team can stop razzing me about not posting.)

It seems I’ll be continuing on a running theme of writing about making Team Foundation Server work for us in new and scary ways. If you’re wondering why so much of our blog has centered on that topic, I think it’s two parts: 1) in many ways TFS customization is neither easy or intuitive so as we struggle to make things work, we want to share that with the development community; and 2) since our build process has little to do with the logic in our products, it’s easy to put this stuff out here without worrying about giving away intellectual property. That said, there will probably be more non-build related content as time goes on – we’ll just change variable names to protect the innocent. Alright, on to the good stuff…

As previously mentioned by Richard, we use the WiX toolset to generate Windows Installer binaries (MSI/MSM) for our applications. Personally, I find the recent builds of Votive (WiX’s Visual Studio integration package) to be quite helpful and easy to work with. One of the things it does very well is enable a simple F5 installer build. What it does not do, however, is help you in any way once you decide to graduate from building on the desktop to incorporating an installer build in your TFS processes. Specifically, there will almost certainly be some trouble with the relative and/or absolute paths used in your WiX source files to locate the build outputs to package. Read on to find out how we first solved that problem in a way that made it hard to sleep at night, and subsequently replaced it with a robust, maintainable solution.

WiX, MSBuild, and Build Verification, Part 1

Probably the least thought about, and planned for process in the development cycle is the installer. Since few projects get completed early, time for a well planned installation takes a back seat to the main development effort. However, we’ve all heard over and over that the customer’s first impression of your product will be your installer. At Tranxition, we were given the time to research the various installation products currently available, and decided to with WiX for a number of reasons.

Why WiX?

WiX has a couple great advantages. It integrates seamlessly with Visual Studio. This means it can be included in our nightly build process simply by including our installation projects into our Visual Studio solution. It produces an .msi file, allowing our installer to work on all Windows versions we need to support. Also, we get the installer repair and uninstall options for free. Speaking of getting things for free… WiX is free. Yes, a free open source Microsoft originated project.

You say nothing is ever free? That is somewhat true, there are some disadvantages. Documentation is scarce, you will depend heavily on blogs to learn the product, and figure out your issues. As an open source product, it has bugs (that so far I’ve been able to work around), but some times I’ve had to go back to an older installation, or needed to manually edit the project files. However, we have multiple configuration of our final product, seven different released products. The differences are mainly to the installer GUI, differing help files, and a couple customer specific DLLs. WiX works beautifully with these different configurations, and we don’t need to create a separate project per installer.

Over the next few months, I will detail our WiX installation scripts and configuration, the integration of our WiX projects into our MSBuild process, along with our build verification process. This first article, I will describe our installers, our build configurations, how we use the project configuration to create each of our product releases, and why this might help you decided to also use WiX.