The only problem is there seems to be some incompatibility problems as described in this post.  One of the posters recommends creating a separate DLL as a way to get around the problem, but this seems like kind of a hassle.

I have created this function below called GetFileInfoByHandleEx that will work from Windows XP to Windows 7(and probably Windows 2000 as well). It does use some undocumented functions so I need to add a disclaimer that they could change or disappear some day, but I don’t think it is too likely.

#include <winternl.h>
// New FILE_INFO_BY_HANDLE_CLASS value for Windows 7
#ifndef FileRemoteProtocolInfo
#define FileRemoteProtocolInfo 13
#endif
typedef NTSTATUS (WINAPI *NTQUERYINFORMATIONFILE_FUNC)(HANDLE, PIO_STATUS_BLOCK,
PVOID, ULONG, FILE_INFORMATION_CLASS);
typedef NTSTATUS (WINAPI *NTQUERYDIRECTORYFILE_FUNC)(HANDLE, HANDLE, PIO_APC_ROUTINE,
PVOID, PIO_STATUS_BLOCK, PVOID , ULONG, FILE_INFORMATION_CLASS,
BOOLEAN, PUNICODE_STRING, BOOLEAN);
typedef ULONG (WINAPI *RTLNTSTATUSTODOSERROR_FUNC)(NTSTATUS);
typedef NTSTATUS (WINAPI *NTWAITFORSINGLEOBJECT_FUNC)(HANDLE, BOOLEAN, PLARGE_INTEGER);
//
// GetFileInformationByHandleEx
//
BOOL GetFileInfoByHandleEx(HANDLE hFile, FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
LPVOID lpFileInformation, DWORD dwBufferSize)
{
IO_STATUS_BLOCK ioStatusBlock;
BOOL restartScan = FALSE;
int queryInformationClass = 0;
DWORD minimumSize = 8;
BOOL useDirectory = FALSE;
//
// Load ntdll.dll
//
HMODULE ntdllModule = LoadLibrary(_T("ntdll.dll"));
if (ntdllModule == NULL)
{
return FALSE;
}
    //
// Get NTDLL Function Addresses
//
NTQUERYINFORMATIONFILE_FUNC pNtQueryInformationFile =
(NTQUERYINFORMATIONFILE_FUNC)GetProcAddress(ntdllModule, "NtQueryInformationFile");
NTQUERYDIRECTORYFILE_FUNC pNtQueryDirectoryFile =
(NTQUERYDIRECTORYFILE_FUNC)GetProcAddress(ntdllModule, "NtQueryDirectoryFile");
RTLNTSTATUSTODOSERROR_FUNC pRtlNtStatusToDosError =
(RTLNTSTATUSTODOSERROR_FUNC)GetProcAddress(ntdllModule, "RtlNtStatusToDosError");
NTWAITFORSINGLEOBJECT_FUNC pNtWaitForSingleObject =
(NTWAITFORSINGLEOBJECT_FUNC)GetProcAddress(ntdllModule, "NtWaitForSingleObject");
switch (FileInformationClass)
{
case FileAttributeTagInfo:
queryInformationClass = 35; // FileObjectIdInformation
break;
case FileIdBothDirectoryInfo:
case FileIdBothDirectoryRestartInfo:
queryInformationClass = 37; // FileOleDirectoryInformation
useDirectory = TRUE;
minimumSize = 0x70;
restartScan = 0;
break;
case FileRemoteProtocolInfo:
queryInformationClass = 55; // ???
minimumSize = 0x74; // sizeof(FILE_REMOTE_PROTOCOL_INFO)
break;
case FileCompressionInfo:
queryInformationClass = 28; // FileCompressionInformation
minimumSize = sizeof(FILE_COMPRESSION_INFO);
break;
case FileBasicInfo:
queryInformationClass = 4; // FileBasicInformation
minimumSize = sizeof(FILE_BASIC_INFO);
break;
case FileStandardInfo:
queryInformationClass = 5; // FileStandardInformation
minimumSize = 0x18;
break;
case FileNameInfo:
queryInformationClass = 9; // FileNameInformation
break;
case FileStreamInfo:
queryInformationClass = 22; // FileStreamInformation
minimumSize = 0x20;
break;
default:
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
if (dwBufferSize < minimumSize)
{
SetLastError(ERROR_BAD_LENGTH);
return FALSE;
}
NTSTATUS status;
if (useDirectory)
{
status = pNtQueryDirectoryFile(hFile, NULL, NULL, NULL, &ioStatusBlock,
lpFileInformation, dwBufferSize,
(FILE_INFORMATION_CLASS)queryInformationClass, FALSE, NULL, restartScan);
if (status == STATUS_PENDING)
{
status = pNtWaitForSingleObject(hFile, FALSE, NULL);
if (FAILED(status))
{
SetLastError(pRtlNtStatusToDosError(status));
return FALSE;
}
status = ioStatusBlock.Status;
}
}
else
{
status = pNtQueryInformationFile(hFile, &ioStatusBlock, lpFileInformation,
dwBufferSize, (FILE_INFORMATION_CLASS)queryInformationClass);
}
if (FAILED(status))
{
SetLastError(pRtlNtStatusToDosError(status));
return 0;
}
if ((FileInformationClass == FileStreamInfo) && (restartScan == FALSE))
{
// STATUS_END_OF_FILE = 0xC0000011
SetLastError((pRtlNtStatusToDosError(0xC0000011)));
return FALSE;
}

return TRUE;
}

As I was starting out trying to get my sample working, I ran into a couple of problems.  The problems occurred when I would call the InitializeForBackup function from the IVssBackupComponent interface.  It would return the value 0×80042302.  When I looked in vsserror.h, that value was skipped:

//
// MessageId: VSS_E_BAD_STATE
//
// MessageText:
//
// A function call was made when the object was in an incorrect state
// for that function
//
#define VSS_E_BAD_STATE ((HRESULT)0x80042301L)

//
// MessageId: VSS_E_PROVIDER_ALREADY_REGISTERED
//
// MessageText:
//
// The provider has already been registered.
//
#define VSS_E_PROVIDER_ALREADY_REGISTERED ((HRESULT)0x80042303L)

I discovered later that the value was defined in V7 of the SDK and it is defined as VSS_E_UNEXPECTED and it simply meant to check the application event logs for more information.

So I checked the Application Log and was getting the following error.

Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr = 0x800401f0, CoInitialize has not been called.
.
Operation:
Initialize For Backup

I did some searches and eventually found a forum post that said to make sure that the “Volume Shadow Copy”, “COM+ System Application”, and the “Distributed Transaction Coordinator” services were running.  My “COM+ System Application” service was not running, so I started it and it fixed that problem.

But then another error occurred:

Volume Shadow Copy Service error: A critical component required by the Volume Shadow Copy service is not registered. This might happened if an error occurred during Windows setup or during installation of a Shadow Copy provider. The error returned from CoCreateInstance on class with CLSID {e579ab5f-1cc4-44b4-bed9-de0991ff0623} and Name IVssCoordinatorEx2 is [0x80040154, Class not registered].
Operation:
Instantiating VSS server

I figured out that this was being caused because I was making my application a 32-bit application running on a 64-bit OS.  The documentation specifically says “All 32-bit VSS applications (requesters, providers, and writers) must run as native 32-bit or 64-bit applications. Running them under WOW64 is not supported.” and this is what happens when you ignore it.

So I was about 90% of the way finished, but the last part of actually doing the file copy was a little unclear, so after a little bit of searching, I found the VShadow sample project in the Volume Shadow Copy Service SDK 7.2 which seemed like it would be perfect for my needs.  Well, it’s a very powerful tool, but it  really wasn’t that clear on how to use this utility to copy a file either.

I felt like I was getting very close!

After a little more searching, I found SCRIPT RECIPE OF THE WEEK: HOW TO COPY AN OPENED FILE which gave me the information needed on how to call VShadow, along with other cool features like how to recursively call your script.  It worked, but there were still a few problems like not being able to use it from a long file path with spaces and it also wouldn’t copy hidden files.

But based on how this script called VShadow, I was able to figure out my missing piece and finished this sample.

So, in a nutshell, this is a sample of how to copy a single locked file:

LockeFileCopy.cpp

#include <stdio.h>
#include <tchar.h>
#include <shlwapi.h>
#include <vss.h>
#include <vswriter.h>
#include <vsbackup.h>

int _tmain(int argc, _TCHAR* argv[])
{
int returnValue = 1;
if (argc != 3)
{
printf("Usage: LockedFileCopy.exe sourcefile destinationfile\n");
return 1;
}
TCHAR sourceFile[_MAX_PATH] = {0};
LPTSTR destinationFile = argv[2];

//
// Create an absolute path if it is relative
//
_tcscpy(sourceFile, argv[1]);
if (PathIsRelative(sourceFile))
{
::PathFindFileName(sourceFile);
}

if (_taccess(sourceFile,0) != 0)
{
_tprintf(_T("\"%s\" does not exist!\n"), argv[1]);
return 1;
}

if (CoInitialize(NULL) != S_OK)
{
printf("CoInitialize failed!\n");
return 1;
}

//
// Create the IVssBackupComponents Interface
//
IVssBackupComponents *pBackup = NULL;
HRESULT result = CreateVssBackupComponents(&pBackup);
if (result == S_OK)
{
//
// Initialize for backup
//
result = pBackup->InitializeForBackup();</code>

if (result == S_OK)
{
//
// Prompts each writer to send the metadata they have collected
//
IVssAsync *pAsync = NULL;
result = pBackup->GatherWriterMetadata(&pAsync);
if (result == S_OK)
{
printf("Gathering metadata from writers...\n");
result = pAsync->Wait();
if (result == S_OK)
{
//
// Creates a new, empty shadow copy set
//
VSS_ID snapshotSetId;
result = pBackup->StartSnapshotSet(&snapshotSetId);
if (result == S_OK)
{
//
// Add Volume to the shadow copy set
//
WCHAR volumeName[4] = {sourceFile[0], _T(':'), _T("\\")};
wprintf(L"Adding %s volume to snapshot set...\n", volumeName);
result = pBackup->AddToSnapshotSet(volumeName, GUID_NULL, &snapshotSetId);
if (result == S_OK)
{
//
// Configure the backup operation for Copy with no backup history
//
result = pBackup->SetBackupState(false, false, VSS_BT_COPY);
if (result == S_OK)
{
//
// Make VSS generate a PrepareForBackup event
//
IVssAsync* pPrepare = NULL;
result = pBackup->PrepareForBackup(&pPrepare);
if (result == S_OK)
{
printf("Preparing for backup...\n");
result = pPrepare->Wait();
if (result == S_OK)
{
//
// Commit all snapshots in this set
//
IVssAsync* pDoShadowCopy = NULL;
result = pBackup->DoSnapshotSet(&pDoShadowCopy);
if (result == S_OK)
{
printf("Taking snapshots...\n");
result = pDoShadowCopy->Wait();
if (result == S_OK)
{
//
// Get the snapshot device object from the properties
//
VSS_SNAPSHOT_PROP snapshotProp = {0};
result = pBackup->GetSnapshotProperties(snapshotSetId, &snapshotProp);
if (result == S_OK)
{
//
// Create the source path by using the volume specified in
// m_pwszSnapshotDeviceObject and appending the path of
// the source file (minus the drive letter)
//
int sourceLength = wcslen(snapshotProp.m_pwszSnapshotDeviceObject) +
_tcslen(sourceFile);
LPTSTR sourceSnapshotFile = new TCHAR[sourceLength];
_tcscpy_s(sourceSnapshotFile, sourceLength,
snapshotProp.m_pwszSnapshotDeviceObject);
_tcscat_s(sourceSnapshotFile, sourceLength, &sourceFile[2]);</code>

//
// Copy the file from the snapshot device object
//
if (!::CopyFile(sourceSnapshotFile, destinationFile, FALSE))
{
DWORD lastError = GetLastError();
printf("Failed to copy file - Error: %d\n", lastError);
}
else
{
printf("Successfully copied file!\n");
returnValue = 0;
}
delete [] sourceSnapshotFile;</code>

//
// Cleanup properties
//
VssFreeSnapshotProperties(&snapshotProp);
}
}
pDoShadowCopy->Release();
}
}
pPrepare->Release();
}
}
}
//
// Delete the snapshot
//
LONG deletedSnapshots = 0;
VSS_ID nonDeletedSnapshotId;
result = pBackup->DeleteSnapshots(snapshotSetId, VSS_OBJECT_SNAPSHOT,
TRUE, &deletedSnapshots, &nonDeletedSnapshotId);
}
}
pAsync->Release();
}
}
pBackup->Release();
}
return returnValue;
}

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:

Internally, Team Build uses MSBuild, and as such, to perform many of its common tasks it depends on MSBuild, but Team Build is most certainly not MSBuild.

I’m sure after reading this most people are probably thinking two things:

1. Duh!
2. So what?

As for your first thought; hey, cut me some slack. I never claimed to be the sharpest tool in the shed. That said, odds are I’m not the first person to incorrectly assume a more intimate relationship between Team Build and MSBuild than what actually exists.

To address your second thought; let’s look at this from the other perspective. What assumptions might you hold about the capabilities of MSBuild that may actually be capabilities inherent to Team Build which have no corollary in the context of MSBuild. Specifically for me this showed up as support for building (and controlling the build process of) “solutions”.

If you’ve done any work customizing a MSBuild project’s build process, the ability to override build properties and targets has probably been very useful. If not, then let me edify you now:

You have the ability to override build properties and targets in your MSBuild projects (which includes C# (.csproj), VB.NET (.vbproj), ASP.NET Web Deployment Projects (.wdproj) , et al.) In fact, if you crack open the .csproj file for any of your VS2008 C# projects, you’ll see the following markup at the bottom:

<!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets.

<Target Name="BeforeBuild">

</Target>

<Target Name="AfterBuild">

</Target>

-->

If your Team Build experience is at all like mine then you’re more than a little familiar with both the Target element and the nomenclature of BeforeTarget/AfterTarget. The idea there is pretty straightforward, rather than using the clunky old “PostBuild Steps” from the days of yore (which you can still do, but why?) they are explicitly inviting you to interact directly with MSBuild in altering your build steps. This has been written about quite a bit and can be very handy for simplifying the lives of current and future developers on a project. One thing we like to do on my current project is to ensure that any actions normally taken by our installer are automatically applied after each build on a development machine. For instance:

<Target Name="AfterBuild" Condition="$(DevEnvDir) != '*Undefined*'">

  <Message Text="Copying My targets file" />

  <Copy SourceFiles="$(ProjectDir)My.targets" DestinationFolder="$(MSBuildExtensionsPath)\My\" ContinueOnError="false" SkipUnchangedFiles="false" />

</Target>

That target will copy the “My.targets” file from the project’s source directory to the system configured path for MSBuild extensions after each successful build. That may not be very useful in your situation, but for our project it is a major developer productivity boon.

Let’s say, however, that you wanted some particular bit of functionality to execute after each successful Solution build. How would you go about it? Well, I can tell you one thing that will not work – adding solution-related targets to your .csproj file. One reason may seem obvious, each project is build individually by MSBuild. Therefore, when a particular project is building it really has no information about the overall status of the outer build. The more important reason, however, is that generally speaking, your solutions are not built by MSBuild.

Now if you really want to you can call msbuild.exe from the command-line to build your solution. And if your solution consists only of projects whose type is one of the few project types directly supported by MSBuild, then MSBuild can build your solution. However, the vast majority of Visual Studio solutions will never be built by MSBuild. True story.

So what does build them? More often than not, the build is managed by Visual Studio itself. Other tools that you may run into which can directly build solutions are NAnt and of course Team Build, which I’ll get to shortly.

If you look in your solution file (.sln) you’ll see the first few lines looks like this:

Microsoft Visual Studio Solution File, Format Version 10.00

# Visual Studio 2008

Notice that A) that is obviously not XML syntax and B) it’s pretty specific about which application this file’s format belongs to. In other words, this is not an MSBuild file, this is a Visual Studio file. When you execute the command, Visual Studio (not MSBuild) runs the show. It decides which projects should build, when they should build and which build targets to execute, and it decides how and where to log any output and where to drop the output files. It also, for example, knows that Visual C++ projects should build using VCBuild whereas C# projects should build using MSBuild.

Alright, back to Team Build. How does Team Build know what to do with a .sln file that is specific to Visual Studio? The team behind Team Build coded support for that (external) file format into their system and decided what to do with them. Generally speaking, they don’t do much with them besides parsing out the configured projects and their supported build platform and configuration pairs. After that, Team Build handles solution building just like it does project building – it has a set of predefined solution targets that execute in a predefined order (all of which is overridable) that ultimately calls a task they wrote named MSBuild and passes in the solution file’s path along with the configuration and platform to build as well as a bunch of additional properties and metadata. What’s important to note here is that Team Build’s MSBuild Task does execute MSBuild, it just does so in an over-controlling-boss fashion. One of the side-effects, however, is that Team Build does not support building solutions which contain non-MSBuild project types. Rather than failing when it encounters those projects, MSBuild instead will skip them and build the project types it does support (I’m still in the process of validating that statement.)

MSDN has a walkthrough on configuring Team Build to build a Visual Studio Setup Project (one of the project types supported by Visual Studio but not supported by MSBuild.) The meat of the walkthrough is really near the end:

<Target Name="AfterCompile">
    <Exec Command="&quot;$(ProgramFiles)\Microsoft Visual Studio 9.0\Common7\IDE\devenv&quot; &quot;$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj&quot; /Build &quot;Debug|Any CPU&quot;"/>
    <Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller.msi; SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe" DestinationFolder="$(OutDir)" />
</Target>

This target will be called once the compilation chain is complete (all solution and project configurations have been compiled.) What does it do? Because Visual Studio knows how to build Setup projects and MSBuild does not, it actually calls out to devenv.exe (the Visual Studio executable) passing it “/build ‘Debug|Any CPU’” and the path to the project file to build.

So where does all this knowledge of Visual Studio, MSBuild, and Team Build leave us? Well for me it has created a bit of a quandary and at this point I’m still not sure the best way to resolve it. I need to find a way to interact with the solution build sequence of Visual Studio (and probably Team Build at some point) such that I can execute some custom validation on a fully built solution, rather than on individual projects. The only thing I can be 100% certain of is that MSBuild will have little or no direct involvement.

For now that’s where I leave this post. I have a feeling my follow-up will involve Visual Studio eXtensibility hooks convoluted enough to make grown men weep. But until I know that for sure, I’ll just keep smiling while I think about kittens and bunnies.

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.

As for what we’re looking for, I’m just going to republish our standard job description. If you are at all interested, please email hiring@tranxition.com with your half-page résumé. What? You don’t have one of those ready to send? That’s the whole point … we don’t hire by the same standards and methods that Intel does, so you shouldn’t expect the same résumé will work with us that works with them. Take a few minutes and show us why we should hire you, not your bullet points. Of course if you really can’t do it, we’ll take your 3 page list of bullet points as well. We just won’t like it.

Title:
Senior Software Engineer, Full-time employee

The Hook:
Superstars wanted!

Do you have the chops to develop bleeding edge software on leading edge platforms? Do you have a history of getting things done and a demonstrable aptitude for all things software? Do you despise buzzwords like self-motivated and self-starter, but embody their ideals anyway? If so, then you should join our dev team.

The Team:
At Tranxition, our engineers eat and sleep software. We do our best coding in the bathroom and we’re not afraid to admit it. No algorithm is perfect and no architecture is complete, but we know when to call it good enough because perfection is a dream and profitability means we get to come back tomorrow.

We thrive on natural talent and we constantly nurture our talented. We don’t ask management if we can receive training; management asks us which training we want to receive. New technology, old technology, we do it all and we do it well.

Iterative development is our core because it works. Unit testing is not optional because working software is not optional. QA is an integral part of our team for the same reason. We don’t do pair programming because sometimes – we just need to sleep in. Or work from home. Or put in a twelve hour day because this problem needs to be solved and we want to solve it, today!

The Profile:
Our primary concern is to find people smarter than us to join our team. That said, we have a specific skill set that we would love to match and those who do may find themselves at the front of the pack:

· Real-world advanced .NET experience
· Full SDLC (specification through maintenance) experience
· Iterative development experience
· Commercial software experience
· Experience designing and implementing web services
· SQL Server experience
· Active Directory and Group Policy experience
· WMI development experience
· Unmanaged C/C++ development experience
· Experience with Team Foundation Server, MSBuild (or NAnt, Ant), and MSTest (or NUnit, MbUnit, xUnit.net, JUnit)
· WPF, LINQ and PowerShell aren’t foreign concepts
· Reference shelf includes books with “Internals” in the title
· Indigo equals WCF and WinFS is the greatest lost feature since Microsoft Bob

The control I covered was the TextBlock, and the customizations I made involved adding a dependency property called IsTextTrimmed to my derived control which indicates if the text is being trimmed (clipped with ellipses appended). This time I’ll tackle that same issue, but do it in a way that doesn’t require custom controls, is easy to use, and is flexible enough to support any number of additional customizations.

At the end of this post there is a link to a solution which contains the TextBlockService assembly and a Sample WpfApplication that demonstrates its usage. As with everything we post on The Tranxition Developer Blog, feel free to use it however you wish, ask questions, or suggest alternatives. Rather than cover how all of this works (there are a lot of WPF concepts involved), I’m just going to lay out the key bits and then explain a little about why I made certain design and implementation decisions.

All of the functionality resides in the TextBlockService assembly with most of the logic in TextBlockService.cs. That file holds a single public class called TextBlockService which serves as an attached property provider for two properties, the critical one being TextBlockService.IsTextTrimmed.

The attached properties mechanism is one of the coolest (and least intuitive) things about WPF. In this case, I’m bucking the norm which involves backing all attached properties with corresponding dependency properties. As a result, my class doesn’t need to implement any dependency property requirements and also need not derive from the DependencyObject class. It seems odd at first, but the instance values for these properties are maintained entirely by the framework, with no help from my class.

That code fragment is what registers my attached property as “TextBlockService.IsTextTrimmed” in XAML, sets it type to bool, and sets the default value to false. Since this property can’t logically be “set” by a consumer, it’s registered as read-only which means instead of returning a DependencyProperty object, it returns a DependencyPropertyKey. That key is used to retrieve a special type of DependencyProperty object:

Which is used when retrieving the current value:

This property (IsTextTrimmed) only makes sense when attached directly to a TextBlock so I used AttachedPropertyBrowsableForType to restrict designers to only displaying it as an attribute on TextBlock elements. This doesn’t actually prevent users from trying to attach it to other element types, but it won’t show as an available option in the IDE. In addition I made the parameter type TextBlock on GetIsTextTrimmed where normally for attached properties this will be something much more generic like DependencyObject or UIElement, etc.

With that bit of code we’ve created a full fledged read-only property that can be attached to any TextBlock control. However, we lack any means to actually set the value (besides its default).

I simply adapted a function that calculates the current trimmed state for any given TextBlock by adding a bit of logic at the top to retrieve the present IsTextTrimmed value if the TextBlock is not in a state where it can be evaluated:

private static bool CalculateIsTextTrimmed( TextBlock textBlock )
{
    if ( !textBlock.IsArrangeValid )
    {
        return GetIsTextTrimmed( textBlock );
    }

    Typeface typeface = new Typeface(
        textBlock.FontFamily,
        textBlock.FontStyle,
        textBlock.FontWeight,
        textBlock.FontStretch );

    // FormattedText is used to measure the whole width of the text held up by TextBlock container
    FormattedText formattedText = new FormattedText(
        textBlock.Text,
        System.Threading.Thread.CurrentThread.CurrentCulture,
        textBlock.FlowDirection,
        typeface,
        textBlock.FontSize,
        textBlock.Foreground );

    formattedText.MaxTextWidth = textBlock.ActualWidth;

    // When the maximum text width of the FormattedText instance is set to the actual
    // width of the textBlock, if the textBlock is being trimmed to fit then the formatted
    // text will report a larger height than the textBlock. Should work whether the
    // textBlock is single or multi-line.
    return ( formattedText.Height > textBlock.ActualHeight );
}

Now that the state can be determined, we need something to trigger that determination. Meet EventManager.RegisterClassHandler:

This code in the service class’s static constructor causes an event handler for the SizeChangedEvent (from FrameworkElement) to be registered for every instance of the TextBlock class. Additionally it allows me to specify that the event handler should be called even if the event has already been marked “handled” by a previous handler. I’m greedy like that. The actual event handler is fairly straight forward, just checking to make sure trimming is even possible before bothering to evaluate it:

That handler uses an additional function called SetIsTextTrimmed. In a read-write attached property, that function is required to be present as that’s what WPF uses to write a new property value. In our case the property is read-only, so I still went ahead and created the function but marked it private:

(This uses the DependencyPropertyKey instance rather than the DependencyProperty object because SetValue has 2 overloads, one that takes a DependencyProperty (for read-write properties) and one that takes a DependencyPropertyKey (for read-only properties). GetValue doesn’t care about writeability, so it only has a single version which expects a DependencyProperty instance.)

That actually covers the entirety of adding a (read-only) attached property to every TextBlock with the only usage requirements being (obviously) a reference to the TextBlockService assembly and (to use it from XAML) importing TextBlockService as a clr-namespace:

Once that’s imported, making use of the property is super easy (assuming you’ve figured out property triggers!)

And as always, the pudding:

Don’t know about you, but I find that incredibly cool. We were able to develop and build an attached property in a class in a separate assembly and all that was needed to make use of it from a consuming application is to import the class’ CLR namespace!

Now that we’ve built out our IsTextTrimmed attached property and shown how easy it is to use, let’s take it a step further and add an some additional custom TextBlock behavior into TextBlockService. I wanted to add an attached property that, when set to true for any given TextBlock, automatically enables a ToolTip that shows the hidden text whenever the text is being trimmed. I called that property TextBlockService.AutomaticToolTipEnabled and here’s how it works.

Like IsTextTrimmed, the AutomaticToolTipEnabled attached property does not have an associated dependency property that backs it. Unlike IsTextTrimmed, AutomaticToolTipEnabled is not a read-only property and, its implementation is much less involved since the property itself has no custom logic:

Some additional differences to note are:

1. The value defaults to true.
2. The value is automatically inherited by child elements.
3. The property can be attached to any DependencyObject.

Points two and three are incredibly powerful when it comes to applying this property to multiple controls which makes it even more wonderful that all of that behavior is provided for free by the framework.

OK, so we’ve created a new attached property – but by itself that’s not going to provide any additional behavior. There are a lot of ways you could go about this, but the way I felt was most reusable under any number of scenarios was to create a ResourceDictionary (TextBlockServiceDictionary.xaml) with some simple property triggers.

First off, if you’ve never worked with resource dictionaries before, just think of it as a collection of resources (styles, templates, etc). If you import a dictionary, you import all of the resources it contains.

Two things are crucial here: First, I’m importing the TextBlockService CLR namespace, which means I automatically have access to the IsTextTrimmed attached property and the new AutomaticToolTipEnabled attached property.

Second, I’ve defined a style using TextBlock as the target type but also giving it an x:Key identifier. As a result, this style is considered an “explicit” style and will not be automatically applied to TextBlocks – something has to explicitly cause the style to be applied. I did this for several reasons, but a major one is that there are a lot of intricacies in WPF’s style system and many of them come into play when you attempt to use multiple implicit styles for the same type. As a result, it’s just easier for everyone if this style remains explicit. (By the way, Ian Griffiths has a great blog entry which explains default styles that I ran across while researching some of those intricacies.)

I defined a multi-condition trigger that says (in prose form): whenever AutomaticToolTipEnabled is true and IsTextTrimmed is true, set the value of the ToolTip property for this TextBlock to the value of the TextBlock’s Text property.

Making use of that style is also quite straightforward, it just requires merging in the resource dictionary. In addition to pulling in the styles, you also need to cause your TextBlocks to use the style. That’s easy to do and it’s also easy to cause those styles to apply to all TextBlocks in a control, window or even application (if it’s a WPF application.)

(Note: the ResourceDictionary.Source property uses Pack URI syntax which is fairly well documented on MSDN.)

In this case I’m not only applying the TextBlockService style to all my TextBlocks (by attaching it to my style via the BasedOn attribute), but I’m also adding some additional global properties. Remember, since the default value of AutomaticToolTipEnabled is true, the above fragment will enable the full host of functionality my TextBlockService has to offer for every TextBlock in that Window.

Finally, the AutomaticToolTipEnabled attached property can also be used in a more granular fashion:

Well, this post has droned on long enough. If you’re interested, please take a look at the Sample project I included in this zip file (right click, Save As…, and change the extension to .zip – WordPress doesn’t permit uploading files with a .zip extension.)

And as I mentioned earlier, please feel free to leave questions, comments or suggestions. We’re all learning.

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.

The obvious compromise is to display a ToolTip containing the full text when the mouse hovers over it. Easy enough to do by simply using a Style to add a ToolTip whose text is bound to the control’s content (fairly well documented elsewhere.)

There is one big problem that crops up with the simple hover invoked ToolTip, though. When the text is not being trimmed, a popup is still displayed which contains no additional information and obscures whatever data happens to be underneath it. At best it’s annoying for the user and worse could get in the way enough to slow them down.

My first thought was that surely there’s a property on TextBlock that I can hook up a property trigger to and only enable the ToolTip when that property is set. Something like, “IsTextTrimmed” or “HasParagraphEllipsis”, etc. Unfortunately, no such luck. Even worse, because TextBlock is a “lookful” control I can’t just pick apart its ControlTemplate to get after the information I need. My last blog post described that problem in detail and the general approach taken to solve it.

In that post I presented a new custom control called EnhancedTextBlock which derives from TextBlock and uses reflection to provide an IsTextTrimmed read-only dependency property. Simply attaching a style trigger to that property offers the ability to easily adjust behavior based on whether or not the text is being trimmed. Here is a simple example of using that property to conditionally display a ToolTip:

Which produces something that works approximately like so:

Now that we’ve resolved conditional ToolTips in the general case, let’s get back to the WPF Toolkit’s DataGrid specifically.

First thing to realize is that we’re not going to be able to use the stock DataGridBoundColumn derived DataGridTextColumn because that control’s data template makes use of WPF’s TextBlock. Actually we could override the DataGridTextColumn’s ControlTemplate, but it turns out that’s not necessary! Vincent Sibal has a post describing a type of column control provided with the DataGrid called DataGridTemplateColumn. The sole purpose of that type is to allow us to provide our own custom data templates for both the view and edit case of any given column.

All that’s required is to first disable auto column generation (yes, unfortunately that’s one of the drawbacks of this approach) and second, add a column with a CellTemplate that includes our EnhancedTextBlock control:

Then spice it up with our style setters and triggers from above and we end up with this lovely bit of XAML:

And as always, I like to demonstrate my flare with visual aids:

Ultimately, it’s not a very tidy solution because the original trick to add an IsTextTrimmed property required creating a custom control rather than just using the built-in TextBlock and it makes use of reflection which means the EnhancedTextBlock can’t be used in partial-trust applications. Those issues aside, I have at least shown that if you’re willing to accept a few compromises and do some heavy lifting, deep customization of “lookful” WPF controls can be achieved. I’ve also shown that making use of custom controls in the WPF Toolkit DataGrid is really quite straightforward.

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.

Unlike most of the built-in WPF controls which derive from the Control class, TextBlock derives directly from the FrameworkElement class. MSDN says there are two standard methods for building FrameworkElement-based components: direct rendering and custom element composition. TextBlock performs direct rendering because it overrides the OnRender method and provides DrawingContext operations that explicitly define the component visuals. It also performs custom element composition because it uses other visual components like Flow Documents to provide its content. What’s most important to this discussion is simply that TextBlock does not derive from Control thus its visual appearance can not be changed by simply overriding its ControlTemplate (which is extremely easy to do via Expression Blend.) What this means for would-be direct rendering control customizers is that we’ve got a lot more work to do.

For instance, let’s say I want to display a different background in the TextBlock based on whether or not the text inside it is being trimmed. Telling the TextBlock to trim is simple enough:

Now whenever the TextBlock isn’t given enough space to display the full text, it will automatically clip the text and append an ellipsis (…). In order to provide a different background based on the state of a control, typically you can make use of a style trigger – which is exactly what I’ll attempt in this case:

Ah, right. It appears I’m missing an important bit of information. That big red question-mark above is referring to a dependency property on TextBlock to which we need to bind in order to determine whether the text is being trimmed. However, there is no such property documented for TextBlock. In actual fact, no such property exists at all, but I’ll get to that in a moment.

First I want to point out that the easiest way to resolve these situations for normal controls is to access their control template and start looking for relevant triggers and properties. In many cases you’ll find that the control provides exactly the information you need and it’s just a matter of applying a property trigger or a slightly altered template to get the desired behavior (or appearance.) For example, the control template for the CheckBox class is laid out on MSDN and with just a quick glance I see that the checkmark graphic is created by a border brush with a predefined path. Again, the ways in which you can customize that control’s appearance and behavior are virtually limitless.

Not so for the TextBlock. Because there’s no control template we’ll have to resort to poking around with Reflector (which, in case you hadn’t heard, is now owned by Red Gate Software, not Lutz Roeder.) I couldn’t possibly recall everything I did to arrive with this solution, apart from attaching a time-sliced video of my computer in action as I traversed up and down class hierarchies and ran innumerable expressions in my debugger’s Immediate Window. Suffice to say it was a lot of digging and comprehending and ultimately, a lot of guessing that led me to the conclusion that the simplest and most direct way to determine if a TextBlock is currently trimming the text is to compare the Width property of RenderSize with the Width property of a private instance field named “_firstLine” inside the OnRenderSizeChanged method.

For that to be possible, we’ll have to create a new control which derives from TextBlock and override its OnRenderSizeChanged. Additionally, reflection will be necessary in order to access private members of the base class. Sadly that does mean we’re going to deliberately degrade the control’s performance and, as such, this technique should only be used as a last resort. That’s not the only reason, though. Microsoft does not guarantee that the internal implementation details of any of its libraries won’t change drastically between versions. Which means even though this code works on .NET Framework 3.5 SP1, it may not work at all for the next service pack or major release. The code I’m presenting is not robust and should be augmented with mechanisms to deal with that scenario.

Speaking of code, here it is. In order to publish information about the control’s trimming status I added a read-only dependency property named IsTextTrimmed. I’m also caching the reflected type information so the only repeat performance hit is actually retrieving the values:

All that’s left is to modify our original markup to make use of the new and improved EnhancedTextBlock and replace the question-mark with our custom IsTextTrimmed property:

Finally, last but not least – evidence that the background color does change if (and only if) the text is being trimmed:

What’s left to say except, “That’s Hot!”

I have two versions: one for a base class and one for a derived class.  You use the Base Dispose Pattern snippet if your class is the first class in your hierarchy that implements IDisposable.  You use the Derived Dispose Pattern snippet if your class is derived from another class that implements IDisposable.  Just put your caret on a line within class scope, but outside method scope.  Hit the old “Ctrl K X”, select “My Code Snippets” from the context menu, then find the correct Dispose Pattern.  Don’t forget to add IDisposable to your class definition if it’s a base disposable class.

After the snippet is pasted you’ll have a couple sections to fill in.  The fill in sections are marked with comments.  The managed section is where you clean up your managed member data.  You would do this by calling Dispose() on IDisposable types and breaking references by setting them to null.  This makes it easier for the garbage collector to know what to clean up.  For example:

The unmanaged section is where you would clean up any native resources used by your class.  For example: you would close any open win32 handles there.

The disposed member variable can be used in debugging to find out if your object is being referenced after it’s been disposed.  This is a bad thing, but you can quickly check for it by using code like the following:

Copy these two files into your DocumentsVisual Studio 2008Code SnippetsVisual C#My Code Snippets folder:

Base Dispose Pattern.snippet:

Derived Dispose Pattern.snippet:

Enjoy!

Here’s a classic example from a simple drawing program:

The solution this ShapeFactory provides is pretty cool actually.  Now, if you need to add a new shape to the screen you just call one function.  Most of your code doesn’t have to know the details of the shape the user wants to create.  You just call the CreateObject() method passing the shape’s name and you get back a reference to generic shape object that can be stored in any shape container.  The shape container gets passed along and presumably gets a virtual Shape.Draw() method called on all of its contents in a foreach loop.

That’s really awesome until you want to add Triangles to your drawing program.  You probably start by adding a new Triangle.cs class file to your project.  Nice and OOP-y so far.  But then you have to crack open the ShapeName enumeration to add a new identifier for your Triangle class.  Next you have to crack open the switch statement of your ShapeFactory.CreateObject() method to add a case for your new Triangle class.  That’s two violations of the open/closed principle.  That’s not so awesome.  I like making as few changes as possible to existing code when adding features.
You’ll notice that the switch statement is really switching on a type.  That sounds familiar, like I’ve heard that idea before somewhere…  It’s too bad we don’t have virtual constructors, but in the meantime: you could add some static factory methods to the derived Shape classes.  Then, you could replace that switch statement with a map from ShapeNames to ShapeFactory Methods.  You would end up with something like this:

That’s pretty cool, we got rid of the switch statement.  Now you don’t have to crack open the ShapeFactory.cs file for every additional shape you add, but somewhere you still need to instantiate a ShapeFactory and populate its map with shapes types.  We haven’t solved the problem yet, just moved it:

We still have two places to change every time we want to add another shape type.  It would be really nice if we could just add a static constructor to each class derived Shape that would automatically register itself with a static ShapeFactory like this:

Unfortunately .NET doesn’t play that way.  A class’s Static constructor is not called until the first time a method of that class is called.  To my knowledge, there is nothing in C# that is equivalent to the static scope initialization of C++.  However, there is something C# has that may still be useful: reflection.  In preparation, let’s add a little searchable identifier to each class that’s derived from shape.  Like this:

Now let’s use a little reflection in the ShapeFactory to automatically load up its map:

We just got rid of the need to manually maintain the ShapeFactory’s list of shapes.  Pretty cool so far.  Now, what about that enumeration?  Let’s throw a little more reflection code at the problem:

So the enumeration is gone AND you can even ditch the ShapeName property attached to each Shape class.  Now, if you want to add a Triangle class all you need to do is drop in your Triangle.cs source file and you won’t have need to modified existing code.  Sweet!  The only thing you have to remember to do is include a CreateObject() method on each new shape.  But wait!  Reflection can help us here too:

Now we don’t have any special requirements of new Shape classes, we’ve ditched the extra factory method delegate, AND we can even use the most appropriate constructor for each object.  The only left to do is turn this factory into a library that works on any class hierarchy.  Let’s make it generic:

And this is how we’d use it as a Shape factory:

Now you’ve got a generic factory library in C# …and there’s still plenty of room to trick it out in my next blog post.  In the meantime, you are probably aware that the factory pattern is commonly combined with the singleton pattern.  I would personally recommend this article on the subject: http://www.yoda.arachsys.com/csharp/singleton.html

The first thing that needs to be addressed in this case is the fact that the Software Under Test (SUT) is actually an extension for a third-party application – the MSBuild engine. For someone new to unit testing, that may seem like an insurmountable hurdle, after all I certainly don’t want to have to invoke the entire build framework in order to unit test my 188 line custom task. Fortunately some smart people have already shown us that an easy way to deal with those scenarios is to introduce a “test double”, the options and vocabulary of which are well explained by Martin Fowler in this article.

While mock objects enable a deep level of testing and behavior assurance, manually creating them can be tedious depending on the object being mocked and the number of behavioral combinations involved. To help with that, many developers resort to frameworks such as TypeMock, Rhino Mocks, Moq, et al. Of those, TypeMock has the distinction of using aspect-oriented techniques to actually redirect calls from the real code allowing you to test units which are otherwise difficult or impossible to isolate. Fortunately, in this particular case we have some nice interfaces to work against and I’m not especially concerned about guaranteeing internal behavior of my code, so I will make use of a simple stub object and focus on validating known inputs against expected outcomes.

Since the SUT is targeting Team Build I’m going to stay in that arena and use the testing tools built into Visual Studio Team System 2008 Development Edition for this sample. However, the code and concepts could easily be adapted (in many cases with no change) to work in NUnit, MbUnit, or even xUnit.net. All of which can be integrated into Visual Studio either natively or via TestDriven.NET.

For this post I’m only going to include two tests, each of which proves that a valid input produces the expected result. What is missing from a thorough test suite is the slew of exception cases which should also be covered. For instance, what happens when an invalid input is applied, or when the environment doesn’t meet preconditions, etc. However, those tests are actually easier to write and for the sake of brevity I’ll leave them to the reader.

The first thing I did is create a new project in the build task solution called WixVarSubstitutionTests (there are many varied opinions on the pros and cons of separating tests from code, but at Tranxition we’ve decided to adopt that approach so I’m using it here.) Next add a project reference to the WixVarSubstitution project and make sure references are also present for Microsoft.Build.Framework, Microsoft.Build.Utilities.v3.5, and System.Xml.Linq. Finally, create a new C# class called WixVarSubstitutionTaskTest and we’re ready to write some tests.

Now that we’re ready to write some code, we need to build up a bit of infrastructure to enable our test methods. All test “fixtures” need to be adorned with the TestClassAttribute, and we’ll need to initialize a task instance for each test method:

Notice the BuildEngineStub reference? That is a stub object (test double) which we’ll use to isolate our task from the actual MSBuild engine. So the only thing left to do before writing our tests is to create that stub class:

Obviously, this stub doesn’t do a whole lot. That’s actually the point of a stub, to do as little as possible while providing properties and methods for the supported interfaces. In this case, the only interface we need to implement is IBuildEngine.

One issue you may run into occasionally with stub objects is that the method or property implementation provided causes behavioral issues somewhere down the line. For instance, originally I had the read-only property ProjectFileOfTaskNode return a null reference, however, during testing I discovered that the base Task class doesn’t support that and will throw an exception under certain scenarios. So I simply changed the return to an empty string and the problem went away. Just be aware that this is one of the known limitations with simple stub objects.

Because both of my test methods are going to need a temp file containing some pre-defined XML, I’ll use a helper method to set that up each time:

The call to Path.GetTempFileName actually creates an empty file in the current user’s temporary files folder and returns the full path as a string. Then a simple XDocument instance is built up using the convenient construction syntax. And finally the constructed XDocument is saved into the new temp.

At last we’ve reached the actual code for our test methods. The first just validates that when a single VariableDefinition is provided, that variable’s value in the XML file is correctly modified:

That test follows the common four-stage testing pattern:

1. Set up prerequisite objects
2. Call the method being tested
   _task.Execute()
3. Evaluate the results
   Load the temp file as an XDocument, retrieve the Processing Instructions, and assert that the value for the “Var1″ variable was changed.
4. Tear down the objects

The implicit step in there is #4, obviously, since we’re just allowing the garbage collector to handle object tear-down. It would probably be preferable to delete the temp file explicitly rather than letting it hang around after the test ends.

Now we have a test for providing a single variable definition, the next test will do the same but for providing multiple definitions:

And of course writing tests is not particularly useful if you don’t ever run them:

There are lots of additional tests needed, so I’ll just throw out a few obvious ones:

• File is unaffected when one/multiple VariableDefinitions are supplied but no variable names match
• Expected result when SourceFile is marked readonly
  • This actually turned up a problem for us with the custom task which had to be resolved
• “” when SourceFile doesn’t exist
• “” when SourceFile doesn’t contain a valid XML document

It may seem like it took a while getting there, but most of the infrastructure is actually provided for you by Visual Studio Team System if you right click on a class or method and select “Create Unit Tests…”. With a little practice, going from zero to 70% (or more) code coverage should take less than 15 minutes for most units of code. If it takes longer it may be worth refactoring your code or consider adopting a mocking framework to help take care of some of the manual set up.