At the PDC 2009 conference, Microsoft announced a beta release of Silverlight 4. The final release is expected in the first half of 2010.

JetBrains released a new version of TeamCity, a popular build management and continuous integration server. The release includes a number of important new features:

• Integration with Amazon EC2
• Integration with Issue Tracking software, such as Jira, Bugzilla, and JetBrains YouTrack
• .NET Code Coverage using NCover and PartCover.

In the past, if you owned a license to a previous version of Team City Enterprise Edition, you qualified for a free upgrade. Unfortunately, this is no longer the case. With TeamCity 5.0, JetBrains requires you to buy an annual subscription at $999 per year in order to qualify for an upgrade.

The Professional Edition that supports up to 20 user accounts and 20 build configurations is still available at no cost.

Happy coding!

We have been helping a company consume our WCF services from Cold Fusion. I was surprised when a relatively simple WCF service caused an exception in the Cold Fusion 9 cfinvoke tag. The error message stated that there was an undefined portType in WSDL.

To solve the issue, declare a namespace in the ServiceBehavior attribute of your WCF service and leave the namespace empty in the ServiceContract attribute:

[ServiceContract]
[ServiceBehavior(Namespace = "http://yourdomainname.com/")]

Happy coding!

A named pipe is a system kernel object that processes on the same server may use for communicating with each other. It is a fast, secure, and reliable way for your applications to access on-machine WCF services.

While working on the test server that hosted multiple sites in IIS7 (test, uat, staging, etc.), I have noticed that for a single web service all sites used the same named pipe - you can look at all named pipes defined on your system using a tool like PipeList. Needless to say, reusing the same named pipe is not a desirable behavior in this situation.

I looked closer into the issue. From what I now understand, WCF uses an algorithm that maps a service path to the pipe name. By default, this algorithm ignores the domain name of the site and, thus, all sites on the server map services with the same local path to the same named pipes.

That explain the root cause of the issue. How can we get it fixed? How can we force the algorithm to take the domain name into acount when creating a named pipe?

The first step is to set the hostNameComparisonMode attribute to Exact in the NetNamedPipeBinding configuration of your service:

<netNamedPipeBinding>

    <binding  name="YourNamedPipeBinding"  hostNameComparisonMode="Exact" />

</netNamedPipeBinding>

The second step is to modify the net.pipe binding on each IIS7 website:

Hope it helps. Happy coding!

Problem Statement

In August, I blogged about the structure of a release unit's trunk folder. We looked at how to organize your .NET solution to support principles of object-oriented and domain-driven design and distributed application development. We recommended creating a separate library for domain model classes that would describe your release unit's capabilities in business terms.

This month, we are starting a discussion around how to organize classes inside your domain model in a clear, easy-to-understand and, thus, easy-to-maintain manner that supports natural growth of your applications. The topic is quite large and will take a series of articles to cover even at a very high level. The purpose of this article is to introduce you to the topic and provide basis for our discussion over the next few months.

Objectives

As always, let's define our main objectives:

• Support on-the-project learning
• Organize development of the domain model in a structured evolutionary manner
• Have the domain model tell a story
• Make rules and operations explicit and extendable
• Support domain-driven design philosophy
• Support principles of object-oriented design

Why are these objectives important?

Support on-the-project learning

When all decisions are predetermined before the implementation, a significant amount of business value is lost:

1. Learning that occurs during the project is ignored because it is not a part of the original plan.
2. Communication between users and stakeholders and the development team is poor.
3. Very limited creativity takes place. There is almost no place for new ideas.
4. As a result, the system is created lacking flexibility and understanding of the domain.

To get the most out of your projects, enable continuous functional and technical learning for all your team members. As they learn more, they will make decisions better and faster.

Organize development of the domain model in a structured evolutionary manner

There are two major alternatives to Structured Evolutionary Design:

1. Big Design Up Front (BDUF), in which design decisions are perfected before the implementation is started.
2. Adhoc Evolutionary Design, in which design decisions are made as the system is being developed, but without a set of rules that would ensure domain model consistency.

As your team acquires new knowledge, their understanding of the domain changes. Even if you start with BDUF, the domain model needs to evolve in order to correctly represent your understanding of the business situation.

As your domain model evolves, it becomes more powerful and sophisticated, requiring you to establish rules and guidelines around it. Without overarching rules, constant changes to the model will make it inconsistent and hard-to-understand, eventually leading to a familiar "fast-slow-stopped-redesign" application development cycle.

Have the domain model tell a story

An ability of the domain model to tell a story is one of the most critical design objectives. OO allows us to build classes representing real-world business concepts. Should not we be able to use them to describe a business situation? Ask the following questions during your next design or code review:

• What business processes are enabled by this system and what are their steps?
• What business transactions are supported and how are they implemented?
• What business concepts do we deal with day-to-day? How are they described? How can they be created and loaded into memory?
• What operations are performed? What decisions do we face? What business rules could be customized and how are they configured?

Make rules and operations explicit and extendable

Business rules and operations are often the most sophisticated and the most changeable classes in the domain model. But most importantly, these classes have a great potential to add a hidden business value. Make them explicit and extendable in your model to uncover their true power.

Support domain-driven design philosophy

If you are new to domain-driven design, please, refer to this book to get started.

Support principles of object-oriented design

There is plenty of information online about the object-oriented principles. They are a great way to maintain a clear, flexible, reusable, and robust codebase and keep infrastructural details outside of the domain model.

Summary

This article started a discussion around how to organize your domain model. We have reviewed the objectives and discussed why they are important. Next time, we will look closer into designing domain model in practice.

Happy coding! To be continued...

Steve Resnick, Richard Crane, Chris Bowen
Essential Windows Communication Foundation. For .NET Framework 3.5.

This is a well-organized and easy-to-read introductory book on WCF. It provides a thorough overview of the principles behind building and consuming WCF web services and includes real-world examples illustrating how to leverage WCF framework in your applications. The topics covered in this book include:

• Contracts: how to define complex structures and interfaces
• Channels: how to configure channels and channel stacks
• Bindings: how to choose communication protocols
• Behaviors: how to manage instances, concurrency, and transactions as well as how to add your own custom behaviors
• Serialization and Encoding: how .NET classes are serialized and represented on the wire
• Hosting services in IIS, WAS, and managed .NET applications
• Security options for authentication and transport- and message-level security for Internet and Intranet applications
• Integration with other frameworks such as WF and Silverlight
• Other topics: JSON, RSS/ATOM, peer networking, metadata publishing, diagnostics, and others

The authors did an excellent job explaining complex WCF concepts in simple terms and will help you jump right into building distributed applications in .NET. I highly recommend this book to .NET application developers and architects.

Happy reading!

While working with WCF services hosted in IIS7 with non-HTTP endpoints (such as TCP or NamedPipes), we realized that our usual way to resolve a phisycal file path corresponding to a virtual path on the web server is not supported.

In ASP.NET, we use HttpContext.Current.Server.MapPath method, but HttpContext.Current is null in WCF services with non-HTTP endpoints. What shall we do? It turns out that there is another way to map a virtual path: using the HostingEnvironment class. See the example below.

public static string MapPath(string path)
{

    if (HttpContext.Current != null)

        return HttpContext.Current.Server.MapPath(path);

    return HostingEnvironment.MapPath(path);

}

Happy coding!

Jordan Terrell will be speaking on Domain Driven Design tomorrow, October 1, 2009.

Who:	Jordan Terrell
What:	Introduction to Domain Driven Design
When:	Thursday, October 1, 2009 5:00 - 7:00 pm - Presentation
Where:	Microsoft Corporation, 8300 Norman Center Drive, Suite 950, Bloomington MN 55437
Cost:	Free. Register here.

Problem Statement

Last month, I blogged about organizing code in a source control system. We looked at how release units help us represent a domain context map to support domain-driven design and distributed application development. We recommended adopting a standard release unit layout so that your release process can be clearly understood and automated.

This month, we will take a deep dive into the release unit's trunk folder. I said before that trunk contains the latest version of the release unit code. How shall we organize our code inside trunk?

Objectives

As always, let's define our objectives:

• Support domain-driven design philosophy
• Support principles of object-oriented design
• Support distributed application development
• Support a structured, repeatable, and traceable release process

Release Units in .NET

Release Unit is a collection of folders and files that are released together. In .NET environment, this is achieved with a .NET solution that groups multiple projects together for the purposes of debug, compilation, and release. Hence, if you are working in .NET environment:

Each release unit should contain one and only one .NET solution.

.NET Solution Structure

Now, we are ready to take a look at a sample .NET solution structure that will help you implement principles of domain-driven design and object-oriented programming. For simplicity, let's assume our solution consists of a single web application and a command-line data setup utility. You will have no problems extending this approach to handle your own more sophisticated scenarios.

/doc - contains release unit's documentation.

/lib - contains release unit's pull dependencies. When your project uses a .NET assembly not part of your solution, place the assembly into the lib folder and reference it from there. It ensures that all projects in the same solution always use the same version of the dependent upon library and provides you with a clear way to upgrade the library to a new version should you decide to do so.

/Database - contains database creation and modification scripts, scripts to set up users and their permissions, load data files, etc. This folder may also include command-line batch files to set up the release unit on a local machine, build, integration or test server.

/Model - contains classes of the Domain Model, a central part of the release unit. This assembly describes what can be accomplished by the release unit in business terms. Keep the model free from infrastructural detail. It will help you achieve high levels of reuse and low costs of maintenance in your applications. Next month, we will take a look at how to organize your domain model to clearly identify all supported business scenarios and transactions. This is a big topic on its own, which certainly deserves a dedicated blog article.

/ModelUT - contains unit tests for the Domain Model classes.

/Persistence - implements a persistence mechanism for the release unit's domain model. I strongly recommend keeping persistence interfaces with the model itself since it shows how aggregates and entities are designed to be loaded into memory. The purpose of the persistence library is to implement persistence interfaces with your standard tools and techniques.

/PersistenceUT - contains configuration files and unit tests for the Persistence. In our case, these tests verify the release unit's persistence classes and their configuration files as well as the database. Strictly speaking, they are integration tests. However for the purposes of the domain modeling, we prefer to think about the whole domian model persistence as a black box.

/WebInfrastructure - contains web infrastructural classes which would otherwise be placed in the App_Code directory on the web site. Extracting these classes into a dedicated library allows them to be unit tested.

/WebInfrastructureUT - contains unit tests for the web infrastructural components.

/Web - contains a web application, a top application layer responsible not only for user interface but also for referencing and configuring all its depencies.

/WebUAT - contains user acceptance test scripts, such as Selenium or WatiN.

/WebLT - contains load testing projects, such as JMeter or LoadRunner.

/DataSetup - contains a command-line process to perform backroom administrative tasks.

/DataSetupUT - contains unit tests for the data setup components.

Dependencies

To better understand this sample solution structure, take a look at the package diagram below:

Summary

1. For each release unit, create a .NET solution file.
2. Place all of your external pull dependencies into the lib folder.
3. Keep your model classes free from any infrastructural detail.
4. Make your top layer responsible for connecting and configuring all its dependencies.

Happy coding!

The long waited Silverlight 3 and its development tools have been released by Microsoft.

Farewell, Silverlight 2. Welcome, Silverlight 3!