{ explore .net }

To content | To menu | To search

Wednesday 4 November 2009

WCSF and VS2010

Guidance Automation isn't supported yet in Visual Studio 2010 beta 2 and this sucks (my apologies for using this word).

In a project we're currently working on we're using Entity Framework and the Web Client Software Factory and I would really like to use the new EF features in VS2010 beta 2 (it does have a go-live license) but also keep using WCSF and without GAX/GAT support this aint gonna happen.

But as always in IT there might be a workaround, I'll be extracting the project templates of WCSF (have a look in the install directory to find them) and adding them to the project templates of Visual Studio.

I'll keep you informed of my success or failure.

Thursday 17 September 2009

Understanding Oslo

Are you also intrigued by Oslo but don't really understand what to do with it?

Well, then you have to read this article of Kraig Brockschmidt, he talks about the part you don't here in the usual presentations. He also has 2 introduction articles to "M" (1, 2).

Wednesday 18 March 2009

LINQ to SQL - mapping multiple resultsets to the same type

Apparantly LINQ to SQL doesn't really support mapping multiple resultsets to the same .net type.

My situation is like this:
The stored procedure returns 4 resultsets and I want to map the first 3 sets to the same .net type. Those 3 resultsets also have different column names and different amount of columns.

The thing is, you can define the mappings but LINQ to SQL will always use the first mapping that was defined for for that .net type.

A workaround is to change the stored procedure so that the resultsets that you want to map to the same type always have the same number of columns and have the same column names.

Tuesday 7 October 2008

BackgroundWorker in different AppDomain not synchronizing with main thread

One of my projects is creating an application framework and this consists of several libraries with "tools", base UI elements (forms, controls...) and a "hosting" application. In the near future I will probably dedicate one or more articles about this hosting application, it's quite interesting. Basically the hosting application is responsible for "installing" (xcopy), updating and "running" applications in separate AppDomains.

The problem I encountered was that when a child application (running in its own AppDomain) used a BackgroundWorker this BackgroundWorker couldn't synchronize with the main UI thread. This resulted in exceptions whenever the RunWorkerCompletedEventHandler wanted to update the UI. As a workaround I use this piece of code before creating the BackgroundWorker.

if (SynchronizationContext.Current == null)

{

    SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

}

In my framework this is encapsulated in a method on a base Form, this is the short version:

public void StartAsyncLongAction(

    DoWorkEventHandler action,

    ProgressChangedEventHandler progressChanged,

    RunWorkerCompletedEventHandler workerCompleted,

    string actionText,

    string finishedText)

{

    if (SynchronizationContext.Current == null)

    {

        SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());

    }

 

    BackgroundWorker worker = new BackgroundWorker();           

    worker.DoWork += action;           

    if (workerCompleted != null) { worker.RunWorkerCompleted += workerCompleted; }           

    if (progressChanged != null)

    {

        worker.WorkerReportsProgress = true;

        worker.ProgressChanged += progressChanged;               

    }

 

    worker.RunWorkerAsync();

}

If somebody knows why this happens I would be very interested.

Monday 29 September 2008

ServiceFacadeExecuter: Minimize the code in your service

When you write the code for your (WCF) service you’ll probably find yourself writing the same code for every method for every service. It might look a bit like this (simplified):

public List<Contact> GetContacts(SomeInput input)

{

    // log usage of the service…

    try

    {

        BusinessLayer bl = new BusinessLayer();

        return bl.GetContacts(input);

    }

    catch(Exception ex)

    {

        // log exception…

        // throw FaultException…

    }

    return null;

}

Wouldn’t it be great if you could write all of this in almost one line of code and centralize all the “non-business” related code in one place?

public List<Contact> GetContacts(SomeInput input)

{

    return ServiceFacadeExecuter.Execute<BusinessLayer, List<Contact>>(

    bl => bl.GetContacts(input));

}

This is how you do it:

public static TResult Execute<TObject, TResult>(TObject theObject, Func<TObject, TResult> function)

{           

    try

    {

        return function(theObject);

    }

    catch (Exception ex)

    {

        HandleException(ex);

    }

    return default(TResult);

}

and an overloaded method

public static TResult Execute<TObject, TResult>(Func<TObject, TResult> function)

    where TObject : new()

{

    return Execute<TObject, TResult>(new TObject(), function);

}


TObject is the type of the object that your service will call, most likely your business layer.
TResult is the return type of your business layer call.
HandleException is a method that will take care of logging the exception and throwing a FaultException.

So all the stuff you would write over and over again in your service can now be centralized in the ServiceFacadeExecuter. If in 3 months you need to change something to the exception handling of your services or change the logging you only need to do it in one place. Of course this way of working is not only limited to use in your services.

I hope this article shows you the power of functional programming and the paradigm that logic (methods, delegates, lambdas) can be passed around like data to create a new level of abstraction and simplification of your code.

In the .cs file you’ll find several overloaded methods for different situations.

Tuesday 9 October 2007

Generics and covariance/contravariance

Today I was writing code that looks like this:


public interface IChild<TParent>
{}

public class GenericSet<TChild>
    where TChild : IChild<GenericSet<TChild>>
{}

public class SpecificSet : GenericSet<ChildClass>
{}   

public class ChildClass : IChild<SpecificSet>
{}


If you try to compile this you'll get the following compiler error: The type 'ChildClass' must be convertible to 'IChild<GenericSet<ChildClass>>' in order to use it as parameter 'TChild' in the generic type or method 'GenericSet<TChild>'

Because ChildClass inherits from IChild<SpecificSet> and SpecificSet inherits from GenericSet<ChildClass> I assumed that this should work. Purely from an OO view ChildClass is a IChild<GenericSet<ChildClass>> through inheritance. Unfortunately C# and other .net languages do not support covariance and/or contravariance (definition), Eiffel.net seems to be an exception. The CLR itself on the other hand does support this functionality so you could write this code in IL if you would really want to, reported here.

Due to this limitation you can't write code like this:
GenericClass<BaseClass> T = new Test<DerivedClass>();
or
List<string> TS = new List<string>;
List<Object> TO = TS;


I don't know if this functionality will implemented in future releases of C# (or other .net languages) but I would find it a handy feature to write cleaner code.

Another feature of the CLR which isn't implemented is the try-catch-finally-fault-filter possibilities for exception handling, a full description on the blog of Bart De Smet.

Friday 5 October 2007

Visual Studio 2008 - Code Metrics and .net source code

The new Visual Studio will have a new tool called Code Metrics, "Code Metrics is a new tool window that helps users find and act upon complex and unmaintainable areas within an application". More information can be found on the blog of the team.


Scott Guthrie has some very good news, we'll be able to download the source code of the .net framework! Just think about all the geeky nights we'll have exploring this code :-)

Wednesday 3 October 2007

DataView vs DataTable.Select

This week I was working on some performance issues in an application and encountered a big difference between filtering data from a DataTable using a DataView or the DataTable.Select method.


The application I'm talking about could be retrieving 40000 rows and then has to create the 40000 objects that have parent/child relationships between them. So I would start by finding the root elements and then iteratively build up the whole structure and in each iteration I would filter the child objects from the DataTable.
The original code used a DataView to do the filtering, this worked well during initial testing with a few dozen elements but when we loaded the real data in the DB performance became an issue. When I changed the filtering to use the DataTable.Select method the application ran between 5 and 8 times faster. A possible explanation for the difference can be found on the blog of Chris Falter.

Other performance solutions/advice:
database
- enough and correct indexes (also on views)
- remove cursors (use temporary tables and/or the "table" type)
- do as much data retrieval in a single DB call as possible

code

- remove stuff from your loops that doesn't have to be in them
- use caching mechanisms
- use fast collections such as Dictionary<> with "simple" IDs if you need a lot of searching in collections