Jeremy Jee

Property overwrite behaviour

jeremyj — Wed, 22 Aug 2012 15:06:21 GMT

Originally posted on: http://geekswithblogs.net/jeremyj/archive/2012/08/22/property-overwrite-behaviour.aspx

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>

Pinning any folder location to the task bar Explorer jump list

jeremyj — Thu, 17 May 2012 21:33:12 GMT

Originally posted on: http://geekswithblogs.net/jeremyj/archive/2012/05/17/pinning-any-folder-location-to-the-task-bar-explorer-jump-list.aspx

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.

Debugging Castle WcfFacility installers

jeremyj — Tue, 15 May 2012 09:00:59 GMT

Originally posted on: http://geekswithblogs.net/jeremyj/archive/2012/05/15/debugging-castle-wcffacility-installers.aspx

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. Just pressing F5 with the web service set as a start up project causes the start up code to have already been run before the debugger attaches to the IIS worker process. Fortunately there is a simple way of causing the start up code to be re-run whilst remaining attached to the IIS worker process, so that you can step through your Castle installers and access the debugger views.

Once you've attached to the worker process under the debugger you can just rebuild the web service project to force IIS to re-initialize the newly built assembly when it is next exercised.

Once you've attached to the worker process under the debugger^[2] you can just rebuild the web service project to force IIS to re-initialize the newly built assembly when it is next exercised. The IDE won't normally let you do this^[3] so you have to build the web service project outside the IDE that is running the debugger. Of the various ways of doing this i'd like to suggest running the .csproj file directly in MSBuild.exe on the command line (because it means that just pressing the up arrow and enter in the command window will easily let you re-build). So with the debugger attached to the IIS worker process of your web service, just re-build the web service project on the command line e.g.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe My.Web.Service.csproj

As soon as you call any of its operations IIS will re-initialize the service causing the breakpoints to be hit. I hope this saved you some frustration as it took me a while to figure this one out. Happy Debugging.

[1] If you are using the Castle WcfFacility your My.Web.Service.svc will probably look something like this -

<%@ ServiceHost Language="C#"

Debug="true"

Service="My.Web.Service"

Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory, Castle.Facilities.WcfIntegration" %>

[2] I.e. either you've just hit F5 with the web service project as the start up project, or you've attached to the worker process by selecting it in the processes list (If the worker process isn't showing in the list it might be because it isn't yet running, the worker process hosting the application pool can be started just by calling one of the web service operations. Alternatively you might have to tick the box to include processes from all sessions.)

[3] I've definitely seen a bug in VS2010 SP1 where under rare circumstances it will let you, i have been able to do this once but now have no idea how to reproduce this issue now...