Benjamin Day Consulting, Inc.

VSLive Chicago 2013: TFS2012 Build Customization talk

Ben Day — Wed, 15 May 2013 16:15:08 +0000

Thanks to those of you who came to my TFS2012 Build customization talk at VSLive Chicago 2013 yesterday. As promised, here are the slides and samples from the talk.

Team Foundation Server 2012 Builds: Understand, Configure, and Customize
The Build system in TFS2012 could be the best feature in the product. Actually, it’s almost definitely the best feature in the product. It’s got a slick Windows Workflow structure that has done away with the old-style, clunky text-based and XML-based scripts. It’s got a great integration with Source Control through Gated Check-ins that requires a build to pass before code can be checked in. (Buh-bye, broken builds.) There’s even integration with Virtual Lab Management to help with your QA process.
If you want to eliminate a bunch of integration headaches and improve quality on your project, using TFS Builds is a perfect place to start.
In this talk, Ben will start by giving you a tour of the features. Then he’ll move on to show you how to configure your build servers and builds. Finally, he’ll show you how to extend and customize the default build scripts to handle environment-specific configuration files, configuring IIS applications, and more.

Enjoy!

-Ben

– Looking for help getting going with Team Foundation Server 2012 Builds? Looking to get Lab Management configured? Looking to automate your QA test cases and run them from your TFS2012 Builds? Drop us a line at info@benday.com.

VSLive Chicago 2013: “Design for Testability” slides & code

Ben Day — Wed, 15 May 2013 16:13:19 +0000

I just wrapped up at VSLive Chicago 2013 and, as promised, here are my slides and code samples from the “Design for Testability: Mocks, Stubs, Refactoring, and User Interfaces” talk.

Design for Testability: Mocks, Stubs, Refactoring, and User Interfaces
You’re sold on unit testing. You’re even doing “test first” development – but there are always those nagging questions. How do your user interfaces fit into your testing plan? Do I have to call my database in order to have a good, solid test? What about calls into separate sub-systems or calls out to web services? Do you really need to have all those pieces running in order to test your logic? Are my UI tests the same for WPF, Windows Forms, Windows Phone, Win RT, and ASP.NET? What do I do about that app that doesn’t have any tests?
In this session, Ben will start by clarifying the difference between “unit” and “integration” tests. After that, he’ll demonstrate how using dependency injection, mocks objects and stubs can help break dependencies and simplify your tests. Throughout the talk, you can expect to hear a lot about design patterns, how much code coverage is enough, and the fine line between too much and too little object mocking.

Enjoy!

-Ben

– Looking for help getting going on unit testing, integration testing, and Coded UI testing? Want to raise your testing game? Got an ‘untestable’ app that you’d like to start testing? Drop us a line at info@benday.com.

Problem moving virtual machines between Hyper-V 2012 hosts

Ben Day — Thu, 09 May 2013 15:38:53 +0000

(Huge thanks to Antone Heyward for the answer to this problem.)

One of the things I love about Hyper-V 2012 is that you can easily move Hyper-v virtual machines (guests) between Hyper-V hosts using the Hyper-V Manager app. Sure, in previous versions of Hyper-V you could do an Export, Copy, and Import to move VMs between hosts but that’s a lot of manual steps. Or, if you were feeling really motivated, you could set up System Center Virtual Machine Manager and have SCVMM handle moving your hosts around.

I ran into a problem today moving some VMs between some new Hyper-V hosts. I’d right-click on the machine, choose Move…, and then go through the migration wizard only get an error. Here’s the error:

“Failed to establish a connection with host ‘VESIME’: the credentials supplied to the package were not recognized (0x8009030D). The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: no suitable credentials available. Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and Constrained Delegation is enabled for the host in Active Directory.”

Right-click the VM you want to migrate and choose Move… from the context menu.

Here’s that error message.

Two things popped out at me in that error. 1) “Make sure the operation is initiated on the source host” and 2) “make sure…Constrained Delegation is enabled for the host in Active Directory.” For item #1, I tried logging in to the source server and starting the migration from there and it worked. Win. But that’s a bit of a pain so I started looking for how to enable Constrained Delegation.

The answer came from Antone Heyward’s blog post “Microsoft Hyper-V 2012 Live Migration and Constrained Delegation”. Antone has a full walk-through on his blog but here’s the short form.

Step 1: Go to Hyper-V settings for the host machines and enable Live Migrations using Kerberos.

Step 2: Go to Active Directory Users and Computers and for each Hyper-V host server enable delegation for “cifs” and “Microsoft Virtual System Migration Service” for all the servers you want to migrate to/from.

Done and done.

-Ben

VSLive Las Vegas 2013: TFS2012 Build Customization talk

Ben Day — Wed, 27 Mar 2013 20:32:53 +0000

Thanks to those of you who came to my TFS2012 Build customization talk at VSLive Vegas 2013 yesterday. As promised, here are the slides and samples from the talk.

Team Foundation Server 2012 Builds: Understand, Configure, and Customize
The Build system in TFS2012 could be the best feature in the product. Actually, it’s almost definitely the best feature in the product. It’s got a slick Windows Workflow structure that has done away with the old-style, clunky text-based and XML-based scripts. It’s got a great integration with Source Control through Gated Check-ins that requires a build to pass before code can be checked in. (Buh-bye, broken builds.) There’s even integration with Virtual Lab Management to help with your QA process.
If you want to eliminate a bunch of integration headaches and improve quality on your project, using TFS Builds is a perfect place to start.
In this talk, Ben will start by giving you a tour of the features. Then he’ll move on to show you how to configure your build servers and builds. Finally, he’ll show you how to extend and customize the default build scripts to handle environment-specific configuration files, configuring IIS applications, and more.

Enjoy!

-Ben

VSLive Las Vegas 2013: “Design for Testability” slides & code

Ben Day — Wed, 27 Mar 2013 20:11:37 +0000

I just wrapped up at VSLive Las Vegas 2013 and, as promised, here are my slides and code samples from the “Design for Testability: Mocks, Stubs, Refactoring, and User Interfaces” talk.

Design for Testability: Mocks, Stubs, Refactoring, and User Interfaces
You’re sold on unit testing. You’re even doing “test first” development – but there are always those nagging questions. How do your user interfaces fit into your testing plan? Do I have to call my database in order to have a good, solid test? What about calls into separate sub-systems or calls out to web services? Do you really need to have all those pieces running in order to test your logic? Are my UI tests the same for WPF, Windows Forms, Windows Phone, Win RT, and ASP.NET? What do I do about that app that doesn’t have any tests?
In this session, Ben will start by clarifying the difference between “unit” and “integration” tests. After that, he’ll demonstrate how using dependency injection, mocks objects and stubs can help break dependencies and simplify your tests. Throughout the talk, you can expect to hear a lot about design patterns, how much code coverage is enough, and the fine line between too much and too little object mocking.

Enjoy!

-Ben

Slides & Video from “Agile Under a Waterfall” talk at ALM Summit 2013

Ben Day — Wed, 30 Jan 2013 22:07:22 +0000

I finished up presenting at the 2013 ALM Summit a little while ago where I presented “Agile Under a Waterfall.”

Agile Under a Waterfall
It would be so easy if everyone at our companies just used Scrum — or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it — an all-Agile organization isn’t always possible. Maybe you have a Project Management Office (PMO). Maybe you work for a government contractor. Maybe you have regulatory requirements. Maybe you’re the first Scrum/Agile project at your company. Maybe your company simply *likes* it this way. Whatever the reason, Agile teams frequently report into Waterfall organizations.
Your team thinks “backlog” and your bosses think “project plan.” How do you make it work? How do you ensure communication and foster trust between the two groups? How do you bridge the project management impedance mismatch? You need to find a way get everybody to ‘play nice’ so they can do their jobs.
In this session, we’ll drill into the details of the project management impedance mismatch and talk about strategies to improve communication and delivery when you need to make Agile work inside a Waterfall-centric organization.

As promised, here are the slides for the talk in PowerPoint format and in PDF.

Update 2/18/2013: The video is on Channel 9 for the talk now.

-Ben

– Looking for help with Scrum Under a Waterfall at your company? Thinking about adopting Team Foundation Server and Microsoft Project Server? Want training for your teams on delivering great, working software with Scrum? Drop us a line at info@benday.com.

Strategies for Sharing Code between Windows Phone 8 and Windows 8 Applications

Ben Day — Thu, 24 Jan 2013 19:19:41 +0000

(NOTE: A PDF version of this article is available for download.)

Visual Studio 2012 is out and we can write apps for Windows Store and now (finally) we have access to the Windows Phone 8 SDK and Windows Phone 8 devices. We’ve been hearing and reading for a while that the platforms are very similar to code for and after doing some coding for both platforms I only kind of agree. Windows Store applications for Windows 8 are written using C#, XAML, and WinRT. Windows Phone 8 is still basically Silverlight.

The real big question on everyone’s mind is just how much code you can actually share between your Windows Store apps and your Windows Phone apps. The answer is that you can actually share a lot of code but – get ready to not be surprised – like most things in software, you have to plan for it. That planning will almost definitely require you to abstract away a lot of details and use interface-driven programming.

There are 3 main ways to share code: 1) portable class libraries, 2) multiple projects using linked code, and 3) branching & merging via your source control repository. A Portable Class Library is a project type in Visual Studio 2012 that lets you target multiple frameworks from a single project. In the case of Figure 1 — Choose the frameworks for a Portable Class Library, you can see that the project targets version 4.5 of the .NET Framework, Silverlight 5, Windows Phone 8, and .NET for Windows Store apps. Basically, what’s going on here is that Visual Studio 2012 now becomes smart enough to know what is the lowest common denominator for all of these frameworks, will tell you what isn’t valid, and will generate an assembly that can be referenced by all these platforms.

Figure 1 — Choose the frameworks for a Portable Class Library

The second way of sharing is via linked code. The idea here is that you have two different project files that point to the same classes on disk. Let’s say you have a Windows Phone 8 assembly project and a Windows Store assembly project – respectively, Project A and Project B. You’ll first create a class in Project A and then you’ll go to Project B, choose Add, and then Add An Existing Item. When the Add Existing Item dialog pops up, you select the class file, and then instead of clicking the Add button, you’ll choose Add As Link instead. The Add As Link option isn’t obvious and it’s hidden in a little dropdown menu off of the Add button as shown in Figure 2 — Add an existing item using Add As Link. Once you’ve created the link, any changes you make to that file in one project is instantly reflected in that same file in the other project.

Figure 2 – Add an existing item using Add As Link

The third way to share code is using the branching and merging functionality of a source control repository such as Team Foundation Server 2012. This approach is going to look similar to the linked code version of code sharing. You’ll have two different projects (Project A and Project B) that target different platforms and they’ll have similar files in them. The main difference is that you’ll have two separate copies of the shared files on your disk and any changes you make won’t automatically propagate between projects – you’ll need to perform a Merge in source control in order to move files between projects. The blessing here is that you can track exactly what is shared and you can decide when you choose to move sync code between the projects. If you use the linked code approach, changes you make in Project A might work on that platform but break the app in Project B. The curse with the branching and merging approach is that it’s a little cumbersome.

For any of these approaches, there are upsides and downsides. Sharing via branching and merging appeals to my inner control freak but it’s cumbersome and is almost definitely going to put you into the dreaded and labor intensive “cherry pick merge” model. The Linked Code approach has a fair number of downsides, too. First off, it offends my inner Application Lifecycle Management (ALM) Control Freak because changes instantly appear in both projects. Secondly, it’s exactly the same code in both projects – right down to the namespace. So, you’ll have two classes in your solution that have exactly the same namespace and class name. That nags at me because the default namespace for Project A and Project B might not be the same. In Project A it might be TheAwesomeApp.WinPhone.MyClass and in Project B you might want it to TheAwesomeApp.WinStore.MyClass but you’ll be stuck with the original namespace and now the naming convention in Project B won’t match all the other classes in that project. I know that it’s a little OCD of me but clean, well-organized code is easier to maintain.

Sharing using the Portable Class Library approach for sharing feels like it’s the cleanest and most polished way to go. Like the rest of the sharing approaches, you’ll need to write platform agnostic, lowest common denominator, non-partisan code but you don’t have any branch/merge headaches and you’re dealing with literally the same binary for each platform rather than having to think about a similar but not-quite-the-same version. It’s the same binary. Done and done.

Finding the Lowest Common Denominator (LCD)

Three quick thoughts on Portable Class Libraries (PCLs) and the Lowest Common Denominator (LCD) problem. Thought #1: if you’re writing a PCL, you have to write code that works on all the platforms targeted by that PCL. That set of code that works on all the platforms is the LCD. Thought #2: platform-specific, non-Portable exe’s and assemblies can reference a PCL but a PCL can only reference another PCL. Thought #3: The big things that are different between the platforms are networking code, data-access code, and which APIs are required to be asynchronous. Those three things govern the shape of your application architecture because of what can reference what and what you need to be abstract.

When I write a XAML-based application with C#, I use a layered architecture that is comprised of the following layers:

1) The XAML user interface layer: this is the platform-specific user interface that targets the Phone or the Windows Store or Silverlight or .NET/WPF. This project generates an EXE or a XAP.

2) The Model-View-ViewModel (MVVM) presentation layer: This project contains my ViewModels. The ViewModels are the code-based abstraction of everything that is displayed on a particular screen. My XAML-based user interfaces are going to have references to instances of the ViewModels and use data binding to move information to and from these classes and the running user interface that the user will manipulate.

3) The Model layer: This project contains the Model classes (aka. the “business objects”) that contain my business logic. These Models are what get saved to and from my database or file system storage or web services.

4) The Data Access layer: This project could also be called the Persistence Layer because it is primarily concerned with persisting (aka. saving) my application data to whatever my persistent store is. A persistent store could be a database or a service or the file system or local storage. Basically, anyplace that I can store data so that that data doesn’t disappear when I pull the plug on my app. The classes in the project commonly use the Repository Pattern and the Adapter Pattern to save and load instances of the Models to/from my persistent store.

5) The Common code layer: This project will contain any common code that can be referenced by any of the other layers. This project contains the C# interfaces that are implemented by my Models, ViewModels, Adapters, and Repositories.

In the simplest form, the user interface references the ViewModels which reference the Models which references the Data Access layer and everything references Common (see Figure 3 — Layers and their references). When you’re sharing code across platforms, the ViewModels, Models, and Common code are the same and the XAML UIs and the Data Access layers are completely different. This means that the ViewModel, Model, and Common projects are all going to be PCLs and the other projects will be platform-specific.

Figure 3 – Layers and their references

Remember that thought about what can reference a PCL and what a PCL is allowed to reference? Anything can reference a PCL but a PCL can only reference another PCL. For the XAML UI to the ViewModel the reference will be fine because that’s platform-specific to a PCL. What becomes more difficult is that reference from the Model to Data Access because that’s going from a PCL to a platform-specific DLL and that’s not allowed. (Game over.)

There’s another nifty little detail about PCLs and interfaces and this is why you’re going to care about interface-driven programming if you want to share code between platforms. Let’s say that you define an interface called IPersonDataAccess in a PCL. This interface represents all the operations that your system needs in order to save and retrieve Person model classes. Better yet, let’s say that IPersonDataAccess represents all the operations required to save and retrieve instances of IPerson models. You can now create platform-specific classes that implement IPersonDataAccess. Here’s the cool part – let’s say that your PersonViewModel class depends on IPersonDataAccess to save and retrieve data. As long as PersonViewModel references IPersonDataAccess rather than a platform-specific implementation, you can pass in platform-specific instances of IPersonDataAccess to PersonViewModel and it will be perfectly happy as shown in Figure 5 — ViewModelLocator that creates an instance of PersonViewModel and passes in a platform-specific instance of IPersonDataAccess.

///

/// Interface for person data access
/// defined in a portable class library
///

public interface IPersonDataAccess
{
    Task> GetAll();
    Task GetById(int id);
    Task Save(IPerson saveThis);
}

///

/// Interface for person model
/// defined in a portable class library
///

public interface IPerson
{
    int Id { get; set; }
    string FirstName { get; set; }
    string LastName { get; set; }
    string EmailAddress { get; set; }
}

Figure 4 — IPersonDataAccess and IPerson interfaces in a PCL

///

/// A ViewModelLocator helps keep track of the instances of a
/// ViewModel in an application. They can be either PCLs or
/// platform-specific. This code represents a platform-specific
/// ViewModelLocator.
///

public class ViewModelLocator
{
    public ViewModelLocator()
    {
        // create an instance of PersonViewModel
        // and pass in an instance of
        // WindowsPhonePersonDataAccess
        m_ViewModelInstance = new PersonViewModel(
            new WindowsPhonePersonDataAccess());
    }

    private PersonViewModel m_ViewModelInstance;
    public PersonViewModel ViewModelInstance
    {
        get { return m_ViewModelInstance; }
    }
}

Figure 5 – ViewModelLocator that creates an instance of PersonViewModel and passes in a platform-specific instance of IPersonDataAccess

///

/// This view model class is defined in a PCL and depends on
/// IPersonDataAccess to save and load data.
///

public class PersonViewModel : INotifyPropertyChanged
{
///

    /// Constructor that requires an instance of
    /// the IPersonDataAccess dependency to be “injected”
    ///

    ///
    public PersonViewModel(IPersonDataAccess dataAccess)
    {
        m_DataAccess = dataAccess;
    }

private IPersonDataAccess m_DataAccess;

    public async Task LoadById(int id)
    {
        // call into the instance of IPersonDataAccess
        // to get some data
        var result = await m_DataAccess.GetById(id);

// do something with the result
}

// …

public event PropertyChangedEventHandler PropertyChanged;
}

Figure 6 – the PersonViewModel class depends on IPersonDataAccess and takes an instance of IPersonDataAccess on the constructor

///

/// Implementation of IPersonDataAccess that is
/// specific to the Windows Phone platform.
///

public class WindowsPhonePersonDataAccess : IPersonDataAccess
{
    public Task> GetAll()
    {
        IList theResults = new List();

// do some work that is specific to Windows Phone

return new Task>(() => theResults);
}

    public Task GetById(int id)
    {
        IPerson theResult = null;

        // do some work that is specific to Windows Phone

        return new Task(() => theResult);
    }

    public Task Save(IPerson saveThis)
    {
        // do some work that is specific to Windows Phone

return new Task(null);
}
}

Figure 7 – a Windows Phone-specific implementation of IPersonDataAccess

This pattern is known as Dependency Injection. If Class A relies on another Class B or Interface B in order to do work, that is known as a dependency. Rather than having Class A internally create an instance of Class B, you create that instance of Class B outside of Class A and then “inject” it into Class A’s constructor. If Class A depends on Interface B, then this means that Class A is interface-driven. Being interface-driven and using Dependency Injection helps us to bridge the divide between the PCLs and the platform-specific projects and re-use code. Remember, our problem in Figure 3 — Layers and their references was referencing out platform-specific Data Access code from the Models and ViewModels that live in PCLs. If you code against interfaces you can just inject the versions of the classes that are specific to Windows Phone or Windows Store apps.

Factoring in Asynchronous Code into your Lowest Common Denominator

Over the last handful of years, asynchronous operations have become more and more common. While we’ve known for a while that we can improve the user experience and performance of our applications by making certain operations asynchronous, this generally wasn’t required until Silverlight and Windows Phone 7 (WP7). In Silverlight and WP7, any networking calls had to be async so if your application needed to read or write data over a network, you needed to adjust your application architecture to work with async. That doesn’t sound like that would cause too much difficulty but, since async network calls returned instantly, that makes using methods with ordinary return values pretty much impossible. Windows Phone 8 (WP8) still has the same requirement that network calls be asynchronous but this now gets a lot easier with async, await, and System.Threading.Tasks. Those sharp and jagged edges of asynchronous coding aren’t nearly as scary anymore.

Enter Windows RT and Windows Store applications for Windows 8. If you’re a XAML and C# programmer, WinRT is going to look very familiar but there is a lot of new stuff. New classes. New methods. New project types. And lots more asynchronous code. Once again, just like in Silverlight and WP8, async, await, and System.Threading.Tasks makes working with this asynchronous code fairly painless but if your goal is to share code between platforms, this is where you need to start paying attention. Assuming that you’re doing interface-driven programming, you’ll need to craft your interfaces so that they can adequately wrap (aka “hide”) the details of the most asynchronous platform that you want to target from your PCLs. If you’re targeting both Windows Phone 8 and Windows Store application for Windows 8, the Windows Store apps are definitely going to require more asynchronous code. As a result, if you have the option to do so, you’ll probably want to write the Windows Store version of your libraries first so that you discover as much of the required async logic as possible.

Summary

The good news is that you can definitely share code between the platforms. The bad news is that that sharing won’t happen for free and you’ll need to design your application in order to enable it. Using Portable Class Libraries, interface-driven programming, and Dependency Injection will help you to achieve that sharing. You might be thinking that having to build your application like this is going to be painful or difficult but I think you’ll find that there’s a silver lining for this particular cloud – you’ll be forced to follow some great best practices for application design and you’ll be pleasantly surprised at how it help make your application more maintainable.

NOTE: A PDF version of this article is available for download.

Unit Testing & Test-Driven Development Courseware for Visual Studio 2010

Ben Day — Sun, 20 Jan 2013 16:23:00 +0000

Well, like I mentioned in my last post, I’m planning to publish a lot of the old courseware that I’ve developed over time. The idea is to share the materials that I’m no longer using with the good folks on the internet rather than to have it all sitting around collecting virtual dust on my laptop.

This time, I’m pushing out the labs and slides for my 2-day unit testing & test-driven development (TDD) course for Visual Studio 2010. A few months ago, I started looking at upgrading the VS2010 course to Visual Studio 2012 and decided that it was actually time for a re-write because I don’t really write tests the same way anymore.

The labs for this course focus on process and software architecture patterns for how to:

Create unit tests for a Deck of Cards using TDD
Unit test the Adapter pattern
Unit test the Repository pattern
Using mock objects to test in isolation
Unit testing a user interface using the Model-View-Presenter (MVP) pattern

Here are the materials for the course:

Enjoy.

-Ben

– Looking for training for unit testing and test-driven development with Visual Studio 2012? Want a coach to come show your team how to incorporate tests into your existing applications? Drop us a line at info@benday.com

Lab: Refactor for testability using the Repository pattern

Ben Day — Wed, 19 Dec 2012 12:31:59 +0000

I had a long drive yesterday to go visit a customer and while I was driving it occurred to me that I have LOTS of courseware that I’ve written that is just sitting around gathering virtual dust. Whether they’re parts of classes that never fully came together or they’re for courses that target old versions of Visual Studio, the ideas are still useful and I’d rather share them out than have them just sit around.

A couple of years ago I started working on a software architecture skills course and wrote a lab that walks you through how to refactor an application with tightly coupled data access logic to use the Repository pattern so that the code is more testable. Here’s that lab.

The before and after code for this lab targets Visual Studio 2010 but you’re all a bunch of smartypantses so you probably won’t have too much trouble making it work with Visual Studio 2012. The version of the tool is different but the ideas are still absolutely relevant.

Here are the links to the materials:

Enjoy.

-Ben

– Want some software architecture training or guidance using Visual Studio 2012? Can’t quite figure out how to unit test that application that you have? We can help. Drop us a line at info@benday.com.

Deploy a SQL Server Database project’s *.dacpac with SqlPackage.exe

Ben Day — Tue, 18 Dec 2012 15:39:36 +0000

Are you a big user of the SQL Server database projects? You know…what used to be known as ”data dude”? Did you get way into doing command line deployments of your databases using vsdbcmd.exe? Well, if you are one of those developers and you’ve upgraded to the latest version of the SQL Server Database Projects, then you might be wondering just where vsdbcmd.exe went.

Answer: vsdbcmd.exe has been replaced with SqlPackage.exe.

There were a lot of updates for the VS2012 version of the SQL Server Database Projects so it makes sense that vsdbcmd would get tweeked, too. Especially, since the outputs of database projects have completely changed. (Goodbye, *.dbschema files. Hello, *.dacpac.)

For this blog post, let’s assume a very simple SQL Server Database Project called Benday.SampleApp.Database (as shown in Figure 1) that, upon “compile”, generates a dacpac file named “Benday.SampleApp.Database.dacpac”.

Figure 1 – The database project

Thankfully, IMHO, SqlPackage.exe is about a trillion times easier to work with. If I wanted to deploy this database to an instance of SQL Server named demo2012util, here’s what my command line syntax would be:

SqlPackage /Action:Publish
   /SourceFile:”Benday.SampleApp.Database.dacpac”
   /TargetDatabaseName:BendaySampleAppDb
   /TargetServerName:”demo2012util”

Pretty easy, right? Set the /Action to Publish. Specify the /SourceFile and point it to the *.dacpac. Tell it what to name the database using /TargetDatabaseName. Give it the /TargetServerName for the SQL Server instance. Done.

You can make this even easier if you add a “Publish Database” profile to your project. In Figure 2, you can see the two profiles that I created – one for the “dev” environment named Benday.SampleApp.Database.dev.publish.xml and one for the “prod” environment named Benday.SampleApp.Database.prod.publish.xml. These files contain all the configuration values that you’d use to deploy a SQL Server dacpac into a particular environment.

Figure 2 – The “Publish Database” profiles in the SQL Server Database Project

Since the profile (*.publish.xml) file has all the config values, when you go to deploy the database from the command line using SqlPackage.exe, you don’t have to supply the /TargetDatabaseName or the /TargetServerName anymore and instead you just provide the path to the dacpac using /SourceFile and then specify the profile using the /Profile argument.

Here’s what that command would look like:

SqlPackage
   /Action:Publish
   /SourceFile:”Benday.SampleApp.Database.dacpac”
   /Profile:”Benday.SampleApp.Database.prod.publish.xml”

At this point, you’re probably sarcastically thinking “WHOOPTEEDOOO!!! I’ve exchanged 4 command line arguments for 3 command line arguments! Think of all the extra free time I’ll have now! Thanks, Ben!” If your deployment arguments are as simple as server instance and database name then yah…not that impressive. But there are a lot more configuration options available to you on the command line and typing/managing all those values will definitely be an annoying and error-prone process.

Just for giggles, try double-clicking on one of those *.publish.xml files. You should see the Publish Database dialog for that deployment profile as shown in Figure 3. This dialog lets you set the target database connection and the database name.

Figure 3 – The Publish Database editor dialog

Impressed yet? Not really? Ok. Click the Advanced button. KA-POWWWWWW! Aw snap! You’ve just been pwned! Or whatever the cool kids say in order to indicate that something kinda awesome just happened up. I’m pretty solidly lame. Cut me some slack already. Granddad’s tired. (I’m 38. Practically a senior citizen in the development world.)

ANYWAY! You should now see the Advanced Publish Settings dialog and it should look something like Figure 4. There are a TON of settings that you can…uhmmm…set for your database deployments.

Figure 4 – The Advanced Publish Settings editor dialog

As these settings get complex, it becomes more and more important that these settings aren’t left up to chance and are under version control just like everything else. One of the biggest time savers when it comes to deploying code and databases is having a well-known automated way to deploy where all your config settings are scripted out. If it’s scripted, it’s easy. If it’s under version control, it’s traceable.

Create Your First Database Publish Profile

Ok. How do I create this profile?

Step 1: Right-click the database project and choose Publish (Figure 5)

Figure 5 – Right-click the database project and choose publish from the context menu

Step 2: Populate the values for your settings and click the Create button (Figure 6)

Figure 6 – Enter your settings and click Create Profile

After you click Create Profile, you should see a new *.publish.xml file in your project (Figure 7).

Figure 7 – The new deployment profile

Step 3: This step is optional but I think it’s handy. Change the “Copy to Output Directory” setting on the new *.publish.xml file to “Copy Always” (Figure 8). This ensures that when the project is compiled (via the Build command) that the publish profile is copied to the bin directory along with the *.dacpac file. This makes scripting the deploy using SqlPackage.exe easier when you’re deploying from a developer machine and MUCH easier if you’re deploying from an automated build.

Figure 8 – Set the Copy to Output Directory to Copy Always

I hope this is helpful and/or useful.

-Ben

– Want to streamline your database and binary deployment process? Looking for suggestions on how to make all this run smoothly from Team Foundation Server’s automated build? Thinking it might be nice to get some training on how to put your insanely complex database under source control using SQL Server Database Projects? Drop us a line at info@benday.com.