It all starts with the IDE. While the tool has been built to provide a development environment for the new .NET 4.0 framework, there are several other features that make Visual Studio 2010 something to look forward to:

• Microsoft has cleaned up the user interface a bit, which will be the most obvious change when you first run VS 2010.  For the first time, Visual Studio is now a full-fledged WPF application.
  

  The new welcome screen in Visual Studio 2010

• There are several enhancements to better support new languages such as F# and parallel programming.
• Most exciting to many developers will be the full IntelliSense support for JavaScript (finally!)
• A new visual editor for XAML-based Silverlight applications has been added.  It’s no longer necessary to use Microsoft Blend to do front-end visual design, which is a big win for Silverlight developers.
• Several tools have been either added or enriched: new built-in modeling capabilities, better testing options, and some really nice improvements to TFS.

I’ve had the beta version installed for a while now, and I would have used it more had it not blue-screened my computer a few times.  Regardless, the best development IDE out there has added a number of nice additions to keep it ahead of the game.

Projected Release: March 22, 2010
Further Reading: http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx

2. .NET 4.0/C# 4.0

There is a laundry list of new features in the upcoming .NET Framework 4.0 and C# 4.0 (VB.NET has new features as well, but mostly they either mimic C# enhancements or add abilities that were already in C#).  The .NET Framework has numerous additions, which are detailed throughout this list.

C# adds several new abilities that I’m sure a lot of developers can’t wait to start using, namely:

• Dynamically typed objects
• Optional parameters – Visual Basic has had this forever and now C# finally adds this ability!
• Better interoperability with COM objects – Not that anyone wants to deal with COM anymore, but its out there.

Projected Release: March 22, 2010
Further Reading: http://msdn.microsoft.com/en-us/netframework/default.aspx

3. Windows Identity Foundation/Active Directory Federation Services (formerly codename “Geneva”)

The new identity offerings from Microsoft present a means for ASP.NET developers to jump into the world of claims-based security and federated authentication.  While the approach isn’t new, the tools to make all of this relatively seamless in ASP.NET are a significant advancement for enterprises.  See my previous posting about some of the advantages that come along with this shift in security thinking.

Projected Release: Windows Identity Foundation: Released, Active Directory Federation Services: Q1 2010
Further Reading: http://msdn.microsoft.com/en-us/security/aa570351.aspx

4. Windows Azure Platform

The Cloud – we’ve been hearing about it in articles, TV commercials, and just about everywhere.  Microsoft will be doing the hard sell on their cloud-based services platform in the coming months with the release of Azure.

What does it mean to developers?  Well, for one it’s part of the ongoing move to Internet-based services.  As architects plan out their systems, it may not be a matter of installing a new SQL Server or setting up an Active Directory server.  Instead, the company may opt to host their systems on the Azure platform, which will present its own set of challenges dealing with latency, network concerns, and system interoperability.  [Insert your own rain cloud analogy here.]

Projected Release: November 2009
Further Reading: http://www.microsoft.com/windowsazure/

5. ASP.NET MVC 2

No, MVC doesn’t stand for Microsoft Voluminous Code, although some web forms developers may feel that way after they first get into ASP.NET MVC.  Since MVC ditches server controls, some long-time ASP.NET programmers may see MVC as adding a lot of work and extra code.  While this fear is somewhat unjustified, the next version of MVC hopes to ease the transition to MVC with some nice improvements.

Projected Release: March 22, 2010
Further Reading: http://aspnet.codeplex.com/wikipage?title=Road%20Map&referringTitle=MVC

6. Entity Framework 4.0

With the ADO.NET Entity Framework, Microsoft stepped up to bat in the ORM (Object Relational Mapping) marketplace, and according to many people, swung and missed.  With NHibernate, .netTiers, and their own LINQ to SQL already out there as better ORM options, Microsoft’s first version of the Entity Framework left a lot to be desired.

Thankfully, Microsoft has taken the hint and the next version of the Entity Framework fills in a lot of gaps.  For one, you can now easily customize the code generated by the tool using T4 templates.

Another complaint was the ability to deal with disconnected entity objects in an n-tier architecture.  Since the Entity Framework relies on the state of an object to determine whether a record should be updated, deleted, or inserted; dealing with stateless entity objects passed over a WCF service was a bit of a chore.  Microsoft corrects this with “self-tracking” entities that will set their own state on the client side.

Projected Release: Q1 2010
Further Reading: http://blogs.msdn.com/efdesign/

7. WCF 4, WF 4, and Windows Server “Dublin”

Yes, another European city codename for Microsoft.  With the .NET 4.0 framework, Microsoft has made significant improvements to Windows Communication Foundation (WCF) and Windows Worflow Foundation (WF).  ”Dublin” meanwhile is a set of enhancements to Windows Server and IIS that provides a standard host for WCF and WF applications.

One of the biggest headaches with WCF is configuration. The range of web.config or app.config settings that need to be specified for WCF negates the ease with which the rest of a WCF service can be developed. With .NET 4.0, WCF now has a default endpoint configuration so you don’t actually need to configure anything if you don’t need to. In addition, WCF now supports a more simplified REST interface. This was available before with the WCF REST Starter Kit, but the new version of WCF makes this a lot easier.

On the Workflow side of things, Microsoft has greatly improved the visual designer for WF in Visual Studio while also completely revamping the programming model to be more robust. They’ve also made enhancements to the interaction between WCF and WF, which brings both of these technologies more in line with each other.

Projected Release: Q1 2010
Further Reading: http://www.microsoft.com/NET/Dublin.aspx

8. F#

Like many developers out there, I got my first taste of functional programming in college with LISP, and that was enough to scare me away forever.  Recently however, there’s been a resurgence in functional programming interest, stemming partly from the introduction of LINQ in .NET and leading to the development of F#.  What started out as a research project within Microsoft is now the fully-realized F# language that will be available with Visual Studio 2010.

Here is a quick sample program in F#:

(* Sample Windows Forms Program *)

(* We need to open the Windows Forms library *)
open System.Windows.Forms

(* Create a window and set a few properties *)
let form = new Form(Visible=true, TopMost=true, Text="Welcome to F#")

(* Create a label to show some text in the form *)
let label =
let temp = new Label()
let x = 3 + (4 * 5)
(* Set the value of the Text*)
temp.Text <- sprintf "x = %d" x
(* Remember to return a value! *)
temp

(* Add the label to the form *)
do form.Controls.Add(label)

(* Finally, run the form *)
[]
do Application.Run(form)

So why consider F# over object-oriented languages such as C# and Java?  That can be better summed up by someone else so check out Scott Hanselman’s write-up.

Projected Release: March 22, 2010
Further Reading: http://msdn.microsoft.com/en-us/fsharp/default.aspx

9. ASP.NET AJAX v4.0

If you do web development these days, odds are that you’re designing much better user interfaces than were written 5 years ago before the advent of AJAX and rich JavaScript libraries like jQuery.  Within ASP.NET web forms, the ability to do asynchronous operations gets more complicated when you’re dealing with ViewState and generated HTML elements.  To remedy this, Microsoft introduced ASP.NET AJAX in 2007.

The previous versions of ASP.NET AJAX used the UpdatePanel control to define a region of “AJAX-enabled” content that could be replaced using asynchronous updates.  The data sent back and forth in these calls was a large block of ViewState and HTML content, which is clearly inefficient.  With v4.0, ASP.NET AJAX introduces client-side templating, which provides an easier and simpler method of displaying dynamic data.  Take a look at this overview to get an idea of how this all works and how this brings pure AJAX and JSON data interaction into ASP.NET AJAX.

Projected Release: March 22, 2010
Further Reading: http://aspnet.codeplex.com/wikipage?title=AJAX&ProjectName=aspnet

10. .NET RIA Services

Microsoft .NET RIA (Rich Internet Application) Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.

Put simply, .NET RIA bridges the gap between Silverlight and data access by providing a middle tier layer for defining business and application logic.

Projected Release: Q1 2010
Further Reading: http://go.microsoft.com/fwlink/?LinkID=144687

Claims-based authentication scenario

If you haven’t been exposed to the concept of claims-based security, it’s a bit of a mind-shift from how application rights and user properties have been typically implemented so it may take some time to fully grasp.  A claim, to put it simply, is any attribute that can be ascribed to a user (or any resource).  For example, a user’s claims may consist of his name, birth date, gender, and role within an organization.

What makes this different from traditional role-based security is that these claims are authenticated by a trusted third-party.  One of the best analogies is to think of a person going to buy alcohol at a bar.  The bartender must prove that the person is of legal age so he asks for an authenticated record from a trusted third-party, which in this case is a driver’s license from the DMV.  The claim is that this person is over 21 years old, and the identity provider is the Department of Motor Vehicles.

A Boon to Developers and Organizations

OK, so this is all well and good but how does this make developing applications easier?  The short answer is that claims alone don’t make things much easier, but what does simplify matters is the use of federated authentication.  In our previous example, the bar knew nothing about the person buying a drink.  There was no big filing cabinet with everybody’s name and birth records stored in the back room of the bar (at least you hope not).  The problem is that this is how many applications work today.  Each application stores off its own set of users and profile data, and therefore, the application (and consequently, the application developers) must be responsible for authenticating users.

By utilizing federation, the job of validating that a user is who he claims to be is now handed off to a third party, and a trust is established between our application (the relying party, or RP).  If our identity provider (IP) says that Joe Smith is really Joe Smith, we can trust that this is true.  Immediately, you can probably see that this is a boon for developers everywhere, who are tired of creating user login pages and databases.  In addition, this now enables Single Sign-On (SSO) within a network of applications that share the same IP.

Putting it All Together

Now that you can probably see how claims and federated security can be of benefit, the next question is how all of this works within the current world of application security.  The good news is that Microsoft seems to have done an admirable job of building on top of existing technologies (e.g., Active Directory and ASP.NET authentication) and providing flexibility to leverage existing security mechanisms (e.g., OpenID, Live ID, etc.).

The Geneva Framework is a set of assemblies that forms the foundation of the entire security suite.  Using the Framework (otherwise known as Windows Identity Foundation, or WIF), developers can claims-enable their ASP.NET applications with just a handful of configuration settings.  In addition, WIF can be used to create a custom Secure Token Server (STS) that can perform user authentication and claims look-ups using any technique imaginable.  This open foundation will encourage developers and IT organizations to move towards this model.  In addition, Geneva Server is a robust and freely available STS that can be rolled out within an organization, making federated security a reality in fairly short order.

Further Reading

This discussion barely scratches the surface and depth of Geneva so I would encourage you to read more on the blogs and Microsoft sites out there:

• Vibro.Net – Vittorio Bertocci is a Microsoft architect/evangelist and a prolific blogger on Geneva
• Geneva Framework Whitepaper for Developers
• Microsoft Identity Management Developer Center

Along with a lot of the great new additions already seen in the first preview release, it looks like they’ve added a lot of flexibility in extending the validation processing, both on the client and server sides.

Having worked with the first version of ASP.NET MVC, I’m excited to see how much work they continue to put into the framework. Much like other Microsoft technologies, the product will get much better in version 2 and beyond once they’ve gotten feedback from the user community and they’ve had time to refine the product. I expect more and more developers will start looking to MVC as a genuine option since I know many people have been scared to move away from the comfort of ASP.NET web forms.

Out of the box, AD FS provides several options for the Attribute Store: an LDAP source (such as Active Directory DS), SQL Server, or a custom store defined in a .NET library. In many situations, there may not be a single source for all of the user’s profile data (e.g., birth date, email address, phone numbers, etc.) In these situations, AD FS gives you the ability to have several stores and then determine which attribute store to use based on the claim being requested. Setting up this within AD FS (at least in the beta version) is not the most intuitive process.

Configuring Attribute Stores

The first step is to configure the attribute stores within AD FS, which is accomplished in the Attribute Stores section. An Active Directory store which points to the domain AD instance is setup by default so that’s taken care of. Next, we will need to add our secondary attribute store. When you add a new store, you will see that you have three options: Active Directory, LDAP, or SQL. For an LDAP or SQL source, you simply need to provide a connection string. For my application, I needed to access a SQL Server instance, so I just gave it a unique name and plugged in the SQL connection string.

AD FS Attribute Store

Claim Rules

Once the attribute stores have been setup, you need to setup claims rules either at the Relying Party or Identity Provider level to dictate which claims will be retrieved from which attribute store. Optionally, these claims can also be converted into another claim. Both of these tasks are accomplished using Microsoft’s new claim rule language. The syntax for defining claims transformations is sparsely documented at this point, and the only definitive source that I’ve found is on TechNet: http://technet.microsoft.com/en-us/library/dd807118%28WS.10%29.aspx.

To access the user data that’s stored in our SQL Server database, we need to write the query using a claim rule. Within the Relying Parties section, right click on the appropriate application and select “Edit Claim Rules…” Next, we will need to create an Advanced Rule since there currently isn’t a nice wizard to step us through this process. Within the rule definition window, type up your rule using syntax such as below:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"]
=> issue(store = "AdventureWorks Attribute Store", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"), query = "SELECT BirthDate FROM [HumanResources].[Employee] WHERE LoginID = {0}", param = c.Value);

This isn’t an easy mechanism and hopefully Microsoft polishes this interface in future releases, but in the end, we do have claims being sourced from multiple locations, which will be very useful when developing a claims-enabled application.

The Assembler pattern is used to build up the DTO objects before sending results back from a method and is also responsible for reversing this process when clients pass DTOs to the service.  This build process involves mapping Entity classes to DTO classes, but there will not necessarily be a one-to-one correspondence between properties.  In either case, the process of mapping matching properties can be a laborious programming task.

Enter the AutoMapper

One option for overcoming this chore is to use generated code, which can be sufficient for exact matches but doesn’t address more complicated scenarios.  The other option is to use mapping code, and AutoMapper (http://www.codeplex.com/AutoMapper) is a CodePlex project meant to solve exactly this problem.  By default, the AutoMapper library copies property values from one class to another based on property names and also allows for more complicated mappings.

DtoAssembler

For my particular set of DTOs, the mappings were mostly one-to-one to the underlying database entities and did not require many changes.  To simplify things, I created a generic DtoAssembler class that takes two class types – TSource and TDestination – as the input and output types for the mappings.  Next, we simply create a map using the CreateMap static method and then call the Map to perform the conversion.

using AutoMapper;

public static class DtoAssembler<TSource, TDestination>
{
        public static void MapObject(TSource entity, TDestination destination)
        {
            Mapper.CreateMap<TSource, TDestination>();
            Mapper.Map<TSource, TDestination>(entity, destination);
        }

        public static TDestination MapObject(TSource entity)
        {
            Mapper.CreateMap<TSource, TDestination>();

            TDestination dto = Mapper.Map<TSource, TDestination>(entity);

            return dto;
        }

        public static List<TDestination> MapList(List<TSource> entities)
        {
            List<TDestination> dtoList = new List<TDestination>();

            foreach (TSource entity in entities)
            {
                dtoList.Add(MapObject(entity));
            }

            return dtoList;
        }
}

From within the service code, the call is as simple as this to create the DTO:

TeamDto teamDto = DtoAssembler<TeamEntity, TeamDto>.MapObject(team);

As you can see, creating a simple DTO mapping can be greatly simplified by using the AutoMapper. For more complicated mapping scenarios, take a look at the AutoMapper documentation for examples.

using (EmailServiceClient svc = new EmailServiceClient())
{
   svc.SendEmail(fromAddress, fromName, toEmail, toName, message);
}

However, there are problems with the how the Dispose method was implemented that could cause an exception to be thrown and not properly caught as described in this MSDN article: http://msdn.microsoft.com/en-us/library/aa355056.aspx.  Therefore, the best practices dictates that Close is called explicitly and the operations are wrapped in a try/catch block:

EmailServiceClient svc = null;
try
{
   svc = new EmailServiceClient();
   svc.SendMail(fromAddress, fromName, toEmail, toName, message);
   svc.Close();
}
catch (CommunicationException e)
{
   svc.Abort();
}
catch (TimeoutException e)
{
   svc.Abort();
}
catch (Exception e)
{
   svc.Abort();
   throw;
}

Since this is fairly lengthy to write for every service call, I instead added a wrapper class (based on code found in this blog: http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx).

public class ServiceProxyHelper<TProxy, TChannel> : IDisposable
    where TProxy : ClientBase<TChannel>, new()
    where TChannel : class
{
    ///
    /// Private instance of the WCF service proxy.
    ///
    private TProxy _proxy;

    ///
    /// Gets the WCF service proxy wrapped by this instance.
    ///
    public TProxy Proxy
    {
        get
        {
            if (_proxy != null)
            {
                return _proxy;
            }
            else
            {
                throw new ObjectDisposedException("ServiceProxyHelper");
            }
        }
    }

    public TChannel Channel { get; private set; }

    ///
    /// Constructs an instance.
    ///
    public ServiceProxyHelper()
    {
        _proxy = new TProxy();
    }

    ///
    /// Disposes of this instance.
    ///
    public void Dispose()
    {
        try
        {
            if (_proxy != null)
            {
                if (_proxy.State != CommunicationState.Faulted)
                {
                    _proxy.Close();
                }
                else
                {
                    _proxy.Abort();
                }
            }
        }
        catch (CommunicationException)
        {
            _proxy.Abort();
        }
        catch (TimeoutException)
        {
            _proxy.Abort();
        }
        catch (Exception)
        {
            _proxy.Abort();
            throw;
        }
        finally
        {
            _proxy = null;
        }
    }

The new calls to our service now look like this:

using (ServiceProxyHelper<EmailServiceClient, EmailService> svc =
   new ServiceProxyHelper<EmailServiceClient, EmailService>())
{
   svc.Proxy.SendMail(fromAddress, fromName, toEmail, toName, message);
}

I ran into a situation where there were several services using a common library of data classes.  However, the proxy classes generated for each service included separate instances of the same class (in this case, ParticipantDto) in different namespaces.  So instead of having the same class, the client application treated them as GoalService.ParticipantDto, UserService.ParticipantDto, etc.

Service Utility (SVCUTIL) to the Rescue

At the heart of the Add Service Reference Wizard is the SVCUTIL command line program, which has several options not exposed through Visual Studio.  To solve our divergent namespace issue, SVCUTIL includes a /namespace option that allows you to specify how to map a contract namespace to the generated .NET proxy namespace.

Therefore, the first key is setting the Namespace attribute in the DataContract attributes:

namespace Example.Business.DataTransferObjects
{
    [DataContract(Namespace= http://schemas.example.com/Services/2009/09")]
    public class ParticipantDto
    {
       …

Now that the namespace has been established, you can create a batch script as defined at http://stackoverflow.com/questions/889621/adding-service-references-to-multiple-wcf-services-that-shared-classes.  This script will execute SVCUTIL against the set of services that share a common set of classes.

@ECHO OFF
SET cmd=C:"Program Files""Microsoft SDKs"\Windows\v6.0a\bin\SvcUtil.exe
SET cmd=%cmd% /out:ProxyClass.cs /collectionType:System.Collections.Generic.List`1
SET cmd=%cmd% /config:Proxy.config
SET cmd=%cmd% /serializable
SET cmd=%cmd% /serializer:DataContractSerializer 

REM ######### Service namespace mappings (Service Contracts and Message Contracts)
SET cmd=%cmd% /namespace:"http://services.example.com/Services/2009/09"
SET cmd=%cmd%,"Example.Business.Services"

REM ######### Schema namespace mappings (Data Contracts)
SET cmd=%cmd% /namespace:"http://schemas.example.com/Services/2009/09"
SET cmd=%cmd%,"Example.Business.DataTransferObjects"

REM ######### Set all the URLs that have common types
SET cmd=%cmd% http://localhost/GoalsService/GoalService.svc
SET cmd=%cmd% http://localhost/UserService/UserService.svc
SET cmd=%cmd% http://localhost/EmailService/EmailService.svc

%cmd%

PAUSE

The newly generated proxy code will contain two namespaces – one for the data contracts (Example.Business.DataTransferObjects) and one for the services (Example.Business.Services).  Therefore not only does this solve our divergent namespace issue, but it also provides a cleaner separation between the service methods and the data classes.

For instance, let’s say we have a User DTO class that contains a property with the person’s height in inches.  If we would like to add some code to compute the person’s height in feet and inches (e.g., 5 feet, 11 inches), it would be nice to add this within the DTO class itself.

Since the generated proxy code uses partial classes, we have a fairly simple solution.  Within our client application, we can add on to the class using the “partial” keyword and then include any additional logic that we need to perform.  Be sure not to make this too complicated since any complex business logic should be done within the business layer, but this is an easy way to implement data formatting or simple computations.

namespace Example.Business.DataTransferObjects
{
    public partial class UserDto
    {
        public int HeightFeet
        {
            get
            {
                return this.CurrentHeight / 12;
            }
        }

        public int HeightInches
        {
            get
            {
                return this.CurrentHeight % 12;
            }
        }
    }
}