We add 3 new boolean properties to our Task class, a Milestone property for tasks that are milestones, a Summary property for tasks that represents a group of tasks, and a Critical property for critical tasks.

 public bool Milestone { get; set; }
 public bool Summary { get; set; }
 public bool Critical { get; set; }

and we change the Linq query to fill these properties from the XML file:

project.Tasks
      = (from task in document.Descendants("{http://schemas.microsoft.com/project}Task")
          where (int)task.Element("{http://schemas.microsoft.com/project}ID") != 0
          select new Task()
           {
               Project = project,
               UID = (int)task.Element("{http://schemas.microsoft.com/project}UID"),
               Name = (string)task.Element("{http://schemas.microsoft.com/project}Name"),
               Start = (DateTime)task.Element("{http://schemas.microsoft.com/project}Start"),
               Finish = (DateTime)task.Element("{http://schemas.microsoft.com/project}Finish"),
               Milestone = (bool)task.Element(”{http://schemas.microsoft.com/project}Milestone”),
               Critical = (bool)task.Element(”{http://schemas.microsoft.com/project}Critical”),
               Summary = (bool)task.Element(”{http://schemas.microsoft.com/project}Summary”),
               PredecessorLinks =
                         (from link in task.Descendants(”{http://schemas.microsoft.com/project}PredecessorLink”)
                         select
                           new PredecessorLink
                           {
                               PredecessorUID = (int)link.Element(”{http://schemas.microsoft.com/project}PredecessorUID”)
                           }).ToList() 

              }).ToList();

Now that our Task has 3 new properties we can modify the style of nodes with data triggers to take advantage of this. The data trigger in a style will allow changing the style depending on data. In our case, milestones will be white, summary tasks in blue and all critical tasks in red.
Here is the new style for nodes with 3 data triggers.

 <Style TargetType="{x:Type ilog:Node}" >
     <Setter Property="Background" Value="#FFF0A5"/>
     <Setter Property="BorderBrush" Value="#468966"/>
     <Setter Property="BorderThickness" Value="1"/> 

     <Style.Triggers> 

        <DataTrigger Binding=”{Binding Summary}” Value=”true”>
           <Setter Property=”Background” Value=”blue”/>
        </DataTrigger> 

        <DataTrigger Binding=”{Binding Milestone}” Value=”true”>
           <Setter Property=”Background” Value=”white”/>
           <Setter Property=”CornerRadius” Value=”10″/>
        </DataTrigger> 

        <DataTrigger Binding=”{Binding Critical}” Value=”true”>
           <Setter Property=”Background” Value=”red”/>
        </DataTrigger> 

      </Style.Triggers>
 </Style>

The definition of data triggers is very straight forward. The data trigger evaluates the value specified by the Binding (for example {Binding Summary}) and see if it matches the value specified in the Value property (in our case true), if the two things match, then the setters are applied, in our case the background color is changed.

Two things to understand here, first the binding specified in the data trigger is evaluated on the data context of the Node. In the Diagram control the data context for node is the item in the data source, in our case a Task object, that is why I can directly bind to the properties of a Task (like {Binding Milestone}), no need to specify any source for the binding.
The second point is the order of the triggers. I place the last trigger that changes the background to red for critical tasks at the end because a milestone or a summary task can also be critical. The last data trigger will win in such a case and thus all critical tasks will be red.
We now have the following result, showing the critical tasks :

We can also use data triggers in data templates. For example, for a milestone task it is not necessary to display the start and finish date since the dates are the same.
In order to achieve this we add a data trigger in the data template of nodes:

<DataTemplate x:Key="TaskTemplate">
  <Grid  Margin="5" MaxWidth="150" x:Name="grid">
    <Grid.RowDefinitions>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
    </Grid.RowDefinitions>
    <TextBlock
       x:Name="header" Grid.Row ="0"
       Text="{Binding Path=Name}"
       TextWrapping="WrapWithOverflow"
       Foreground="#FFB03B"
       FontWeight="Bold"/>
    <StackPanel x:Name="startField"  Grid.Row ="1" Orientation="Horizontal">
      <TextBlock x:Name="startLabel" Text="Start:"/>
      <TextBlock Text="{Binding Path=Start}"/>
    </StackPanel>
    <StackPanel x:Name="finishField" Grid.Row ="2" Orientation="Horizontal">
      <TextBlock x:Name="finishLabel" Text="Finish:"/>
      <TextBlock Text="{Binding Path=Finish}"/>
    </StackPanel>
  </Grid>
  <DataTemplate.Triggers>
    <DataTrigger Binding=”{Binding Milestone}” Value=”true”>
        <Setter TargetName=”startLabel” Property=”Text” Value=”Milestone Date:”/>
        <Setter TargetName=”finishField” Property=”Visibility” Value=”Collapsed”/>
    </DataTrigger>
  </DataTemplate.Triggers> 
</DataTemplate>

The trigger here applies to task with Milestone property set to true, it changes the label of the start date to “Milestone Date” and hides the part that corresponds to the end date.

Here is the result for a one of the milestones:

Let’s now use data triggers for links. In order to make the critical path more obvious, we will try to draw the links between two critical tasks in red. Painting a critical task in red was easy; we have simply added a data trigger in the style. For links it is a little bit more complex because there is no instance in the data source that represents a link. To answer this problem, The Wpf diagram component creates a convenient data context for each link that is an instance of the class Diagram.LinkContext. This class has two properties, StartItem and EndItem that represents the items in the data source (for us the tasks) that are at the displayed at the begining and end of the link. Thus we can easily use data triggers in a link of the diagram.
We want the link to be red if both the origin and destination tasks are critical, so we need to use a MultiDataTrigger that is a kind of data trigger with multiple conditions:

Here is the new style for links:

<Style TargetType="{x:Type ilog:Link}" >
  <Setter Property="Radius" Value="10"/>
  <Setter Property="Stroke" Value="#FFF0A5"/>
  <Setter Property="StrokeThickness" Value="2"/>
  <Setter Property="StartArrow">
    <Setter.Value>
      <ilog:LinkArrow  Fill="White"  Shape="Circle"/>
    </Setter.Value>
  </Setter>
  <Setter Property="EndArrow">
    <Setter.Value>
      <ilog:LinkArrow Fill="{x:Null}"  Shape="Open"/>
    </Setter.Value>
  </Setter>
  <Style.Triggers>
    <MultiDataTrigger>
      <MultiDataTrigger.Conditions>
        <Condition Binding=”{Binding StartItem.Critical}” Value=”true”/>
        <Condition Binding=”{Binding EndItem.Critical}” Value=”true”/>
      </MultiDataTrigger.Conditions>
      <Setter Property=”Stroke”  Value=”red”/>
      <Setter Property=”StrokeThickness”  Value=”3″/>
    </MultiDataTrigger>
  </Style.Triggers>
</Style>

I hope I have shown how the combination of the diagram control with its graph layout algorithms and the styling and templating features of WPF can help to easily create nice looking diagrams.

If you want to test the project, here is the source code and Visual Studio 2008 solution. In order to compile and run you will need and evaluation of ILOG Diagrammer for .NET that you can get at http://www.ilog.com/products/diagrammernet/eval.

1. Authoring licensed components.
2. Creating licences at design-time.
3. Creating licences at compile-time.
4. Creating licences at run-time.

Authoring licensed components

I’ll not spend too much time on that topic, as it’s widely documented on the web (see for example this article).

The process is simple. After creating your component, you have to:

1. Apply a LicenseProviderAttribute to the class.
2. Call LicenseManager.Validate from the class constructor to get a licence.
3. Dispose the licence in the component finalizer.

The licence provider specified by the LicenseProviderAttribute attribute in step 1 is used during step 2: Calling LicenseManager.Validate in your component constructor will create an instance of this license provider, and will call its GetLicense method to get a licence. If no licence can be found, LicenseManager.Validate will throw an exception, making your component unusable.

Specifying the licence provider has also another usage: It’s used by Visual Studio to know whether a component is licensed or not. Indeed, as we’ve seen in the first part of this article, Visual Studio manages a licenses.licx file containing all the licensed components used in a project.

Microsoft provides the LicFileLicenseProvider class, a ready-to-use licence provider. But if you need to implement your own logic, you have to create a new licence provider by subclassing the LicenseProvider class. That’s what we’ve done here at ILOG for our .NET products (ILOG Gantt for .NET and ILOG Diagrammer for .NET) because we wanted to implement ILM (ILOG License Manager). Subclassing the LicenseProvider class is relatively simple, as you just need to override the GetLicense method. We’ll see later how to implement this method.

The LicenseProvider will be used in three different contexts:

• At design-time.
• At compile-time.
• At run-time.

Creating licences at design-time

Here we assume that we’re building an application that contains licensed components using Visual Studio. The typical way to do it is to drag and drop a toolbox item onto the design surface, which results in the instantation of the component. As the licence checking is done in the component constructor, a licence has to be provided at that time. Let’s see how to handle this case in the LicenseProvider.GetLicense method through a partial implementation:

public override License GetLicense(
    LicenseContext context,
    Type type,
    object instance,
    bool allowExceptions)
{
    //
    // The context parameter indicates the context
    // in which the component is used.
    //
    bool runtime = context.UsageMode == LicenseUsageMode.Runtime;                 

    if (runtime)
    {
        //
        // Will see later what to do here
        //
    }
    else
    {
        //
        // Here we are designing our application, so we need to
        // get a licence that we will store in the context.
        //                 

        //
        // We're calling the GetDesignTimeLicenseKey() method to get a licence.
        // The code for this method is not provided here, but a simple
        // implementation could be to look in the registries or in a specific
        //  file to check that a valid licence has been installed on this computer.
        // The implementation of this method depends on the licensing schema
        // you want to set up.
        //
        string licenseKey = GetDesignTimeLicenseKey(type);                 

        //
        // If no licence was found, error
        //
        if (licenseKey == null)
        {
            if (allowExceptions)
                throw new LicenseException();
            return null;
        }                

        //
        // Save the licenseKey in the context. It will be possible at runtime to
        // retrieve it.
        //
        context.SetSavedLicenseKey(type, licenseKey);                

        //
        // We create and return a new CustomLicence object using
        // the licenseKey. The code for the CustomLicense class is
        // straightforward, as it's a simple implementation of the License
        // class. It's given below.
        //
        return new CustomLicense(licenseKey);
    }
}               

class CustomLicense : License
{
    private string _key;
    public CustomLicense(string Key)
    {
        _key = key;
    }
    public override string LicenseKey
    {
        get
        {
            return _key;
        }
    }
}

To sum up, the creation of a licence at design time is a 3 steps process:

1. Get the licence key installed on the computer. It can be a licence file, or a registry key…It depends on the way you want to manage the installation of licence keys on development computers.
2. Sets the licence key into the licence context. This will make it possible to retrieve the licence key at runtime.
3. Create a License object using this licence key.

Note : The License class is a .NET class that encapsulates the licence key, which is a simple string.

The LicenseContext used by Visual Studio and passed as the first parameter of the GetLicense method is said to be a “design-time” context, that is, a context whose UsageMode property returns LicenseUsageMode.DesignTime.

Creating licences at compile-time

Once the application has been designed, it needs to get compiled. As we’ve seen in the first part of this article, Visual Studio invokes the licence compiler to compile the licenses.licx file into an assembly resource file.

The licence compiler takes a .licx file as input and produces a resource file as output. It parses the .licx file and create an instance of each type found in it. The LicenseContext used by the licence compiler is a design-time context, an instance of the DesignTimeLicenseContext class. For each component created, a corresponding licence is also created and is stored in the licence context in a hash table. This hash table is then dumped it into a resource file.

This resource file will be used differently at run-time depending on the application type your’re creating, as explained in the first part of this article.

Creating licences at run-time

As for design-time and compile-time, licence checking will take place at run-time each time a licensed component gets instantiated. The difference is that the LicenseContext used will be a run-time licence context, that is, a context whose UsageMode property returns LicenseUsageMode.RunTime. This context will be able to retrieve the licences compiled with the licence compiler. Here is the a partial implementation of the LicenseProvider.GetLicense method:

public override License GetLicense(
    LicenseContext context,
    Type type,
    object instance,
    bool allowExceptions)
{
    //
    // The context parameter indicates the context in
    // which the component is used.
    //
    bool runtime = context.UsageMode == LicenseUsageMode.Runtime;                 

    if (runtime)
    {
        //
        // At runtime, look into the context to find the licence.
        // Depending on the application type, the context may look into
        // the application resources (Windows Forms), or the
        // App_Licenses.dll assembly (Web sites)...
        //
        string licenceKey = context.GetSavedLicenseKey(type, null);                

        if (licenceKey != null)
            return new CustomLicense(licenceKey);           

        if (allowExceptions)
            throw new LicenseException();
        else
            return null;
    }
    else
    {
        //
        // Already covered in the "design-time" section
        //
    }
}

The interesting part here is the call to the LicenseContext.GetSavedLicenseKey method. It will look into the context to see if a licence for the specified type can be found. Depending on the application type (assembly based applications, web sites, windows forms hosted in IE), the context will look in the appropriate location to find the licence.

Conclusion

We’ve seen in this article how the licences were created during the three phases of an application development: design-time, compile-time, run-time. Of course the code given was simpified for the purpose of this article, but you can imagine to enrich it by adding cryptography or anything that can make your licence management more secure.

The XML that you can export from Microsoft Project 2003 contains all the information on the project plan such as all the tasks, resources, calendars and more. Here we will only take care of the tasks and the predecessor constraints between tasks. Predecessor constraints are the constraints between tasks such as “task A starts after task B”. The graph that we will create will have nodes representing the tasks and links representing the predecessor constraints between tasks. The result will give something similar to the “Network Diagram” view of Microsoft Project that represents nicely the flow of tasks in the project plan.

First of all, a few words on the Microsoft Project XML format. The format defines a <tasks> tag that contains all the tasks, each task is represented by a <task> tag that contains the task information.

<Project xmlns="http://schemas.microsoft.com/project">
...
<Tasks>
  <Task>
    <UID>Unique id of task</UID>
    <Name>The name</Name>
    <Start>The start date </Start>
    <Finish>The finish date</Finish>
     ...
    </Task>
</Tasks>
...
</Project>

When a task has predecessors, a <PredecessorLink> tag appears for each predecessor in the <task> tag:

<Task>
  ...
  <PredecessorLink>
    <PredecessorUID>1</PredecessorUID>
    <Type>1</Type>
  </PredecessorLink>
  ...
</Task>

public class Project
{
    public List<Task> Tasks { get; set; }
} 

public class PredecessorLink
{
    public int PredecessorUID { get; set; }
} 

public class Task
{
    public Project Project { get; set; }
    public int UID { get; set; }
    public string Name { get; set; }
    public DateTime Start { get; set; }
    public DateTime Finish { get; set; }
    public List<PredecessorLink> PredecessorLinks { get; set; }
}

XDocument document = XDocument.Load("./Engineering.xml");
Project project = new Project();
project.Tasks
      = (from task in document.Descendants("{http://schemas.microsoft.com/project}Task")
          where (int)task.Element("{http://schemas.microsoft.com/project}ID") != 0
          select new Task()
           {
               Project = project,
               UID = (int)task.Element("{http://schemas.microsoft.com/project}UID"),
               Name = (string)task.Element("{http://schemas.microsoft.com/project}Name"),
               Start = (DateTime)task.Element("{http://schemas.microsoft.com/project}Start"),
               Finish = (DateTime)task.Element("{http://schemas.microsoft.com/project}Finish"),
               PredecessorLinks =
                         (from link in task.Descendants("{http://schemas.microsoft.com/project}PredecessorLink")
                         select
                           new PredecessorLink
                           {
                               PredecessorUID = (int)link.Element("{http://schemas.microsoft.com/project}PredecessorUID")
                           }).ToList() 

              }).ToList();

<Window x:Class="CriticalPath.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:ilog="http://www.ilog.com/diagrammer.net/2008"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <ilog:Diagram x:Name=”diagram”/>
   </Grid>
</Window>

  diagram.Source = project.Tasks;

public class Task
{
    public Project Project { get; set; }
    public int UID { get; set; }
    public string Name { get; set; }
    public DateTime Start { get; set; }
    public DateTime Finish { get; set; }
    public List<PredecessorLink> PredecessorLinks { get; set; }
    public List Predecessors
    {
      get
      {
        return
          (from pred in PredecessorLinks
           join task in Project.Tasks on pred.PredecessorUID equals task.UID
           select task).ToList();
      }
    }
    public override string ToString()
    {
       return Name;
    }
}

    <ilog:Diagram
        x:Name="diagram"
        PredecessorsBinding=”{Binding Predecessors}”>

<Style TargetType="{x:Type ilog:Link}" >
  <Setter Property="Radius" Value="10"/>
  <Setter Property="Stroke" Value="#FFF0A5"/>
  <Setter Property="StrokeThickness" Value="2"/>
  <Setter Property="StartArrow">
    <Setter.Value>
      <ilog:LinkArrow  Fill="White"  Shape="Circle"/>
    </Setter.Value>
  </Setter>
  <Setter Property="EndArrow">
    <Setter.Value>
      <ilog:LinkArrow Fill="{x:Null}"  Shape="Open"/>
    </Setter.Value>
  </Setter>
</Style> 

<Style TargetType="{x:Type ilog:Node}">
  <Setter Property="Background" Value="#FFF0A5"/>
  <Setter Property="BorderBrush" Value="#468966"/>
  <Setter Property="BorderThickness" Value="1"/>
</Style>

<DataTemplate x:Key="TaskTemplate">
  <Grid  Margin="5" MaxWidth="150" x:Name="grid">
    <Grid.RowDefinitions>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
    </Grid.RowDefinitions>
    <TextBlock
       x:Name="header" Grid.Row ="0"
       Text="{Binding Path=Name}"
       TextWrapping="WrapWithOverflow"
       Foreground="#FFB03B"
       FontWeight="Bold"/>
    <StackPanel x:Name="startField"  Grid.Row ="1" Orientation="Horizontal">
      <TextBlock x:Name="startLabel" Text="Start:"/>
      <TextBlock Text="{Binding Path=Start}"/>
    </StackPanel>
    <StackPanel x:Name="finishField" Grid.Row ="2" Orientation="Horizontal">
      <TextBlock x:Name="finishLabel" Text="Finish:"/>
      <TextBlock Text="{Binding Path=Finish}"/>
    </StackPanel>
  </Grid>
</DataTemplate>

<ilog:Diagram
  NodeTemplate="{StaticResource TaskTemplate}"
  PredecessorsBinding="{Binding Predecessors}" x:Name="diagram"> 

  <!-- Background of diagram -->
  <ilog:Diagram.Background>
    <LinearGradientBrush  EndPoint="0.5,1" StartPoint="0.5,0">
      <GradientStop Color="#FF555555" Offset="1"/>
      <GradientStop Color="#FF1C1C1C" Offset="0"/>
    </LinearGradientBrush>
  </ilog:Diagram.Background> 

  <!-- graph layout algorithm -->
  <ilog:Diagram.GraphLayout>
    <ilog:HierarchicalLayout
          LinkStyle="Orthogonal"
          ConnectorStyle="EvenlySpaced" />
  </ilog:Diagram.GraphLayout>
</ilog:Diagram>

If you want to look at the code in Visual Studio, download the second version of the source code and open the UMLClassDiagram.sln solution. To see the code of the UMLType symbol, right-click the UMLType.cs item in the Solution Explorer and choose View Code.

Making the Symbol Functional: Adding Properties

Let’s start with an easy one: the TypeName property. We want the UML type name to be displayed in the title of our UML Type symbol. The code for the TypeName property looks like this:

        [Description("The name of the UML type")]
        [Category("UML")]
        public string TypeName
        {
            get
            {
                return nameRect.Text;
            }
            set
            {
                nameRect.Text = value;
            }
        }

What we did here is add a C# property to our user symbol. The property just gets/sets the Text property of the title rectangle of the symbol. This is a frequently used technique: users of your symbol do not have access to its inner elements, so you must selectively expose some of the properties of the inner elements to the outside world if you want users to be able to customize these properties.

Note the [Description(...)] and [Category(...)] attributes: you have probably used these attributes before if you designed .NET components. These attributes can (and should) be used on ILOG Diagrammer .NET user symbols as well.

To try the new property, build the solution (Build > Build Solution), then double-click the Diagram1.cs item in the Solution Explorer. If you select a UMLType instance, you will see the new TypeName property in the property grid, and you can change its value to verify that it works correctly.

(Note: Remember to always rebuild your solution when you change a symbol: the diagrams or the other symbols that use it will be automatically updated.)

Let’s continue with the SplitterSposition property now. This property controls the vertical position of the splitter, and also the sizes of the upper and lower content areas that will contain the attributes and the methods respectively.

        private float splitterPosition = 0.5f;

        [Description("The vertical position of the splitter (between 0 and 1).")]
        [Category("UML")]
        [DefaultValue(0.5f)]
        public float SplitterPosition
        {
            get
            {
                return splitterPosition;
            }
            set
            {
                if (value != splitterPosition)
                {
                    splitterPosition = value;
                    grid.Rows[0].Size = 100 * splitterPosition;
                    grid.Rows[2].Size = 100 - (100 * splitterPosition);
                }
            }
        }

As you can see, the SplitterPosition property adjusts the sizes of the top and bottom rows of the GridPanel so that the splitter is at the desired position. The position is a floating-point value between 0 and 1 (0 = top, 1 = bottom). Note the [DefaultValue(0.5f)] attribute which makes sure that the property will not be serialized if it has its default value.

As before, you can try the new property: in the Diagram1 designer view, change the SplitterPosition property of a UMLType instance and see how the splitter position changes.

Let’s continue with something a little bit more tricky: the Attributes and Operations properties. We will explain only the Attributes property since the Operations property is almost identical. First, we have to create a simple class that describes a UML attribute.

    public class UMLAttribute
    {
        private string name;

        public string Name
        {
            get { return name; }
            set { name = value; }
        }
    }

Our UML Attribute class is really simple, it has only a Name property. We can add more properties if we want (like the attribute type, scope, etc) but the Name property is enough for our explanations, so let’s keep it simple.

The next step is to define a collection of attributes. The collection will be a specialized subclass of the generic System.Collections.ObjectModel.Collection class. What we want to achieve is the following: when the user adds a UMLAttribute to the collection, a graphical item will be added in the corresponding list of our UML Type symbol. So, the collection must be able to notify its UML Type owner when an element is added to it. Here is the code of the collection.

       internal class UMLAttributeCollection : Collection<UMLAttribute>
        {
            private UMLType owner;

            internal UMLAttributeCollection(UMLType owner)
            {
                this.owner = owner;
            }

            protected override void InsertItem(int index, UMLAttribute item)
            {
                base.InsertItem(index, item);
                owner.AttributeAdded(index, item);
            }

            protected override void RemoveItem(int index)
            {
                base.RemoveItem(index);
                owner.AttributeRemoved(index);
            }

            protected override void SetItem(int index, UMLAttribute item)
            {
                base.SetItem(index, item);
                owner.AttributeRemoved(index);
                owner.AttributeAdded(index, item);
            }

            protected override void ClearItems()
            {
                for (int i = 0; i < Count; i++)
                    owner.AttributeRemoved(0);
                base.ClearItems();
            }
        }

We rely on the base class Collection for the implementation of the collection, but we override the InsertItem, RemoveItem, SetItem and ClearItems methods to notify the “owner” of the collection, that is, the UML Type. When the content of the collection is modified, we call the AttributeAdded or AttributeRemoved method. These methods will be responsible for creating and deleting the actual graphical items displayed in our symbol:

        private void AttributeAdded(int index, UMLAttribute attribute)
        {
            AttributeSymbol symbol = new AttributeSymbol();
            symbol.AttributeName = attribute.Name;
            attributesList.Items.Insert(index, symbol);
        }

        private void AttributeRemoved(int index)
        {
            UMLAttribute attribute = attributes[index];
            attributesList.Items.RemoveAt(index);
        }

The graphical items that represent the UML attributes are ILOG Diagrammer .NET user symbols (the AttributeSymbol class). This is a really simple user symbol that contains a “blue square” icon and a text object, and that has an AttributeName property to change the text. We will not describe this sub-symbol in details, you can look at it by double-clicking the AttributeSymbol.cs item in the Solution Explorer (or right-click > View Code to see the code).

(Note: do not confuse the UMLAttribute class with the AttributeSymbol class. The UMLAttribute class is the logical representation used to define and persist a UML attribute, whereas the AttributeSymbol class is the graphical representation of a UML attribute.)

OK, now we finally have all the pieces to create our Attributes property:

        private UMLAttributeCollection attributes;

        public UMLType()
        {
            ...
            attributes = new UMLAttributeCollection(this);
        }

        [Description("The attributes of the UML type.")]
        [Category("UML")]
        [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
        public Collection<UMLAttribute> Attributes
        {
            get
            {
                return attributes;
            }
        }

The attributes member variable will hold the actual collection that backs the property. This collection is created in the constructor of the UML Type class. Finally, we define the Attribute property. The property is read-only, it just returns the collection. To add a UML attribute, users will add items to the collection like this:

            UMLAttribute attribute = new UMLAttribute();
            attribute.Name = "Attribute1";
            umlType1.Attributes.Add(attribute);

One thing to note is the DesignerSerializationVisibility attribute. The Attributes property is read-only, and by default the .NET framework does not serialize read-only properties, so we need to explicitly tell the .NET framework that the property must be serialized. The DesignerSerializationVisibility.Content value tells the framework that the property value is created automatically by the class, and that only its content (that is, the UMLAttribute values contained in it) must be serialized/deserialized.

You can now try the new Attributes property in our sample diagram. Select a UML Type instance and click the “…” button in the Attributes row of the property grid. You get a dialog that lets you add, remove and modify the UMLAttribute instances of the collection. Once you click OK, the UML Type symbol is updated to show the new UML attributes.

First, what is the purpose of licensing ? It’s a mechanism that makes sure that only users with a valid licence can use a component. The .NET framework has a built-in licensing mechanism that makes it easy to author licensed components. From the component user point of view, it also has a great support in Visual Studio, which makes the use of licensed components easy. In this first article, we’ll focus on how to use licensed components.

Using Licensed Components with Visual Studio

Using licensed components inside Visual Studio is completely transparent for the user. The usual way to use components in Visual Studio is to drag and drop them from the toolbox onto a design surface: When a toolbox item is dropped onto a design surface, Visual Studio creates an instance of the component represented by the toolbox item and adds it to the designer. If the component created is a licensed component, Visual Studio also adds a licences.licx file to the Visual Studio project.

The licences.licx file contains the type names of the licensed components used in a Visual Studio project. Here is an example:

ILOG.Views.Gantt.Windows.Forms.ActivityTable, ILOG.Gantt
ILOG.Views.Gantt.Windows.Forms.ResourceTable, ILOG.Gantt
ILOG.Views.Gantt.Windows.Forms.GanttChart, ILOG.Gantt

The licences.licx file is updated each time a new licensed component is added to the designer. You can also create or edit this file by hand. You must do this for example if you don’t create the components by dragging them from the toolbox.

The .licx files are associated in Visual Studio with the licence compiler tool (lc.exe). When building your project, the license compiler is run with the licence file as parameter. Compiling the licences produces a resource file that will be used at runtime by the application. Let’s see now in details how the compiled licences are used at runtime, depending on the application type you’re building.

Assembly-based Applications

This category of applications regroups all the applications that are assembly based, that is, applications whose ouput produce an assembly. It contains Windows Forms applications, WPF applications, Silverlight applications, as well as class libraries. It also contains Web project applications. For these applications, the compiled licences are automatically embedded in the resources of the application assembly when the project gets compiled. For example, let’s say I have a Windows Forms application called GanttEditor.exe that’s using licensed components. After compiling the application, we can check that a licence resource has been added to the application resources. To do this, I use Reflector, my favorite .NET disassembler :

The licences.licx file has been compiled into a resource called GanttEditor.exe.licenses.

Web Sites Applications

In Visual Studio, a Web Site is a special project, as there’s no real project file. Instead, all the files located under the web site directory are part of the web site. When a licensed component is dropped into a Web Form designer, Visual Studio creates a licenses.licx file and adds it to the web site directory. This licence file is compiled into an assembly named App_Licenses.dll, located in the web site Bin directory. This assembly will be loaded at runtime to locate the licences. Note that you can force the generation of the App_Licenses.dll assembly by right-clicking the licenses.licx file in the solution explorer, and choosing the “Build Runtime Licenses” menu item.

Using Licensed Components without Visual Studio

For some reasons, you may not use Visual Studio to create your application. In this case, you’ll have to integrate the licence into your application by yourself. These are the steps to follow:

1. Create and edit you own licenses.licx file.
2. Compile the licenses.licx file using the licence compiler (lc.exe).
3. Integrate the compiled licence file into the application.

The last step depends on the type of application you’re building. For example, in a Windows Forms application, you have to put the compiled licence as an emdedded resource of the application (using the /resource option of the c# compiler if it’s a c# application). When hosting Windows Forms controls in IE, the process is different, and is described in the next section.

Windows Forms controls hosted in Internet Explorer

Embedding a Windows Forms control in Internet Explorer can be painful for two reasons:

• Code Access Security : When running into Internet Explorer, the hosted control doesn’t have the same permissions as if it was run as a desktop application. Configuring the CAS is not a simple task, as well as finding the minimum permissions required by a control to work properly inside IE.
• Licence Management : You have to compile the licences by yourself.

Let’s illustrate how to manage licences with a very simple example: You want to embed a GanttChart (located in the ILOG.Gantt.dll assembly) into the default.htm page. As the GanttChart is a licensed component, you’ll have to provide an entry for it in the licenses.licx file:

ILOG.Views.Gantt.Windows.Forms.GanttChart, ILOG.Gantt

Then, you’ll have to compile this file using the licence compiler:

lc.exe /target:default.htm /complist:licenses.licx /i:ILOG.Gantt.dll 

the /target parameter must be the page in which the licence will be used,

the /complist parameter is the .licx file to compile,

the /i parameter indicates the assemblies needed to compile the licence.

The licence compiler will produce a file named default.htm.licenses. Now, we need to use this file in the HTML page as shown below: 

<html>
...
<HEAD>
...
<LINK REL="licenses" href="default.htm.licenses" mce_href="default.htm.licenses" />
...
</HEAD>
...
<OBJECT id="ganttControl" height="300" width="800" classid="ILOG.Gantt.dll#ILOG.Views.Gantt.Windows.Forms.GanttChart" />
...
</html>

The <OBJECT> tag is used to insert the control in the HTML page, and the <LINK> tag is used to indicate where the licence can be found.

Conclusion 

We’ve seen two different ways to use licensed components in .NET: With or without Visual Studio. When using Visual Studio, it takes care of everything. When not using it, you need to do things by yourself.

Now, from a developper point of view, it would be interesting to understand how the licence compiler works, and how to author licensed components. That will be the subject of a second article.