When initially setting up new Recovery Services on Windows Azure for the Azure Online Backup service, you are asked to provide a certificate that will be used to manage the identity of the servers allowed to back up to the specified vault. You have the option to either purchase a certificate, or create a self-signed certificate.

We found that the default instructions provided for creating a self-signed certificate are incomplete. If you create a self-signed certificate with an expiration date over 3 years, Azure will reject your certificate, but not tell you why.

To have your self-signed certificate accepted by the Azure Online Backup service, you must specify an expiration date of less than 3 years, and include the other parameters in the example below. Replace the highlighted sections with the information specific to your certificate:

makecert.exe -r -pe -n CN=CertificateName -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 CertificateName.cer

For better instructions and details on managing certificates for the backup service, we recommend referencing the following page found on the MSDN web site:

Recovery Services: Upload Certificates to the Vault

The Microsoft Office IT Pro Blog has recently posted a list of all Office Web Apps for SharePoint 2010 updates since SP1 and the July 2011 updates. They also provide guidance on the order in which they should be applied.

You may want to review the updates for any fixes or enhancements that your SharePoint 2010 farm needs.

The March 2013 Public Update was recently released for SharePoint Server 2013. The update includes several fixes, as well as required changes to the package configuration introduced after SharePoint Server 2013 RTM to allow for future updates to be applied to a SharePoint Server 2013 installation / farm. As such, this is essentially a mandatory installation for all SharePoint 2013 installations.

The description and information can be found on the official Microsoft KB (2767999) article, or on Stefan Goßner’s blog.

Note that the guidelines also include additional steps for installing the March 2013 PU on servers where the search component is installed and where high availability search topologies are enabled. The former would include small farm installations, where all components are on one server.

Below is a screenshot walkthrough of installing the March 2013 PU on a SharePoint Server 2013 RTM installation, in a lab environment.

Update Steps

Per the guidance provided in the additional steps, the following Services were placed in a Stopped state and disabled to allow for proper installation. Note the recommended order in which the services must be stopped:

1. SharePoint Timer Service (SPTimerV4)
2. SharePoint Server Search 15 (OSearch15)
3. SharePoint Search Host Controller (SPSearchHostController)

The next step is to run the 1.7GB (whew!) update file for March 2013:

At this point, you can restart the services in the following order:

1. SharePoint Search Host Controller (SPSearchHostController)
2. SharePoint Server Search 15 (OSearch15)
3. SharePoint Timer Service (SPTimerV4)

Next, run the SharePoint 2013 Products and Configuration Wizard to complete the update:

Verification Steps

Per the instructions for verifying database upgrades, we can then access Central Administration, and view the “Upgrade Status” page, and see that it was successful:

We can also access the “Servers in the Farm” page in Central Administration, and see that the configuration database version is now 15.0.4481.1005, which is the version number corresponding with the March 2013 Public Update:

If you have multiple servers, you can also view the “Check Product and Patch Installation Status” page, and verify that each server in the farm has been updated:

Additional Updates

There are also additional updates for the following that may apply to your installation:

• Office Web Apps Server 2013 (KB2760445)
• Service Bus 1.0 CU (KB2799752)
• Workflow Manager 1.0 CU (KB2799754)

The 3rd Annual Nebraska Code Camp was another huge success.  The conference again had top notch speakers from around the country including the keynote speaker, Ted Neward.  Deliveron Consulting Services had the honor of being a sponsor for the second year in a row.  Thanks to everyone that stopped by our booth and came to my talk.  It was great seeing familiar faces and meeting a lot of new people.  I’m looking forward to going back again next year.

My talk was Developing a Windows 8 C#/XAML MVVM Application.  I had a lot of fun giving this talk.  I have been learning how to build a Windows 8 Store app for the past 3 months building an application that using TFS 2012 and Windows Azure Mobile Services.  I am hoping to publish to the app store in the next week.  I enjoyed sharing what I have learned so far and explain what is next.  I have the slides and sample code from my talk shared on my SkyDrive.  Feel free to contact me with any questions.  My contact information is in the slide deck.

In my last post I talked about a mapping option in Entity Framework called table splitting. Table splitting allows you to take a single physical table and split it into multiple entities in your Entity Framework model. Today I will talk about another modeling option called entity splitting.

Entity splitting gives you the ability to take a single entity in your model and split it into multiple physical database tables. It is essentially the opposite of table splitting. When you query this entity in Entity Framework, it will create a query that automatically joins to the tables for you. Consider the following entity in Code First:

public class User
{
    // these fields come from the Users table
    public int UserId { get; set; }
    public string Username { get; set; }

    // these fields come from the UserProfiles table
    public string FavoriteColor { get; set; }
    public string EmailAddress { get; set; }
}

The above model stores information about a User in our system. The UserId and Username properties will be stored in the Users table, and the EmailAddress and FavoriteColor properties will be stored in the UserProfiles table. Without adding the configuration, Code First will use the default conventions to create a single table (dbo.Users) where all 4 properties would be stored. Let's change that by overriding the default conventions:

public class EntitySplittingContext : DbContext
{
    public IDbSet Users { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            // Map to the Users table
            .Map(map =>
            {
                map.Properties(p => new {
                    p.UserId,
                    p.Username
                });

                map.ToTable("Users");
            })
            // Map to the Users table
            .Map(map =>
            {
                map.Properties(p => new {
                    p.FavoriteColor,
                    p.EmailAddress
                });

                map.ToTable("UserProfiles");
            });
    }
}

We use two Map statements to select which properties go to the Users table and which properties go to the UserProfiles table. Entity Framework will create two tables in the database with a one-to-one relationship. Since we chose to have UserId belong to the Users table, it will treat that table as the Parent table. The UserProfiles table will also contain a UserId primary key column but it will not be an identity and will contain a foreign key reference back to the Users table.

As I mentioned before, when we query the Users entity the query that is generated for us will automatically perform a join between the two tables. Here is a query that demonstrates this behavior:

using(var db = new EntitySplittingContext())
{
    var users = db.Users.Where(u => u.Username == "Travis.Ellis").ToList();
}

-- SQL Query
SELECT 
[Extent1].[UserId] AS [UserId], 
[Extent1].[Username] AS [Username], 
[Extent2].[FavoriteColor] AS [FavoriteColor], 
[Extent2].[EmailAddress] AS [EmailAddress]
FROM  [dbo].[Users] AS [Extent1]
INNER JOIN [dbo].[UserProfiles] AS [Extent2] ON [Extent1].[UserId] = [Extent2].[UserId]
WHERE N'Travis.Ellis' = [Extent1].[Username]

A significant benefit to using Entity Framework is that your entity model does not have to match your database model. One of the ways this is accomplished is by using Table Splitting, which is having two entities in your model map to the same physical database table.

An example of using table splitting would be if you have a Customer entity that contains details about a Customer (first name, last name, e-mail, etc.) and a separate entity to store their address. The database table might store all of this information in a single physical table, but we might not want to pull back the Address every time we want the Customer information.

To accomplish this scenario in Code First you will need the following two entity classes and DbContext configuration:

public class Customer
{
    public int CustomerID { get; set; }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string EmailAddress { get; set; }

    public CustomerAddress Address { get; set; }
}

public class CustomerAddress
{
    public int CustomerID { get; set; }

    public string Line1 { get; set; }
    public string Line2 { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }

    public Customer Customer { get; set; }
}

public class TableSplittingContext : DbContext
{
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
            .HasKey(pk => pk.CustomerID)
            .ToTable("Customers");

        modelBuilder.Entity()
            .HasKey(pk => pk.CustomerID)
            .ToTable("Customers");

        modelBuilder.Entity()
            .HasRequired(p => p.CustomerAddress)
            .WithRequiredPrincipal(c => c.Customer);
    }

    public IDbSet Customers { get; set; }
}

The database that gets generated from this model will have a single table in it that looks like the following:

Now when you write a query to retrieve a Customer it will only retrieve columns related to the Customer and not the address. If you retrieve a Customer with the Address it will generate a query that selects both sets of columns. Here is an example of both of those queries and the resulting SQL queries that get generated:

using(var db = new TableSplittingContext())
{
    var customers = db.Customers.ToList();
    var customersAndAddress = db.Customers.Include(c => c.Address).ToList();
}

-- Query 1
SELECT 
    [Extent1].[CustomerID] AS [CustomerID], 
    [Extent1].[FirstName] AS [FirstName], 
    [Extent1].[LastName] AS [LastName]
FROM [dbo].[Customers] AS [Extent1]

-- Query 2
SELECT 
    [Extent1].[CustomerID] AS [CustomerID], 
    [Extent1].[FirstName] AS [FirstName], 
    [Extent1].[LastName] AS [LastName], 
    [Extent1].[Line1] AS [Line1], 
    [Extent1].[Line2] AS [Line2], 
    [Extent1].[City] AS [City], 
    [Extent1].[State] AS [State], 
    [Extent1].[ZipCode] AS [ZipCode]
FROM [dbo].[Customers] AS [Extent1]

As you can see the first query only pulls the relevant Customer details and the second query pulls both the Customer and Address columns, all coming from a single table. This allows the queries that do not need Address information to be more efficient. In a future post I will talk about Entity Splitting, which is the opposite of table splitting in that two tables map to a single Entity in the model.

I recently had a team ask me about changing the default check in option from Resolve to Associate in Team Foundation Server 2012 (TFS 2012). I did some research and found there is a lot of confusion around the available options.  I am going to describe the two main options to help you decide which option will work best for you and your team.  So, why is changing this important? Our Deliveron ALM Delivery Guidance recommends that each person should update his/her tasks before stand-up each day.  We also recommend the hours be zeroed out for completed tasks, however the task should be left open until stand-up.  During the stand-up the task will be moved from Active to Closed where the team can celebrate the victory.  I have seen teams use clapping, snaps, and noise makers to name a few.   When developers check-in his/her code, they should always associate the check-in to the appropriate work item(s) but not choose Resolve.  Resolve is the default option but by choosing this, it will automatically close the Task bypassing being able to close it during the stand-up. 

Figure 1 – Resolve is the default option for Tasks and Bugs

Changing the option to Associate each time seems small but it would be nice to change the default option from Resolve to Associate.  In TFS 2010 it was relatively simple to change this by updating a registry key.  However, in TFS 2012 there are two options that address this in different ways.  Both options have some drawbacks. I will explain the two options and let you make the decision which you prefer.

Removing the Check-In Action from the Work Item Template (WIT)

One way to address this is to remove the Check-In action from each WIT.  Using the TFS Power Tools, you can remove the Action from the Transition.  In the Task, you need to remove it from the New –> Closed and the Active –> Closed transitions.  To do this, double click on the Transition title bar to open the Workflow Transition dialog.  Navigate to the Actions tab and delete the Action.  In addition to the Task, you should also remove this from the Bug WIT since these are the two types of work items that you would typically associate your check-ins to.

Figure 2 – Removing the Check-In action from the WIT

Once the WITs have been updated into your team project this will be available for all users.  Now when you add a related work item, the only option available is Associate.

Figure 3 – The default and only option is Associate

As I mentioned, this solution has some pros and cons. Here is a few to consider:

Pros

• This change only has to be made the Team Project and nothing has to be done on the clients.
• We recommend not resolving the work item, so removing this option is not a big deal.

Cons

• This would need to be applied to all current Team Projects and would need to update the Process Template for future Team Projects.
• This removes the Resolve option for users, so there is no way to perform this action anymore.

Updating Visual Studio clients to change the default option to Associate

This option sounds good.  Unfortunately it only works under one scenario.  With the Team Explorer 2012, there are two primary ways to initiate a check in.  You can initiate the check in from the Pending Changes Pane and from My Work Pane.  By default if you initiate the check-in from either location, the default option will be Resolve.  Once this fix has been applied, it will update the default option when initiating the action from the My Work pane but not the Pending Changes Pane.  I will show you how to set this up but first I will show you the scenario that doesn’t work and the one that does work.

From my experience, most check-ins are initiated from the Pending Changes pane or by right clicking on a location in Solution explorer.  Either way you will end up on the Pending Changes pane, where you can associate a work item by query or by ID.  Unfortunately the change has no effect on this and will continue to default to the Resolve option as shown below.

Figure 4 – Pending Changes still defaults to Resolve after updating the registry key.

In Team Explorer 2012, there is a new Pane called My Work.  This Pane is designed to group and manage all of your current work including code, break points, and associated work items.  This provides the ability to suspend/resume your current work so you can switch to work on something else and then come back to it later with everything the way you left it.  After applying the update, initiating the check-in from here will change the default option to Associate.

Figure 5 – Initiating the check in from My Work changes the default to Associate after the updating the registry key.

Now that you understand the scenarios.  To enable this option, each Visual Studio user will need to update the following registry key and change ResolveAsDefaultCheckinAction = False.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\SourceControl\Behavior

 
Figure 6 – Set ResolveAsDefaultCheckinAction = False

Next, exit all instances of Visual Studio 2012.  Open the Developer Command Prompt for VS 2012 with administrator privileges.  Run devenv /setup to ensure that the registry is picked up by Visual Studio.

Figure 7 – Run devenv /setup to ensure registry change is applied.

With the change applied, the default option is changed for your My Work initiated check ins.

For this option, here are several pros and cons:

Pros

• This change only has to be made once for it to apply to all TFS servers and Team Projects that you use.
• This keeps the Resolve option for the most flexibility.
• Only developers that want to change the default option will be affected.

Cons

• Most check ins are initiated from the solution or Pending Changes where this update does not work.
• Each Visual Studio user needs to perform this update for it to work for them.

Summary

As you can see there isn’t a perfect option.  Hopefully this gives you a complete picture of the options so you can make the best decision for your team. We chose the first option because the Resolve option would be rarely used.

Mike

In ASP.net MVC, the ModelStateDictionary class contains all of the validation errors for your models that get posted from your forms. The HTML helpers Html.ValidationSummary and Html.ValidationMessageFor will look at the Model State to display these validation messages. When you are submitting your form with an AJAX request and return a JSON response, then you need to have a way to return these validation errors to your views. Here is a helpful extension method that will allow you to do that:

public static class ModelStateExtensions
{
    public static IDictionary ToSerializedDictionary(this ModelStateDictionary modelState)
    {
        return modelState.ToDictionary(
            k => k.Key,
            v => v.Value.Errors.Select(x => x.ErrorMessage).ToArray()
        );
    }
}

Now in your controller action you can return this data back to your view:

[HttpPost]
public ActionResult Create(ProjectModel model)
{
    // Validation Errors
    if(!ModelState.IsValid)
    {
        return Json(ModelState.ToSerializedDictionary());
    }

    // Success - Save Project data
}
}

In your view you can now write some javascript code to display the errors in your view.

Deliveron is proud to congratulate our very own Mike Douglas, an active ALM Ranger of Microsoft and a Microsoft Visual Studio ALM MVP, in helping to author the new book, “Testing For Continuous Delivery with Visual Studio 2012”.  Congratulations to Mike on a great achievement!

There is also a downloadable pdf available:  http://msdn.microsoft.com/en-us/library/jj159345.aspx

Recently, I have had two article published on MSDN and had the opportunity to help do a technical review for a book.  Here are the overviews and links to the full articles in case you missed them.

Testing for Continuous Delivery with Visual Studio 2012
This is an excellent guide for transforming traditional and manual testing practices to support modern iterative development with continuous delivery.  This book is available as a free PDF.  Here are some highlights:

• Create and use effective unit tests, load, and performance tests.
• Record and play back manual tests to reproduce bugs and verify the fixes.
• Transform manual tests into code to speed up re-testing.
• Understand how the lab environment works and how it supports a project.
• Monitor your project in terms of tests passed.
• Run build-deploy-test workflows on virtual lab environments.
• Evolve your testing process to satisfy the demands of agile and continuous delivery.

Read More

Continuous Feedback using Storyboarding, Code Reviews, and the Feedback Tool in Visual Studio 2012 ALM
One of the key advantages of Agile or any other kind of iterative development process is to receive feedback early and often throughout the development process instead of waiting until the end. Traditionally this has been accomplished by teams working closely together where the decision makers can simply turn around to tell developers what they like and don't like. This type of collaboration becomes much more difficult with distributed development teams. Visual Studio 2012 has introduced several tools to help distributed teams collaborate better by being able to request, provide, and receive feedback throughout the development process.

Read More

Code Coverage in Microsoft Test Manager in Visual Studio Update 1
If you are QA professional, have you ever wondered how much of the application code is covered by your tests? Or if you are developer, have you ever wished you knew if there is any code that is no longer being called? Code Coverage for MTM makes it possible for QA professionals to know how much of the application code is being covered by Test Cases executed within MTM. Developers will know if all of code is being accessed by the application and a valid test case. Furthermore, developers can help the QA team identify scenarios in order to access the uncovered code blocks.

Read More