In MSBuild, you can specify inputs and outputs for target so that the target is skipped when the outputs are more recent than the inputs. However, you get a strange behaviour when you put a <CreateProperty> task inside such a target.

Let’s look at the following MSBuild project:

<Project DefaultTargets="DoIt" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup> <WhyIsThisCreated>everything is okay</WhyIsThisCreated> </PropertyGroup>

<Target Name=”DoIt” DependsOnTargets=”CreateTestFiles; DoStuffMaybe”> <Message Text=”I say: $(WhyIsThisCreated)” /> </Target>

<Target Name=”CreateTestFiles”> <WriteLinesToFile Lines=”input” File=”input.txt” Overwrite=”true” /> <WriteLinesToFile Lines=”output” File=”output.txt” Overwrite=”true” /> </Target>

<Target Name=”DoStuffMaybe” Inputs=”input.txt” Outputs=”output.txt”> <Error Text=”We shouldn’t be there!” /> <CreateProperty Value=”oh my” Condition=””> <Output TaskParameter=”Value” PropertyName=”WhyIsThisCreated”/> </CreateProperty> </Target>

</Project>

This project creates two files, “input.txt” and “output.txt”. Then, the “DoStuffMaybe” target is tentatively run, but is skipped because “output.txt” is newer. We make super sure that this target won’t be run by adding an <Error> task in there.

But when you run this project, you get the following output:

Somehow, the <CreateProperty> task was processed, and the value of $(WhyIsThisCreated) was set to “oh my“!

I don’t really know what’s going on, but the solution to this problem is, as it is the case most of the time, to read the documentation. The <CreateProperty> page on MSDN informs us that another property is available on the task:

ValueSetByTask

Optional String output parameter.

Contains the same value as the Value parameter. Use this parameter only when you want to avoid having the output property set by MSBuild when it skips the enclosing target because the outputs are up-to-date.

If we replace TaskParameter=”Value” by TaskParameter=”ValueSetByTask” in the MSBuild project, we finally get the expected result:

This RTFM saying never gets old, does it?

I do almost all my development at home with Visual Studio Express. These products are wonderful and free. Well… granted, if they were not free, they would also be less wonderful too, probably. But they’re still great pieces of software, and I’m pretty sure they played a critical part in building the vibrant .NET community we have now. I wish Microsoft would also release a free “Express” version of Office, but I guess I can keep on dreaming for a while longer.

The Express versions of Visual Studio have of course less features than their “professional” counterparts. Some features, however, are present, but are just disabled by default. This is the case for the build configurations.

By default, you only get a couple of disabled combo-boxes, and you only know what’s supposed to be there if you’ve already worked with Visual Studio Professional. Visual Studio Express will switch between Debug and Release versions of your project depending on what you’re doing. For example, if you start the debugger by pressing F5, the “play” button, or choosing “Debug > Start Debugging“, it will switch to the Debug configuration. If you start the program without debugging by pressing Ctrl+F5 or choosing “Debug > Start Without Debugging“, it will switch to the Release configuration.

This is fine, but can be annoying at times, especially when you have inputs or outputs. For example, if you write a log file in the same directory as the executable, you’ll have to remember to open the correct one depending on whether you pressed F5 or Ctrl+F5. This can lead to situations where you’re looking for an error when there’s nothing wrong because you’re not looking in the correct directory!

Also, you might want more configurations than just Debug and Release. You might want completely different configurations. If you’ve worked with Visual Studio Professional, you may even be wondering what happened to the Configuration Manager in the Express versions.

To fix this, choose “Tools > Options“, and then check “Show all settings” on the bottom left corner of the dialog. You’ll get all the advanced options, including the “Projects and Solutions” category. Check the option called “Show advanced build configurations“.

Click OK, and look at those beautifully enabled combo-boxes!

Now you can set the current build configuration, and whether you start your project through the debugger or not won’t change the executable being launched.

Also, the Configuration Manager is back, and will let you create new configurations:

You will soon find that other parts of the UI have now more options related to build configurations, such as the Project Properties interface.

First, that's right, I said "cloud". In this day and age, you have to keep up with all the hype terms and buzzwords, otherwise you sound like you're from the 20th century.

Second, yes, here's anther blog about programming (mostly in .NET), even though there are thousands of those already. But Jeremy Miller, over at CodeBetter, posted about how I should really blog (well, not me specifically, but since I was reading, I'm pretty sure he was talking to me too):

I've been asked several times over the past month "Should I start a
blog?  What if…?"  The answer is yes, you should.  Or more
accurately, if you're interested in blogging you shouldn't feel afraid
to blog.

He then goes on and gives some pretty sensible "Good", "Bad" and "Ugly" points about starting a blog, along with demystifying the most common excuses for not starting a blog… And guess what? Well, too bad now, here's mine!

Now, however, I made Jeff Atwood sad and angry, as I've committed the sin of meta-blogging, but I guess you get a free pass for the first post, what with the need to introduce yourself and all.

Well, enough ranting for now. I hope to see you again later!