Aug 27, 2010

Import msbuid files

The import construct is the re-usability mechanism in msbuild. When an import element is encountered, these steps take place


  1. The working directory is changed to that of the imported project file.

  2. Project element attributes are processed.

    If a value is already assigned to DefaultTargets attribute, then this is ignored, otherwise it becomes the value of DefaultTargets. If InitialTargets attribute is present, then the list of targets will be appended to the current list of InitialTargets.



  3. Project element nodes are processed.

  4. The working directory returns to importing the previous value.

DefaultTargets and InitialTargets

DefaultTargets attribute is a list of targets to execute if no target is specified. The InitialTargets attribute is a list of tarets to be executed before any other targets. In the following example, the i1, i2, t1, t2 will be run in order

<?xml version="1.0" encoding="utf-8" ?>
<Project ToolsVersion="3.5" DefaultTargets="t1;t2" InitialTargets="i1;i2" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="t1">
    <Message Text="t1 is running" />
  </Target>
  <Target Name="t2">
    <Message Text="t2 is running" />
  </Target>
  <Target Name="i1">
    <Message Text="i1 is running" />
  </Target>
  <Target Name="i2">
    <Message Text="i2 is running" />
  </Target>
</Project>
   

Aug 26, 2010

property and item in msbuild

In msbuild, there are two way to save variable information, they are property and item. Here is an example how to define properties and items.


<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>
  <!--reference items-->
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Core">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Xml.Linq">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data.DataSetExtensions">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
  </ItemGroup>


 <PropertyGroup>
   <Pfile>Program.cs;Msbuild.xml</Pfile>
 </PropertyGroup>


But they have different usage. Normally property defines a single variable, if you redefine it, the old value will be overwritten, but Property can be also used as item list, if you want. For Item, it is a list, so you can define an item multiple times, each definition will add one item into the the list.
You can also pass property from the msbuild command line, like the following


MSBuild MyApp.csproj /t:Clean
                     /p:Configuration=Debug;TargetFrameworkVersion=v3.5

It is also different in the way to reference property and items. Here is an example how they are referenced.




 <Message Text="Pfile:@(MyFile->'%(FullPath)')" />

<!--Referencing a property -->
<Message Text="SchemaVersion: $(SchemaVersion)" />

<!-- Referenceing an item's metadata FullPath
 <Message Text="MyFile.FullPath: @(MyFile->'%(FullPath)')" />

<!--Referencing an item -->
 <Message Text="Reference Items: @(Reference)" />

<!--Referencing an item's medata data -->
 <Message Text="Reference Items: @(Reference->'%(RequiredTargetFramework)')" />





We can use three wildcard elements(?, *, **) to defined items, for example


<ItemGroup>
<MyFile Include="Program.cs;Msbuild.xml" />
<MyFile Include="*.doc" />
<MyFile Include="src\**\*.doc" />
<MyFile Include="**\*.cs" />
</ItemGroup>

After an property is defined, it can be also referenced in a new definition.


<ItemGroup> <AppConfigFileDestination Include="$(OutDir)$(TargetFileName).config"/>
</ItemGroup>

There are some special property and item medtadata. For property we call it reserved property, for more information see http://msdn.microsoft.com/en-us/library/ms164309.aspx. For item, we call it well-known item metadata, for more information see http://msdn.microsoft.com/en-us/library/ms164313.aspx


The "$" can also work with enviroment variables.


<Target Name="PrintSystemPath"> <Message Text="Path: $(Path)"/>
</Target>

Aug 5, 2010

Application Type in silverlgiht

When you create an silverlight app, by default a App.xaml file is created, and by default the class behind is the class or EntryPointType. This information is saved in the AppManifest.xml, so that when the xap file is downloaded, silverlight runtime will create an instance of that class. This class should derive from Application class. After the the application class is instantiated by the runtime, the most important job need to do in the constructor is to set the RootVisual property. You can do in code, or you can do it by loading a a xaml file. Visual studio use the second approach. And here is the pattern. The xaml file automatically create some code behind, which run the following code.


public partial class App1 : Application
    {
        private bool _contentLoaded;

        /// 
        /// InitializeComponent
        /// 
        [System.Diagnostics.DebuggerNonUserCodeAttribute()]
        public void InitializeComponent()
        {
            if (_contentLoaded)
            {
                return;
            }
            _contentLoaded = true;
            System.Windows.Application.LoadComponent(this, new System.Uri("/HelloWorldSilverlight;component/App1.xaml", System.UriKind.Relative));
        }


        public App1()
        {
            this.Startup += this.Application_Startup;
            this.Exit += this.Application_Exit;
            this.UnhandledException += this.Application_UnhandledException;

            InitializeComponent();
        }
}

XAML is faster than code in silverlight

Parsing XAML is faster than intantiating objects from code, because XAML parser does not create the API objects you use to interact with elements, but instead only create an internal representation. After you start interacting with elements from code, silverlight creates api objects that will slow down your application.