I have previously blogged about some new features in MSBuild 4.0 at:

Besides inline tasks there are a set of other new features including Property Functions. In this post we will discuss property functions and how you might use them in your build scripts. With property functions you can call an instance method of the string object on properties now.

The syntax will be in the format $(PropertyName.MethodName([Parameters])) when you want to invoke a string method. Parameters in the previous expression is optional. For instance if you need to call the Trim method then you do not need to supply any arguments. Take a look at the snippet below to get a better feel for how to use these new features.

         DefaultTargets="Demo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  
    This is a sample string
       This is a sample string   
    
    $(SampleString.Substring(0,4))
    $(SampleString.Contains("This"))
    $(SampleString.Contains("this"))
    $(SampleString.CompareTo($(SampleString)))
    $(SampleString.CompareTo("string"))
    $(SampleString.Insert(2,"INSERTED"))
    $(SampleString2.Trim())
  
  
  
    
    
    
    
    
    
    
    
  

In this snippet I am calling various string methods on the properties defined. The results of executing this are shown in the fragment below.

Demo:
  SampleString: This is a sample string
  Sub04: This
  Contains01: True
  Contains02: False
  CompareTo01: 0
  EndsWith01: 1
  Insert01: ThINSERTEDis is a sample string
  Trim01: This is a sample string

This is just one way that you can use property functions. We can also call a static methods (and properties) on a known set of classes. See http://msdn.microsoft.com/en-us/library/dd633440%28VS.100%29.aspx for the list of complete classes that you can call static methods on. The syntax is as follows $([Full-Class-Name]::Method(Parameters)) or if you are calling a property you just leave off the (Parameters). To demonstrate this I have created the following file.



  
    
    $([System.DateTime]::Now)
    $([System.Math]::Pow(2,3))
    $([System.IO.Path]::GetTempFileName())
  
  
  
    
    
    
  

And the result is:

Demo:
  Now01: 3/6/2010 7:31:23 PM
  Pow01: 8
  TempFile01: C:\Users\Ibrahim\AppData\Local\Temp\tmp4C1.tmp

Similar to this you can call a handful of MSBuild methods. Those methods are documented at http://msdn.microsoft.com/en-us/library/dd633440%28VS.100%29.aspx. You would use a similar syntax to access those which is $([MSBuild]::Method(Parameters)). To show you those take a look at the follwing sample file.



  
    $([MSBuild]::Add(5,9))
    $([MSBuild]::Subtract(90,768))
    $([MSBuild]::Multiply(4,9))
    $([MSBuild]::Divide(100,5.2))
  
  
  
    
    
    
    
  

I will leave it up to you to execute that file to see the result, but you can probably figure it out :)

Sayed Ibrahim Hashimi


Comment Section

Comments are closed.


This weekend I will be speaking at the South Florida Code Camp. This has historically been a very popular event (>500 people) with a lot of good speakers.

I will be presenting 2 topics there, the abstracts are below.

MSBuild 4.0 What’s New

MSBuild, the Microsoft Build Engine, was first introduced with Visual Studio 2005. This was MSBuild 2.0, and it was delivered along with the .NET Framework 2.0. The next major release of MSBuild, version 3.5, was introduced for Visual Studio 2008 and was deployed with the .NET Framework 3.5. Now the third major version, 4.0, is being introduced with Visual Studio 2010, and in concert with previous releases is being shipped with the .NET Framework 4.0. In this session we will talk about the new features included with MSBuild 4.0 and how it can make your MSBuild files better. The topics we will talk about will include.
•    Inline Tasks
•    Property Functions
•    Item Functions
•    Before / After Targets
•    Support for C++ projects (both native and managed)
•    New Object Model

Simplifying deployments with MSDeploy and Visual Studio 2010

In this session we will demonstrate how to greatly simplify deployments of web applications using MSDeploy. MSDeploy is shipped with Visual Studio 2010 and is available as a separate download. Visual Studio 2010 has enhances support for MSDeploy and we will go over many of those details in this session. We will also be discussing how MSDeploy can be used as a stand alone tool outside of Visual Studio 2010. So if you are not able to upgrade to Visual Studio 2010 but developing web applications this is still a great for you.

If you are in the South Florida area this is definitely an event that you don’t want to miss out. Please stop by and see me!

Sayed Ibrahim Hashimi


Comment Section

Comments are closed.


If you are an MSDN subscriber you can now download Visual Studio 2010 Release Candidate as well as the TFS 2010 Release Candidate. You can read Brian Hurry's post about the release. Here are some key dates, if you are an MSDN subscriber you can get it now, and if not then you will have to wait until Feb 10. Still no word on when the RTM will ship, but hopefully it will be soon so that more organizations will begin adopting it and we can leave VS 2008 in the dust. Since the Visual Studio 2010 Launch is on April 12, 2010 it should be just around the corner. You should be aware that the launch date doesn't always equal the release date. Launch date is set by marketing to start the launch events, but the RTM date can vary, but will typically be in that same ball park.

Sayed Ibrahim Hashimi


Comment Section

Comments are closed.


This post contains based on .NET 4.0 Beta 2 and Visual Studio 2010 Beta 2 which may change.

The other day I wrote my first post on Inline Tasks in MSBuild 4.0, this post will add onto that topic. In the previous post we covered some basics, but there were a lot that was skipped. Last time we demonstrated how to pass parameters but we never declared what type those parameters were. If you declare a parameter and leave off the type, then it will be declared as a string. If you need to declare parameters of other types then you need to use the ParameterType attribute on the parameter. You have to pass in the full name of the type to be used. For example if you need to declare an int you must use System.Int32, not int and not Int32 but System.Int32. It would be good if they supported aliases like int, string, long, etc but right now they don't. Below you'll find a new inline task which can be used to perform a substring. I've placed this in a file named IT-Substring-01.proj.

 

 

    TaskName="Substring"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

     

     

     

   

   

     

       

        if (Length > 0)

        {

            Result = Input.Substring(StartIndex, Length);

        }

        else

        {

            Result = Input.Substring(StartIndex);

        }

        ]]>

     

   

 

 

 

   

     

   

   

   

   

     

   

   

   

 

In the task above I have declared 4 parameters, from those two have the type specified to be int. If we execute the Demo target here is the result.

From the above image you can see that the task performs the actions requested. One thing to make a mental note of above is my usage of a CDATA tag to wrap the definition of the task. I would suggest that you do so for all inline tasks that you write.

The types supported for parameters on inline types are the same for normal types. For a detailed account of that see my book, but as a general guideline it accepts string, primitive types, ITaskItem, and arrays of all three.

Let's see how we can use an array in an inline task. I created a simple task which will create a list of Guids and place them into an array and return the result back to the calling MSBuild script, the file I placed this is in named IT-CreateGuid-02.proj. The contents of that file are shown in the snippet below.

 

 

    TaskName="CreateGuid02"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

     

   

   

     

       

            List guids = new List();

            for (int i = 0; i < NumToCreate; i++)

            {

                guids.Add(Guid.NewGuid().ToString());

            }

            Guids = guids.ToArray();

        ]]>

     

   

 

 

 

   

     

   

   

 

   

     

   

   

   

 

 

Above you can see that I declared the parameter Guids as System.String[]. I typically prefer to use generic lists instead of arrays so in my task definitions I will use a list and then just call ToArray when I assign the output parameter. Here is a nifty, but very simplistic task. Given an item list, it will filter them based on a Regular Expression passed in.

 

 

    TaskName="FilterList"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

     

     

   

   

     

     

       

            var results = (from l in ListToFilter

                           where Regex.IsMatch(l.ItemSpec, Filter)

                           select l).ToList();

 

            FilteredList = results.ToArray();

        ]]>

     

   

 

 

 

   

   

   

   

   

   

 

 

 

   

     

   

   

   

   

   

      <_filteredList Remove="@(_filteredList)" />

   

 

   

   

     

   

   

 

Here you see that you can you can perform LINQ queries inside of inline tasks without any additional setup. Here is the result of executing the Demo target on this script.

Another thing to notice is the Using element under the Task element. This injects a Using statement into the generated class for the given namespace. If you need to reference another assembly you can do this with the Reference element under the Task element.

 

Sayed Ibrahim Hashimi


Comment Section

Comments are closed.


MSBuild 4.0: Inline Tasks

Comments [0]

This post contains based on .NET 4.0 Beta 2 and Visual Studio 2010 Beta 2 which may change.

If you didn't already know, MSBuild will have a new version shipped with .NET 4.0 (Visual Studio 2010 will use this new version). I will cover many of those features here. This is the first in a series of posts that I will make regarding MSBuild 4.0. One of the big additions to MSBuild 4.0 is Inline Tasks. I'm pretty excited about this new addition. The story before was if you wanted to perform any action it was always through a Task. Which worked pretty well, but the major drawback is that the tasks needed to be written in code and then compiled into an assembly in order for it to be used. What this meant was if you wanted to perform an action (however simple) that wasn't covered out of the box you would have to look for 3rd party tasks or write one yourself. This is time consuming and can be tricky from a "deployment" perspective. Now with Inline Tasks you can declare the behavior of the task right inside of the MSBuild file itself.

Inline Task

The way that Inline Tasks are supported is by using the UsingTask XML element. This element was around before but it has some new options. If you read my book, you probably saw a few different Hello World tasks that I created. In order to demonstrate Inline Tasks I have taken a similar set of examples. Take a look at the project file (IT-HelloWorld-01.proj) below.

 

 

    TaskName="HelloWorld"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

        Log.LogMessage("Hello World!");

      

   

 

 

 

   

 

 

For this basic inline task here are the key things to note, the name of the task is specified in the TaskName attribute. You will use this like you would any other task inside of targets. The definition of the task will be contained in the Code XML element. In order to call that task, I use the syntax inside of the Demo target. The same exact way "classic" tasks are called. Here is the result.

The result shown above is as expected.

Inline Task with Parameters

You can also make inline tasks with parameters, both required and optional. Here is an example (IT-HelloWorld-02.proj) with a lone required parameter.

 

 

    TaskName="HelloWorld"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

   

   

     

        Log.LogMessage(string.Format("Hello {0}",Name));

     

   

 

 

 

    Sayed

 

 

 

   

 

 

 

   

   

 

 

If you take a look at the UsingTask declaration above you will see that I included a ParameterGroup element. All parameters must be included under that element. In this case we just have one. If we execute the Demo target the result will be as follows.

We can see that the message was sent to the console as we expected. You can execute the DemoWithNoName if you are interested in verifying that MSBuild will ensure that required parameters are set.

Inline Tasks with Output Parameter

You can also create your own inline tasks which have one or more output parameters. You will define those output parameters under the ParameterGroup element and use the Output="true" attribute. Take a look at IT-HelloWorld-03.proj below.

 

 

    TaskName="HelloWorld"

    TaskFactory="CodeTaskFactory"

    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >

   

     

      

   

   

     

        TaskMessage = string.Format("Hello {0}",Name);

        Log.LogMessage(TaskMessage);

     

   

 

 

 

    Sayed

 

 

 

   

     

   

   

 

 

In this example I created a HelloWorld task to output the entire message back to the calling MSBuild task invocation inside the target. This output parameter is the TaskMessage parameter. Inside the Demo target I call the task and then print the value that was passed back from the task. Here is the result of that.

From here we can see that the value was correctly sent back to the script.

 

There is a lot more to inline tasks and I plan on covering more features very soon here, but this should get you started.

 

Sayed Ibrahim Hashimi


Comment Section

Comments are closed.