Last time we talked about controlling the order that Targets execute.

There is one other way I want to mention that is pretty cool.  Try this…

<?xml version=“1.0″ encoding=“utf-8″?>

<Project xmlns=“http://schemas.microsoft.com/developer/msbuild/2003″>

    <Target Name=“Target1″ DependsOnTargets=“Target2″>

        <Message Text=“Target 1, Message1″ />

        <Message Text=“Target 1, Message2″ />

    </Target>

    <Target Name=“Target2″ DependsOnTargets=“Target3″>

        <Message Text=“Target 2, Message1″ />

        <Message Text=“Target 2, Message2″ />

    </Target>  

    <Target Name=“Target3″>

        <Message Text=“Target 3, Message1″ />

        <Message Text=“Target 3, Message2″ />

    </Target>

</Project>

Notice that the Target node supports a DependsOnTarget attribute.  Even though Target 1  was supposed to execute first, when you run it you get this output…

Microsoft (R) Build Engine version 4.0.30319.17929

[Microsoft .NET Framework, version 4.0.30319.17929]

Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/17/2012 4:45:26 PM.

Project “C:\Users\sspearman\Documents\MSBuild\test.build” on node 1 (default targets).

Target3:

  Target 3, Message1

  Target 3, Message2

Target2:

  Target 2, Message1

  Target 2, Message2

Target1:

  Target 1, Message1

  Target 1, Message2

Done Building Project “C:\Users\sspearman.UPWARD\Documents\MSBuild\test.build” (default targets).

Build succeeded.

    0 Warning(s)

    0 Error(s)

Time Elapsed 00:00:00.03

The DependOnTarget attribute ensured that Target 2 ran first.  But Target 2 needed Target 3 to run first.  So the execution order was Target 3, Target 2, and then Target 1. 

Pretty cool.

Last time we saw that an MSBuild file must have at least one Target node. 

But it can have as many Targets as you want…

<?xml version=“1.0″ encoding=“utf-8″?>

<Project xmlns=“http://schemas.microsoft.com/developer/msbuild/2003″>

    <Target Name=“Target1″>

        <Message Text=“Target 1, Message1″ />

        <Message Text=“Target 1, Message2″ />

    </Target>

    <Target Name=“Target2″>

        <Message Text=“Target 2, Message1″ />

        <Message Text=“Target 2, Message2″ />

    </Target>  

    <Target Name=“Target3″>

        <Message Text=“Target 3, Message1″ />

        <Message Text=“Target 3, Message2″ />

    </Target>

</Project>

Paste the above code snippet into Notepad++ and run it.  (If you don’t know how to run an MSBuild file from Notepad++ maybe you missed my 2nd Post.)

Here is the output…

Build started 10/15/2012 2:01:06 PM.

Project “C:\Users\sspearman.UPWARD\Documents\MSBuild\test.build” on node 1 (default targets).

Target1:

  Target 1, Message1

  Target 1, Message2

Done Building Project “C:\Users\sspearman.UPWARD\Documents\MSBuild\test.build” (default targets).

Build succeeded.

    0 Warning(s)

    0 Error(s)

Time Elapsed 00:00:00.05

Notice that MSBuild only ran the first Target.  It ran it because it was first. 

There are several other ways to configure which target gets run.

1.  You can change add a DefaultTargets as a project attribute.   Change the Project tag as follows…

<Project DefaultTargets=“Target2″ xmlns=“http://schemas.microsoft.com/developer/msbuild/2003″>

Now run it.  Notice that Target 2 is what gets run. 

You can also put multiple targets into that attribute…now change your Project node to be like this…

<Project DefaultTargets=“Target2;Target3″ xmlns=“http://schemas.microsoft.com/developer/msbuild/2003″>

Now when you run it both Target2 and Target3 are run. 

2.  One other way to control which Target runs is from the command line. 

In Notepad++ hit F6 and edit the Command to be the following…

“C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe” “$(FULL_CURRENT_PATH)”  /t:Target3

Test it and you will see that Target3 is run because of the /t switch.  And just as with the DefaultProjects, you can use this argument with a semi-colon delimited list of Targets.

Two things today…

First…so that we can have fun with MSBuild…here’s how you would configure Notepad++ to run MSBuild files…

1.        Hit F6 to open the Execute dialog of Notepad++

2.       Paste in the following into the Command(s) box…
“C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe” $(FULL_CURRENT_PATH)”
You need to verify your path to MSBuild but it should work for most of you unless you have a 32-bit machine.

3.       Click the Save… button and give the command a name.  I called it Run MSBuild.

4.       Click the Cancel dialog.

5.       Any time you want to run a build script just hit F6 and select Run MSBuild from the drop down.

Now on to MSBuild. 

Here is the anatomy of an MSBuild file…

IF you want to try it here is the raw text…

<?xml version=”1.0″ encoding=”utf-8″?>

<Project xmlns=”http://schemas.microsoft.com/developers/msbuild/2003″ />

</ Project>

Try to run it.  It won’t work.  All MSBuild files have one required target…it must have a … well a Target …

Add this into the project node…

                <Target Name=”test”>

                </Target>

If you build it now it will build.  Of course, it doesn’t do anything.

What is a Target.  A target is a container for a series of Tasks.  There are a lot of tasks that are built into MSBuild.  Add this to the target node…

<Message Text=”Hello Upward Developers” />

The Message task just emits a message to the host.  Your file should look like this and it should work.

<?xml version=”1.0″ encoding=”utf-8″?>

<Project xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>

                <Target Name=”test”>

                                <Message Text=”Hello Upward Developers” />

                </Target>

</Project>

You can add as many Tasks to a target as you would like.

TOP 10 REASON’S YOU SHOULD LIKE MSBUILD (David Letterman style except not humourous.)

10.  MSBuild.exe SHIPS with the .NET framework (since version 2).  So it is on everyone’s machine.  That means that it is almost as available as the command line.

9.  MSBuild uses XML files for it’s input format.  (here is the xsd for v4… C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Build.xsd)

8.  MSBuild does not just do builds…it is a complete automation engine.  (Especially if you install the Extension Pack)

7.  MSBuild only has 4 top-level node types you have to understand (Target, PropertyGroup, ItemGroup,Import).  This does not include the RootNode which is always Project.

6.  Well…that’s not quite true.  Inside each Target you can define multiple TASKS nodes…there are a lot TASKS built-in to MSBuild and the Extension Pack provides hundreds more.

5.  Creating custom tasks is incredibly easy.

4.  CSProj and VBProj files are just MSBuild files. Understanding MSBuild help you to understand the Visual Studio compile process.

3.  You can write and test your MSBuild files in Notepad++.  (Though without intellisense.)

2.  MSBuild will be the key tool for future Continuous Integration and Deployment initiatives…so understanding that will help you to understand, build, and troubleshoot for that initiative.

1.  MSBuild is COOL!  Add another tool to your toolset!

1.  In order to compile, XAML code must be mapped to .NET Namespaces.  Normally, when writing XAML you define XML namespaces to accomplish this.

The XML namespace that maps to various .NET controls is xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/[presentation”

To see the exact many to one mappings refer to page 23 of Windows Presentation Foundation Unleashed (WPFU).

A secondary namespace that is frequently mapped with a prefix (usually x) and that maps XAML language namespace to the System.Windows.Markup .NET namespace is xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”

2.  Some properties of a XAML object can be set using both Property Attribute syntax and Property Element syntax

The following two code XAML code snippets are equivalent.  

Property Attribute Syntax
<Button Content="OK" />

Property Element Syntax
<Button>
    <Button.Content>
        OK
    </Button.Content>
</Button>

Complex types will often require the use of the Property Element syntax

3.  For all of this to work, WPF defines Type Converters that can convert simple strings into .NET complex types.

For example, Type Converters convert the White string in the following XAML
<Button>
    <Button.Background>
        White
    </Button.Background>
</Button>
into the System.Windows.Media.SolidColorBrush type (specifically the static field of System.Windows.Media.Brushes.White)

4.  Type converters inherit from the System.ComponentModel.TypeConverters class.

Many type converters are available for common .NET classes such as Brush, Color, FontWeight, Point, and so on.   You can also write custom Type converters for your own custom types.

5.  Like, Type Converters, Markup Extensions exist to extend the expressability of XAML and WPF ships with multiple Markup Extensions built in. 

The MarkupExtension abstract class exists in the .  System.Windows.Markup namespace.  

For a list of MarkupExtension classes see the inside front cover of WPFU

Markup Extensions have a more explicit and consistent syntax and are the preferred way of extending XAML. 

Markup Extensions are used in XAML attributes (or elements) by referencing the values in curly braces ({}) as shown in the following XAML
<Button Background=”{x:Null}” />

In this example you cannot set a Button background to Null because this is not supported by the Type Converter.  But by using the NullExtension Markup extension you can.  Notice that in the XAML you truncate the Extension part of the Markup extension class.

This feature of Notepad++ save me an hour today!  It is easier to show it to you than tell you about it.

http://www.computerperformance.co.uk/powershell/powershell_printers.htm

using System;
using Quartz;
using Quartz.Impl;

namespace goAlarmsCS
{
    class alarmJob : IJob
    {
        public alarmJob()
        {  
        }

        #region IJob Members

        public void Execute(JobExecutionContext context)
        {
            QuartzAlarmScheduler qas = QuartzAlarmScheduler.Instance();
            qas.Execute(context.Trigger.Name);
        }

        #endregion
    }
}

…you should still use software development best-practices, according to this excellent blog post.  It is the definition of “professional.”

This is good stuff.  And here is his list of best practices defined at the end of the post:

• Yes, you need to use source control.
• Yes, you need to automate the build.
• No, you shouldn’t be releasing the assemblies compiled on your machine.
• Yes, you need to stop writing long methods and pay attention to code complexity.
• Yes, you need to buy your developers the best tools available.
• No, you don’t need to write your own logging framework.
• Yes, you should be practicing test first development.
• No, continuing to ship known defects is not acceptable.
• Yes, you should understand who your customer is

Seth