Jan

Add existing project to TFS

alkampfer on January 27th, 2012

This is a super basic and easy question, but I found quite often people asking me how to add an existing project to a TFS Team Project. It turns out that there are more than one way of doing this, but I usually suggests this simple path that is quite simple and is understandable from people that comes from the subversion world.

First of all be sure that you have a valid workspace in your computer that maps the folder in the Team Project where you want to put your existing project and issue a GetLatest. If the team project is new you can simply create a workspace going to menu File –> source control –> Workspaces, press add and create a workspace that maps the source to a folder on your pc.

Figure 1: Creating a workspace that maps the whole folder of the source control.

Now simply go to the local folder and move the existing solution from the original location to the mapped folder, then go to the Team Explorer –> Source control and manually add all the files to Tfs Source Control. In Figure2 I represented the process to accomplish this task, first of all select Source Control, press the add button then Visual Studio presents you all the files that are in your local folder but are not present in the source control (they are the candidate to be added to the source control).

Figure 2: Adding existing file to source control

Now you are presented with a list of all the files that will be added to TFS source control, as seen in figure 3

Figure 3: List of files that gets added to the source control.

As you can see some of the files are excluded (22 in Figure 3), this happens because Visual Studio already knows that certain types of file should be excluded from source control, like all the Bin and Debug folders and all *.dll files. If you have some lib folder where you store third party library, you can go to the Excluded Items tab in Figure 3 to add manually all the excluded files you want to be added to the source control. Since this window is usually cluttered with all the bin and obj directory, I found simpler to:

1) in a first pass add all the file suggested by Visual Studio
2) browse to lib directory (or whatever folder contains third party library) and add explicitly all the files in the directory.

Now all files were in Pending-add, this means that they will be sent to the source control with a check-in, but before the check-in phase you should open solution file from the source control explorer windows. After the solution is opened Visual studio should tell you that this solution is in a source control monitored folder, but source control is not enabled

This basically means that, source files are correctly linked to the source control system, but the Visual Studio integration is not enabled, you can simply press Yes and let Visual Studio actually do binding between projects and source control.

If the binding does not happens automatically you will get the windows of Figure 4, (you can always open this windows with the menu File –> Source Control –> Change Source control. In this window you can simply select one project at a time and press the Bind button to perform the bind, until all the project files are in Connected Status.

Figure 4: Binding windows where you can bind solution and projects file to TFS

Now you can check-in everything and usually you should create another workspace or ask to another member of the team to do a get-latest of the just-inserted solution, to verify that all the needed files were correctly added to the source control.

Gian Maria.

Tags: Tfs

Team Foundation Server

Jan

Entity Framework error 3002 on views when model updated

alkampfer on January 25th, 2012

One of the most annoying problem with the first version of entity Framework is that you have barely no option other than go with “Database First approach”, and when you start mapping database views your life started to become difficult.

The first obvious problem is that the designer, during the import phase from database, try to detect in the view any not-null column and make it part of the primary key of the entity. If you decide to live with it (and having entities with lot of field used as primary keys), you probably will incur in the error 3002 when you update a view and then update the model from database.

The problem happens if you change the definition of the view, and a column that was not null, became nullable by the modification. What it happens is usually that the designer still mark the corresponding property of the entity as primary key a situation that is not admitted if the field in the database is NULL. If this is your situation you can usually fix it going to “mapping details” of the view that raise the error.

Figure 1: A view with error, the StartDate becomes nullable in the view, but the entity still uses it at key

The problem is depicted in Figure 1, you can see in the left that StartDate is not a key of the database model, because I changed the view and now the StartDate admit NULL value, but in the right part, the model still uses that property as a key.

The fix is easy, just select the StartDate property in the model, then in properties windows set to false the EntityKey property, set the Nullable property to true and the error should go away.

Gian Maria.

Tags: Entity Framework

Entity Framework

Jan

Is my Domain Model really anemic?

alkampfer on January 23rd, 2012

I’m reading the exceptional Object Thinking book, full of interesting considerations about thinking with an Object Oriented mind. One of the main concept of the book is that quite often we are using objects in a procedural way so we are still in the realm of procedural programming even using inheritance, constructor, etc etc. As an example we can have a domain where each object is only a container for data (properties) and a bunch of other classes (services) are using that domain objects to accomplish business rules.

Is this OOP? Probably not, because we have a domain with all the data and service layer with all the logic, and this is what we are used to call procedural programming.

This is the typical situation of an Anemic Domain Model, a domain that does not contains business logic but almost only data; the more the business logic is away from the domain, the more your domain is: anemic, less OOP and more procedural-like. Now suppose you start to move your Business Logic (methods) from services to domain’s objects. Surely this will make your domain less anemic if you accept the previous definition of “Anemic Domain” and if you move every method from services to domain objects you really have a Domain model? The answer is maybe, but it is still far from sounding like DDD to me.

In my opinion the mere distinction on Where the methods are defined is only part of the problem; if the business logic is simply moved from Services to Domain Objects, but the logic remains the same had I created a really different architecture? What happened if you stretch the definition of the domain and include all service classes in whatever you are calling Domain? With this new definition I moved from an Anemic Domain to a Domain Model without changing a single line of code, just considering Services Classes part of the domain.

What is different in OOP is that you should create groups of objects that solve a problem (the business logic) with collaboration and messages exchanging. The simple act of moving the Logic from service to Domain Objects without changing how that logic works, sometimes creates a network of objects so complicated that you gain no benefit.

When you started with an architecture of Service + Data Classes and you simply start moving the very same logic from services to Data Classes, the risk is having the situation depicted in the above picture and when you need to change one of the object is a pain because the modification forces you to change all the objects that actually are using that object, etc etc.

Time passed and I started to believe that a the term anemic is related on how much state an object exposes to other objects. If we use the term anemic to identify how much our domain is procedural instead of Object oriented, a possible definition IMHO can be:

A domain model is completely anemic when all the objects expose their status through getters and setters; the opposite situation, a domain model with no anemia, is when domain objects are fully encapsulated (no getter, no setter).

It sounds really harsh definition, but after all this is the basic concept of encapsulation

WIKIPEDIA: … encapsulation means that the internal representation of an object is generally hidden from view outside of the object’s definition. Typically, only the object’s own methods can directly inspect or manipulate its fields.

After all Domain Driven Design is heavily based on: “Bounded Context” and “Domain Events”, because this reduces the coupling between objects, reduce the need for getter (and make setters useless) and lead to a less anemic Domain Model.

Gian Maria.

Tags: DDD

Jan

Design time data in WPF and Blend with little effort

alkampfer on January 20th, 2012

The power of WPF binding really shines when you use design time data to have a live preview of the aspect of your UI without the need to press F5 to load actual data. Design time data is a cool feature you can have with little effort, suppose you have a simple windows and you want to show a list of customers, taken from the northwind datadabase inside a Listbox, personlizing the DataTemplate.

I start with simple ViewModelBase, that is really far to be a real Base View Model to implement a full MVVM solution, but it serves me to show how to use design time data without scare people telling them to implement complex patterns or similar stuff.

public abstract class ViewModelBase : MarkupExtension, INotifyPropertyChanged
{
  
    public event PropertyChangedEventHandler PropertyChanged;
  
    protected virtual void OnPropertyChanged(String propertyName)
    {
  
        var temp = PropertyChanged;
        if (temp != null)
        {
            temp(this, new PropertyChangedEventArgs(propertyName));
        }
    }
  
    private DependencyObject syncRoot = new DependencyObject();
  
    protected Boolean IsInDesignMode
    {
        get { return DesignerProperties.GetIsInDesignMode(syncRoot); }
    }

This is really simple base class that implements INotifyPropertyChanged and inherits from MarkupExtension, it has also an IsInDesign mode property to detect if the code is running inside a designer.

protected abstract void CommonInit();
  
protected abstract void RuntimeInit();
  
protected abstract void DesignTimeInit();
  
protected ViewModelBase()
{
    this.CommonInit();
    if (!IsInDesignMode)
    {
        this.RuntimeInit();
    }
}
  
public override object ProvideValue(IServiceProvider serviceProvider)
{
    this.DesignTimeInit();
    return this;
}

Then I defined three abstract methods, the first is called CommonInit() and is used to do common initialization, then the RuntimeInit() is called to do all initialization I do not want to do when the viewmodel is used inside the designer, finally the DesignTimeInit() is called when the object is constructed inside the Designer. The trick is that the constructor call the RuntimeInit() only when we are outside the designer and the DesignTimeInit() is simply called inside the ProvideValue() virtual method of the base MarkupExtension class

Then I create a MainWindowViewModel inheriting from this class, add an ObservableCollection<Customers> to show data and implemented the initialization methods, the RuntimeInit() loads data from database.

protected override void RuntimeInit()
 {
     using (NorthWind context = new NorthWind())
     {
         foreach (var customer in context.Customers)
         {
             LoadedCustomers.Add(customer);
         }
     }
 }

Then in the DesignTimeInit() I create some fake objects that will be used by the designer, you can do it simple using Fizzware NBuilder library.

protected override void DesignTimeInit()
{
    for (int i = 0; i < 10; i++)
    {
        Customers customerDummy = FizzWare.NBuilder.Builder<Customers>.CreateNew().Build();
        LoadedCustomers.Add(customerDummy);
    }
}

Now I fire blend and open the solution, create a windows then add the design time data context to the first Grid control

   1: <Grid d:DataContext="{sampleproject:MainWindowViewModel}">

This will call the ProvideValue of the MarkupExtension class, so the object will be constructed with some dummy design data, then I drop a ListBox inside the window and bind its ItemsSource property with designer

Figure 1: Bind with designer

The cool part is that the designer correctly recognize the ViewModel inside the DataContext and shows me the list of properties that can be bound to the ItemsControl property. Now I right click the ListBox and ask blend to edit the ItemTemplate, then create a simple layout with a border and a 2×2 grid.

Figure 2: The layout for the DataTemplate of the ListBox

Now that I created the grid with four cells, I need to bind the label of the second column to the right properties of the Customers object, so I simply select the label, then ask to DataBind the Content:

Figure 3: Thanks to Design Time Data, blend designer can use reflection to understand the properties of the Customers Object, so we can easily choose the property to bind

The cool part is that the interface in the designer immediately reflects the result with the Design Time Data

Figure 4: Designer uses design time data to render the interface directly inside the designer

This is a killer feature because permits you to have a real look at how the UI will be rendered with data.

Code sample is here.

Gian Maria

Tags: Blend, WPF

WPF

Jan

visifire chart hung

alkampfer on January 12th, 2012

Today I lost a lot of time diagnosing a problematic Visifire Silverlight chart. If you own 3.X version of the visifirechart and you experience some Chart to completely hung the browser you should update to the 4.x version, as described in this article.

I’ve found it after a couple of hour of diagnosing why the page hung, actually I hit two of the bug, the last one that makes chart crash when dataseries was empty, and the first one.