Infosys Microsoft Alliance and Solutions blog

« February 2008 | Main | April 2008 »

March 31, 2008

MS Software Factories...

There are some rumbling on the software factories from MS.

It has been nearly 4 years since Jack Greenfield articulated Microsoft Software factories vision. He talked about state of software engineering in his famous book. We have got bunch of PnP guidance packages(http://msdn2.microsoft.com/hi-in/practices/bb969097(en-us).aspx - scroll to then end of the page) that adresses solution domain rather than the problem domain. To some people, these guidance packages have given a different understanding of software factories rather than what was articulated in the vision. Software factories have become synonymous with code generation. These PnP software factories give good guidance and productivity gains but they are not full vision of software factories.

Every one knows that as of now MS has not released tools to realize all the four pillars ( Software Product Lines, Domain Specific Models, Context Guidance and Architecture Frameworks) of software factory vision. Currently, DSL tools like GME from Vanderbilt university have better features than DSL tools from MS.

Complete vision of software factory as articulated few years back is not realized yet but on the other side MS is coming up with Software factory tools support in next version of Visual Studio "Rosario". Check the DSL tools roadmap . Check the updates that are present in Rosario CTP's. These new tools in Rosario represent a definitely a way forward (assuming that they will make it to final release!) but the question is would they give the kind of benefits envisaged in the software factories vision? Only time will tell. 

For latest happenings, refer to software factory community at http://sf.devrevolution.com/

March 26, 2008

WPF - Updating XmlDataProvider when source XML changes

Some days back i had answered a question on the WPF Forum on how to ensure that when the base XML file changes, the XmlDataProvider is udpated and hence the bound control on the UI.

The key is to set a watch on the particular XML file for changes and then update the provider appropriately. See details here. This solution works fine, but I didn't particularly like my initial code that I wrote since the FileSystemWatcher was set externally. It would be better if this could be self contained within the XmlDataProvider itself.  

I hence decided to write my own XmlDataProvider for this purpose. Well, not write entirely, but obviously extend the existing provider. Following is the class that I wrote for this purpose. Since all I am really interested in is to get the FileSystemWatcher setup, I modify the Source property implementation and on the file change event, I force a refresh on the provider.

    public class MyXmlDataProvider : XmlDataProvider

    {

        public new Uri Source

        {

            get { return base.Source; }

            set

            {

                base.Source = value;

 

                FileSystemWatcher watcher = new FileSystemWatcher();

                //set the path of the XML file appropriately as per your requirements

                watcher.Path = AppDomain.CurrentDomain.BaseDirectory;

 

                //name of the file i am watching

                watcher.Filter = value.OriginalString;

 

                //watch for file changed events so that we can refresh the data provider

                watcher.Changed += new FileSystemEventHandler(file_Changed);

 

                //finally, don't forget to enable watching, else the events won't fire           

                watcher.EnableRaisingEvents = true;

            }

        }

 

        void file_Changed(object sender, FileSystemEventArgs e)

        {

            base.Refresh();

        }

    }

This is all that is required. Using this in XAML is pretty straightfoward and following is a sample XAML.

<Window x:Class="TestWPFApp.XmlRefreshTest"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   xmlns:local="clr-namespace:TestWPFApp" 

   Title="XmlRefreshTest" Height="300" Width="300">

    <Window.Resources>

        <local:MyXmlDataProvider x:Key="xmlFromFile" Source="PersonXml.xml" XPath="persons/person" />

    </Window.Resources>

    <Grid>

        <ListView ItemsSource="{Binding Source={StaticResource xmlFromFile}}" x:Name="list" >

            <ListView.View>

                <GridView>

                    <GridViewColumn Header="FirstName" DisplayMemberBinding="{Binding XPath=@firstname}" />

                    <GridViewColumn Header="LastName" DisplayMemberBinding="{Binding XPath=@lastname}" />

                    <GridViewColumn Header="Age" DisplayMemberBinding="{Binding XPath=@age}" />

                </GridView>

            </ListView.View>

        </ListView>

    </Grid>

</Window>

For my testing, I used the following Xml file. Note that I had marked the Xml as Content and Copy if newer in its properties to ensure that the Xml file is available in the output directory.

<?xml version="1.0" encoding="utf-8" ?>

<persons xmlns="">

    <person firstname="Atul" lastname="Gupta" age="35" />

    <person firstname="Sidharth" lastname="Ghag" age="30" />

    <person firstname="Virendra" lastname="Wadekar" age="30" />

</persons>

Comments are welcome !

March 20, 2008

Why is the concept of a list so important in SharePoint

List is a powerful concept in SharePoint. It forms the basic storage mechanism. Everything in SharePoint be it simple item stores like tasks, customlists or more complicated ones like surveys, Calendar entries, project tasks, blogs, wikis, etc are all internally stored as list entries. Infact even Document Library leverages the list infrastructure.

If you open the Onet.xml file in the Global Template directory ( <Installation Drive >\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL\XML\ONET.XML, The following nodes will be seen under Base Types

-  <BaseTypes>
      <BaseType Title="Generic List" Image="/_layouts/images/itgen.gif" Type="0">
    <BaseType Title="Document Library" Image="/_layouts/images/itdl.gif" Type="1">
    <BaseType Title="Discussion Forum" Image="/_layouts/images/itdisc.gif" Type="3">
    <BaseType Title="Vote or Surevy" Image="/_layouts/images/itsurvey.gif" Type="4">
    <BaseType Title="Issues List" Image="/_layouts/images/itgen.gif" Type="5">
 </BaseTypes>
Any list that will be used in SharePoint will be from one of these base types. What is seen as Type here is the ID of the list. As I understand this classification is mainly because the basc purpose and the storage mechanism will be slightly different with each of these.

March 18, 2008

Expression Blend issue with WPF Data binding debugging

Some days back I had pointed to the blog by Beatriz on how to debug WPF data binding errors. I have been using the PresentationTraceSources.TraceLevel feature (available with .NET 3.5) since then and have found it very easy to use and very effective in resolving my data binding errors.

However recently when I opened a XAML, which had this debugging feature enabled, in Expression Blend 2.5 March Preview, I got an error. The XAML won't open in designer and showed "Invalid XAML" with details as 'The member "TraceLevel" is not recognized or is not accessible'.

You can use the following very trivial XAML to reproduce the error.

<Window x:Class="TestWPFApp.Window2"

       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

       xmlns:diag="clr-namespace:System.Diagnostics;assembly=WindowsBase"  

       xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

       xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="d"

       Title="Window2" Height="300" Width="300" x:Name="wnd" >

    <StackPanel>

        <Button x:Name="button1" Content="Click" />

        <Button x:Name="button2" Content="{Binding ElementName=button1, Path=Content, diag:PresentationTraceSources.TraceLevel=Medium}" />

    </StackPanel>

</Window>

Microsoft has confirmed this to be a bug with Expression Blend 2.5. We can expect to see a fix for this in future releases. Check here for details on this bug.

Note that I have set the TraceLevel to Medium. For basic data binding debugging, this can also suffice since it shows the final Transfer value used by data binding. Setting it to Low will not help much. For most detailed information, however, you need to set it to High.

[Updated: March 26, 2008] I got notification from the MS Connect site that this issue has been fixed. Hopefully this means that the next preview release will have this fix included.

March 12, 2008

WPF TextBox Memory Issue

Some days back, I had blogged about this issue and suggested how to set global style to counter this. However it turns out that with that you may run into 'Cannot use UndoService while it is disabled' related error. To address that, you will need to modify the style using a DataTrigger as below.

        <Style TargetType="{x:Type TextBox}">

            <Style.Triggers>

                <DataTrigger Binding="{Binding Path=IsLoaded, RelativeSource={RelativeSource Self}}" Value="True">

                    <Setter Property="UndoLimit" Value="0" />

                </DataTrigger>

            </Style.Triggers>

        </Style>

MS has accepted the behavior behind this as a bug. Read more discussion on this here.

March 10, 2008

WPF XmlDataProvider, Working with External XML Files

Recently on the WPF Forum I came across an interesting problem about use of XmlDataProvider in XAML and its ability to load external XML files. It took a bit of a struggle, but eventually I did manage to get it working. Here I will try and explain it in some detail so that others can also benefit.

We all know that one can easily bind to inline XML in XAML or can load that from external file. If working with inline XML, you usually use XData to specify the XML file content.

        <XmlDataProvider x:Key="Persons" XPath="persons/person">

            <x:XData>

                <persons xmlns="">

                    <person name="Person 1" age="20"/>

                    <person name="Person 2" age="30"/>

                    <person name="Person 3" age="40"/>

                </persons>

            </x:XData>

        </XmlDataProvider>

If working with external file, the Source attribute is set to point to the specific XML File.

        <XmlDataProvider x:Key="xmlFileRes" Source="XMLFile1.xml" XPath="persons/person" />

Note that when you add a new XML file to the project, by default, it is marked as Resource. This means that it will be compiled as a resource inside of the application assembly and personally I don't see much value in that. XML files are typically used so that you can modify them without having to recompile the code, so set the properties of the XML file as
Build Action - Content
Copy to Output Directory - Copy if newer

You can also set Copy to Output Directory to Copy always if you prefer it. That said, if you there is no need for XML file to be modified, you can leave it as a Resource. Also if you do want the XML file to be externally modifyable, take care of appropriate updating to Application logic to ensure that it can pick up the latest XML.

With the above XML you can easily bind this to say a ListBox as

        <ListBox ItemsSource="{Binding Source={StaticResource xmlFileRes}}" ItemContainerStyle="{StaticResource listStyle}" Height="70" Name="list" />

In my case, I have used a style for the ListBox which is defined as below.  

        <Style x:Key="listStyle" TargetType="{x:Type ListBoxItem}">

            <Setter Property="Template">

                <Setter.Value>

                    <ControlTemplate>

                        <TextBlock Text="{Binding XPath=@name}" />

                    </ControlTemplate>

                </Setter.Value>

            </Setter>

        </Style>

Compile and run and all works fine. If you don't see any content in the ListBox, make sure that the settings on the XML file are properly done and physically verify that the XML file is indeed present in the same path as the Application executable.

This entire logic can be moved inside of a UserControl and all still works fine. However the issue occurs if this is moved inside of a new project altogether. In my case, I created a new WPF User Control library and created a User Control inside of it. In the VS and Expression designer the user control loads fine, but when added to the Window of my parent project and executed, the XML files to load. The output window shows that some error occured while loading the XML file -

System.Windows.Data Error: 43 : XmlDataProvider cannot load asynchronous document from Source because of load or parse error in XML stream.; Source='<null>' IOException:'System.IO.IOException: Cannot locate resource 'ucxmlfile1.xml'.
   at MS.Internal.AppModel.ResourcePart.GetStreamCore(FileMode mode, FileAccess access)
   at System.IO.Packaging.PackagePart.GetStream(FileMode mode, FileAccess access)
   at System.IO.Packaging.PackWebResponse.CachedResponse.GetResponseStream()
   at System.IO.Packaging.PackWebResponse.GetResponseStream()
   at System.Windows.Data.XmlDataProvider.CreateDocFromExternalSource(WebRequest request)'

If you look at this strack trace, the call seems to have orginated from XmlDataProvider.CreateDocFromExternalSource(WebRequest). I don't know why the data provider is thinking this to be an XML coming from Web, but this could be the reason for the failure to load. Looks like some bug in the way the XML file is loaded.

To fix this,  here is what I did in the user control's code behind. I modified the constructor logic to as below

        public UserControl1()

        {

            InitializeComponent();

 

            XmlDataProvider xdp = this.TryFindResource("xmlFileRes") as XmlDataProvider;

            if (xdp != null)

            {

                XmlDocument doc = new XmlDocument();

                doc.Load("UCXMLFile1.xml");

                xdp.Document = doc;

                xdp.XPath = "persons/person";

            }

        }

With this change, the application now works fine. You might wonder if we are modifying the Source of the XmlDataProvider in the code behind, do we really need to specific it in the XAML also. It isn't necessary and you can very well modify the XAML as below. However I didn't do it to continue to get designer support. If you remove the Source and XPath details from XAML, the control will not display anything in the designer view and hence designing the layout may become an issue.  

        <XmlDataProvider x:Key="xmlFileRes" />

That said, things aren't still completely fixed. If only both VS and Expression designer's would behave in the same way !!! If you open the Window.XAML in Expression it looks fine and is even able to load the UserControl and show the XML contents inside it as expected. However for some reason now the VS designer goes for a toss. You may see a "Could not create an Instance of type 'UserControl'" error and the VS designer fails to load. To fix this, you can further modify the UserControl's constructor as below.

        public UserControl1()

        {

            InitializeComponent();

 

            if (DesignerProperties.GetIsInDesignMode(this))

                return;

 

            XmlDataProvider xdp = this.TryFindResource("xmlFileRes") as XmlDataProvider;

            if (xdp != null)

            {

                XmlDocument doc = new XmlDocument();

                doc.Load("UCXMLFile1.xml");

                xdp.Document = doc;

                xdp.XPath = "persons/person";

            }

        }

Now both VS and Expression designer work fine, but since the XML load logic isn't executed in design time, the XML contents that were earlier visible in Expression are not visible anymore. You will only see the bounds of the control, but no data inside of it. So based on which designer you prefer to work with, you can take a call of how to write the code.

BTW, I have used Visual Studio 2008 RTM and Expression Blend 2.5 March 2008 Preview. 

 

 

March 7, 2008

A Refactorability Approach to Software Reusability

“If creating a cyborg by plugging human limbs and machine components could become a reality, why is it difficult to create software just by plugging other software components?”, a pal once asked me. “The answer is in the question”, I replied, “Creating reusable components is as much of a trick as a cyborg”.

Five years back, reusability used to be as big a term as it is today. New technologies and increasing business complexities warranted creating reusable components to improve productivity and faster go-to-market times. Five years later, today, we still have the same problems. Technology has grown, programming paradigms have changed, business needs are becoming complex. Factually speaking, reusability hasn’t solved our problems. The reason is simple: Reusability is generally approached with an as-is usage in mind – create once and use many times. On the other hand, reusability needs to be approached with an altogether different angle. Here’s why!

Traditionally reusability is about the infrastructure aspects of a software like caching, runtime management, monitoring etc. It takes time to understand new technology, identify reusable pieces, design generic frameworks around them, pilot them and roll out across projects. The question of creating reusable business components is even trickier to answer as business requirements vary across applications even within a given domain. Even if you do manage to create reusable components, the next problem is to gain customer acceptance for such reusable components and break even on the investments. Add the learning curve required to understand such components as well.  By the time all of these happen, we have the next version of the technology or a change in business requirement to contend with, and we run into issues of upgrading the components or creating new ones.

Oops. Did I say “create new ones”? Well, weren’t we talking about “reusability”?

Only such code can be reused if it does something that you want it to do again in some other application at some other time. But applications are as distinct from each other as are the sun and the moon. Although commonalities do exist, there is also a significant variability to contend with. Reusability in its traditional view does not deal with this variability factor. But then how do we really address all this buzz about reusability improving productivity, and faster go-to-market times?

The answer lies in looking at reusability through the mirrors of Software Refactorability. The ability of a software component to be quickly refactored and fitted into the new application is how I would define the term. Instead of aiming to create components for using as-is across many applications, this approach to reusability insists on creating refactorable components, so that, such components can quickly adapt itself to different applications and amend its behavior as needed.

I would further expand on this idea and ways to achieve it in the following posts.

March 6, 2008

Expression Blend 2.5 still has some issues with Globalization

Last week I had blogged about an issue with Expression Blend Dec 2007 Preview when working with Globalization and Localization. Yesterday at MIX 2008 Microsoft has launched Expression Blend 2.5 March 2008 Preview along with SilverLight 2.0 Beta. For a list of all the products announced during MIX check here.

With the new version of Expression Blend available, I went ahead and upgraded my machine with it and decided to give it a shot for the Globalization issue I had faced earlier.

The good news is that the bug seems to have been fixed and Expression Blend is now able the load the Window and UserControls targetted for globalization and localization without issues. However, I had a case where I was using an ObjectDataProvider in my XAML. Something like

        <ObjectDataProvider x:Key="mtcList" ObjectType="{x:Type GenericWPFApp:MTCList}" x:Uid="mtcList_12" />

The x:Uid got added when I modified the application with MSBuild to add the Uid tags. After this Expression Blend again started having issues in being able to load the particular control to which this ObjectDataProvider was data bound to, as can be seen in the following figure.

Globalization.jpg

This can however be easily fixed. Since the ObjectDataProvider in my case wasn't affected by Globalization and localization, I deleted the x:Uid attribute and Expression Blend once again loaded the control without issues.

Usually any specific localization logic will be inside fo the object referenced by ObjectDataProvider and hence we will not need explicit globalization and localization for it via XAML.

White paper on Monitoring Workflows with WF

Last week a white paper on Monitoring Workflows with WF authored by our architects (Ganesan and Prashanth BG) was published on MSDN at http://msdn2.microsoft.com/en-us/library/cc299397.aspx.

Few other white papers authored by our architects were also published last year on MSDN

Integration and Migration of COM+ Services to WCF by Ganesan and Sripriya at http://msdn2.microsoft.com/en-us/library/bb978523.aspx

BizTalk Server and WCF integration by Atul, Amit and Jitendra
http://msdn2.microsoft.com/en-us/library/bb973215.aspx

Well, Ganesan authored those papers while he was with Infy!

Please let us know any specific feedback or comments on the papers through this blog.  

March 1, 2008

WPF - TextBox memory leak issue

Earlier today on the WPF Forum I hit upon this issue about memory leak in TextBox. MS has responded saying it is by design. I am not entirely convinced as to how consuming unlimited memory could be a good design decision. I have been using WPF for a while now and wasn't even aware of this property on TextBox. I am sure many others won't be.

Anyway, the solution discussed there is to set the UndoLimit property of TextBox to 0. Instead of setting this for all TextBoxes in your code, it can more easily set in App.xaml as an application resource so that it is applicable to all TextBoxes by default. You can explicitly undo for specific ones via code or local property setting.

    <Application.Resources>  
        <Style TargetType="{x:Type TextBox}"> 
            <Setter Property="UndoLimit" Value="0" /> 
        </Style> 
    </Application.Resources>

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter