posts - 3 , comments - 3 , trackbacks - 0

My Links

News

Our new streamlined development process is composed of three stages -
  1. 1. Get it done
  2. 2. Just get it done
  3. 3. Is it done yet?

Article Categories

Archives

Post Categories

Wednesday, August 22, 2012

Property overwrite behaviour

I thought it worth sharing about property overwrite behaviour because i found it confusing at first in the hope of preventing some learning pain for the uninitiated with MSBuild :-)

The confusion for me came because of the redundancy of using a Condition statement in a _project_ level property to test that a property has not been previously set. What i mean is that the following two statements are always identical in behaviour, regardless if the property has been supplied on the command line -

  <PropertyGroup>
    <PropA Condition=" '$(PropA)' == '' ">PropA set at project level</PropA>
  </PropertyGroup>

has the same behaviour regardless of command line override as -

  <PropertyGroup>
    <PropA>PropA set at project level</PropA>
  </PropertyGroup>

 i.e. the two above property declarations have the same result whether the property is overridden on the command line or not.

To prove this experiment with the following .proj file -

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <PropA Condition=" '$(PropA)' == '' ">PropA set at project level</PropA>
  </PropertyGroup>

  <Target Name="Target1">
    <Message Text="PropA: $(PropA)"/>
  </Target>

  <Target Name="Target2">
    <PropertyGroup>
      <PropA>PropA set in Target2</PropA>
    </PropertyGroup>
    <Message Text="PropA: $(PropA)"/>
  </Target>

  <Target Name="Target3">
    <PropertyGroup>
      <PropA Condition=" '$(PropA)' == '' ">PropA set in Target3</PropA>
    </PropertyGroup>
    <Message Text="PropA: $(PropA)"/>
  </Target>

  <Target Name="Target4">
    <PropertyGroup>
      <PropA Condition=" '$(PropA)' != '' ">PropA set in Target4</PropA>
    </PropertyGroup>
    <Message Text="PropA: $(PropA)"/>
  </Target>

</Project>

Try invoking it using both of the following invocations and observe its output -

1)
>msbuild blog.proj /t:Target1;Target2;Target3;Target4

2)
>msbuild blog.proj /t:Target1;Target2;Target3;Target4 "/p:PropA=PropA set on command line"

Then try those two invocations with the following three variations of specifying PropA at the project level -

1)
  <PropertyGroup>
    <PropA Condition=" '$(PropA)' == '' ">PropA set at project level</PropA>
  </PropertyGroup>

2)
  <PropertyGroup>
    <PropA>PropA set at project level</PropA>
  </PropertyGroup>

3)
  <PropertyGroup>
    <PropA Condition=" '$(PropA)' != '' ">PropA set at project level</PropA>
  </PropertyGroup>

Posted On Wednesday, August 22, 2012 4:06 PM | Comments (1) | Filed Under [ MSBuild ]

Thursday, May 17, 2012

Pinning any folder location to the task bar Explorer jump list

This might not be news to you but for me this was a discovery i made only this week, yes how did i not know this before!

So I discovered how to pin any folder to the Windows Explorer jump list on the Windows 7 task bar. Any entries in the 'Frequent' menu can be pinned using its context menu, but a folder that does not appear in the 'Frequent' menu can still be pinned just by dragging its path from the address bar in the Explorer window onto the task bar icon. The pinned folders can then be accessed by using the context menu of the task bar button.

Actually for a few years now i've been in the habit of pinning frequently accessed folder locations into the Favorites list in the navigation pane, when using XP and also Windows 7. Perhaps my habits formed with Windows XP using folders pinned to the Favorites list in the navigation pane combined with task bar Toolbar folders is the reason why so much time spent using Windows 7 has gone by without without me using this handy feature, but now instead of adding a Toolbar folder i can just pin my RDP folder (and other folders like the SysinternalsSuite) to the Explorer jump list instead.


Posted On Thursday, May 17, 2012 10:33 PM | Comments (2) |

Tuesday, May 15, 2012

Debugging Castle WcfFacility installers

Stepping through IWindsorInstaller implementations in web services created using the WcfFacility[1] is not as immediately accessible compared to debugging the start up of a console application. The problem when trying to do this when just pressing F5 with the web service set as a start up project is that breakpoints set in the application initialization code will not be hit because the start up code has already been run before the debugger attaches to the IIS worker process. Fortunately there is

Posted On Tuesday, May 15, 2012 10:00 AM | Comments (0) |

Powered by: