I am totally excited to support the folks over at Devlicio.us and their giveaway.  They are giving away MSDN  Licenses to Open Source projects in need of said licenses.  As a Microsoft MVP, I was given three MSDN License’s to help spread the the goodness of VS2010.  As a supporter of Open Source I think the best way to help stimulate the .Net Open Source eco system is to provide license to those who need them. I have tried a few times to get the folks over at the Codeplex Foundation to start up a program, but no luck yet.  That is why I am happy to see the MVPs who are part of the blogging community pulling together to help stimulate these project.

Go see the details here

I want to thank Jimmy Bogard and Keith Dahlby from the Los Techies crew for donating some of their licenses too.

I just uploaded a visual studio project template for creating portable areas. 

You can find the release here: http://mvccontrib.codeplex.com/releases/view/43162

This project template includes a little msbuild trick to automatically include all of your content files as embedded resources, so you do not have to remember to manually keep track of them.  This was a neat little trick that Steve Michelotti pulled together.

Additional information on MvcContrib Portable Areas

• For more information about Portable Areas checkout this blog post series I did on them here: Part 1 – Introduction
• You can also check out this  series that Steve Michelotti put together http://geekswithblogs.net/michelotti/Default.aspx
• The C4MVC (Community For MVC) presentation about Portable Areas
• Check out this podcast on the Polymorphic Podcast about Portable Areas

As time permits I will put together a walk through using the new project template.  It is really pretty simple if you read through the Portable Area series on my blog.

This is my second time of calling to the community to support some feature requests I have made for the CodePlex website.   The first time I did this, I got a great response. The community voted my issue up and the codeplex team promptly implemented the feature. It was a simple feature and the community clearly thought it had value.  I am making a call for help.

There are two issues that I feel will make the site more usable to projects like MvcContrib. One will allow me to configure the project site so that it is easier for new users to understand we host our code at Github rather than on codeplex.  The other is making the project site a place where I can add information that the contributors need.  This will help the project be sustainable over the long term, I need a place where I can put license keys and other information that the committers need to keep the project running. 

Vote for the Following Codeplex Features.  You will need to create an account on codeplex do this, by doing so you can make the project site more usable to the people who are getting started using new Open Source Project.

Please Vote for Both of these Features:

• 
  

  Allow menu items to point to wiki pages.

• 
  

  Support for hidden Wiki pages.

I appreciate your support.  Please feel to blog and tweet and email your friends about this campaign!!!

Thanks,

Eric

MsDeploy is a newish technology that is a bit schizophrenic.  What I mean is that it is a tool that is useful to both Developers and Administrators but it is not clear from the documentation how to best use the technology and how to approach it. I believe it stated as a Server Administrator tool and the team was able to work in an integration with Visual Studio which made it into a more robust framework, but at the same time left is command line interface with so many options that it is challenging to get a grasp on.  To top that off the Web Platform Installer uses the MsDeploy packages as a way to distribute packages through that tool.  After working through some various ways to use the technology I have settled into some commands that work well for our projects.

Let me set the context of how we are using the tool and what we already had in place so that you can better understand if my use of MsDeploy will work for you. At Headspring we use Continuous Integration on all of our projects and as a result, once our software is built by our build server the next logical step is to deploy our software to a server and than run User Interface tests against the application. Most of our projects are web applications running on ASP.Net MVC using Sql Server as the back end.  We install our software using a lightweight zipfile that contains the web application files, database migration scripts and a deployment script which can poke config files and execute our database migration tool.  We already have all the pieces in place to deploy our application on a local machine.

Up until know we have used two methods to deploy instances to remote machines.  The first methods was to install Cruise Control.Net on the server and have it monitor our source control repository for a new installation package being committed to the repository. Once it sees a new package CCNet will pull down the package, install it locally and go on its merry way.  The second method, is to kick off the deployment from the build server and connect over the network to the target database to run upgrades and then xcopy the files to a unc share.  Both of these methods require setting up some configuration on our target servers. My goal with our deployments is to reduce the amount of per server configuration we do on each server and use some conventions to make each server look similar to one from a different project.

Using MSDeploy allows us to do the following.

1. Remove the need to install cruise control on the target server and update the configuration for cruise control on each target server.  We do have to install MSDeploy on each server but we do not have to mess with any configuration after that.

2. We do not have to mess with setting up unc shares and deal with the mess.  It sounds like a silly thing but by getting away from the unc share we can also test our deployments from any machine and msdeploy is actually firewall friendly.  xcopy to a unc share is not firewall friendly which means that we cannot use it for all of our clients which means variations between our projects. 

3. We use msdeploy as a mechanism to distribute our deployment packages and then remotely execute the packages.  This means I can have a single instance of our Continuous Integration server which reduces the number of places to maintain configuration.  That is a big win.  This also means the log files for all of the deployments can be tracked in a single place.

4. Another benefit of using msdeploy to push our deployments means that I can easily setup new instances of a test configuration and push it to multiple servers without having to log into each machine.. This is good for efficiency.

Our use of MSDeploy now boils down to two steps.  Distribute and Execute.  We have some of our scripts in NAnt and we are in the process of migrating to PowerShell now that version 2.0 is available from the older operating systems.  Below is a sample of executing msdeploy from a NAnt script.

Calling MsDeploy from Nant

The dirPath  command tells MSDeploy to synchronize a directory from the source computer a target computer. This is a pretty easy command to understand.

The second command is the runCommand this command was added between the RC and 1.0 release of MSDeploy and I am so happy they added it. The run command is told to execute a command on the remote machine.  Since we are running installation scripts, they do not execute instantly and as a result the waitInterval and waitAttempts need to be specified so that the command does not timeout before it has completed running. other than that the output of the console application is piped back to the source computer.  The one caveat about the run command is that when it starts it runs from the C:\windows\system32 directory.  In order to work around this issue I have found that passing the directory of the command into the batch file that I run allows my batch files to first cd to that directory as its first step.  This is a pretty harmless thing to do and works pretty well.

This is what a sample deployment batch files looks like.

cd %1
rd ..\codeToDeploy\ /s /q
applicationNamePackage.exe -o..\CodeToDeploy\ -y
cd ..\CodeToDeploy\
cmd /c %systemroot%\system32\inetsrv\appcmd stop site applicationName_dev
iisreset
call dev.bat
cmd /c %systemroot%\system32\inetsrv\appcmd start site applicationName_dev

This is pretty basic and does some IIS commands as well. 

I am sure I left some information out, but I wanted to get a brain dump of our use of MSDeploy.

Long term I would like to see the use of PowerShell driving msdeploy and adding some configuration around each Server Role in an application and tie it to the servers needed for each environment.  I have started a project to put this together called psTrami but I have not put any of the code together yet, just some small spikes to prove it out.

More to come sometime soon…..

On some of our projects we have been experimenting with smaller AutoMapper profiles.  The idea is that it is easier to digest a smaller profile. We have gone so far as creating a profile for each Domain object and handle all of the mappings to and from the domain object.  We are also trying out a Profile per scenario.  While these smaller profiles are easier to dig in and understand, the registration of them are a little painful.  So I put together a quick way to auto register all the profiles for automapper.  Below is the code to discover all the profiles in an assembly than register them with AutoMapper.  There is nothing fancy here and I could certainly spend more time making it better performing, but realistically this is startup code that runs once at application start up.  That being said I would rather focus performance optimization efforts on places that actually make a difference to the End User Experience.

Here is the sample.

It is important to know that we have full code coverage over our application including integration tests, so that if something were to break as a result of loading this in a non deterministic order, we would know before we commit our changes to source control.

Here is the code for the ForEach extension method, since I breezed over it.

This is a smaller post than I normally put together.. is this small of a post useful?

This is a multi post series on ASP.Net MVC Portable Areas

• Part 1 – Introduction
• Part 2 – Sample Portable Area
• Part 3 – Usage of a Portable Area
• Part 4 – IoC framework support

What is a Portable Area?

A Portable Area is a set of reusable multi page functionality can be dropped into an application to provide rich functionality without having to custom build functionality that is literally the same in every application. This could be considered a plug-in or add-in type of functionality.  The portable portion of this approach is that the area can be distributed as a single assembly rather than an assembly and a host of other files, like views or other html assets that need to be managed and maintained over time.  By making a portable area totally self contained in a single assembly, this should allow for easier reuse and upgrades to the area.  The challenge for doing something like this has been how do you allow enough control over the User Interface by the application yet still allow the actual views to be packaged with the logic.

Why Now?

There has been some discussion in the past on the MvcContrib mailing list about creating an plug-in framework and plugins but I do not think we had enough of the pieces in place to do this properly.   I believe that with MVC 2 we have those missing pieces figured out.  The first enabler is the inclusion of Areas into the MVC 2 feature set. This includes having the Area and Controller namespace become part of the route data which is used both for Controller/Action selection but this also flows down to the selection of a view. The second enabler is some of the work that came out of MvcContrib and the Input Builders.  While implementing that feature we came up with a way to pull views from an assembly as an embedded resource.  This with the ability to override the default view engine in a way that allows an application developer to place their own version of a view in a folder so that they have the option to change the view to their needs was huge.  The last enabler really comes from what we have learned from all of the SOA greats and see how frameworks like nServiceBus and MassTransit have demonstrated that a messaging approach for integration can keep our concerns separated.

The other why now is that my company, Headspring, has found that in order to make our practice more successful, we need the ability to drop in some of the essentials for an application, we would prefer to do this in a binary form that is easy to upgrade and does not leave us with copy and pasted code between our various projects.  We would like to see that if we learn something from one project that we have the potential to apply those learning’s to projects that are still in flight. We all prefer that rather than waiting for the next project to start so that we can apply what we have learned to the new project.  This approach will be much better for us as developers and our client will benefit as well.  We could take the approach of working on this in a bubble but by putting this out for the community we can learn from every else and potentially help others in the process and raise the collective bar for the industry, in our own little way.

Logical View of a Portable Area

Below is a logic view of a Portable Area.  It shows how the Green block is an application.  Inside the application the blocks in dark blue are framework components in ASP.Net MVC 2 and MvcContrib.  These blocks provide some minimal framework support for registration view resolution and communication between the application and the portable area.  The light blue blocks represent code the developer create.  The code in the Portable Area is created by the Portable Area developer. The code in the application block is coded by… you guessed it. The application developer.

Thanks for the Pictures but where is the code?

The code is currently available in the MvcContrib MVC 2 Branch.  You can get the latest binary from our (TeamCity/CodeBetter) build server here:  http://teamcity.codebetter.com/guestAuth/repository/download/bt83/.lastSuccessful/MVCContrib.release.zip

There is a sample application you can download here: http://teamcity.codebetter.com/guestAuth/repository/download/bt83/.lastSuccessful/MVCContrib.Extras.release.zip 

or from the code repository on GitHub:  Download the source as a zip.  or Fork it on GitHub.

We recently moved the MvcContrib projects source code over to GitHub.  We are hoping that the ease of creating forks and pulling them back into the trunk will allow for more contributions to the project.  I know that GIT seems to be a source control system that few developers in the .Net space seem to know about but Jeremy Skinner created a great tutorial specifically for the MvcContrib project.

Here are the sections of the tutorial

Continuous Integration is running on the Codebetter TeamCity server.  Codebetter and Jetbrains have teamed up and are providing free build server for opensource projects.  Below is the MvcContrib builds, we currently have 3 builds running.. the old Subversion source. the new Git Hub trunk, and a branch on GitHub that is compiled against the MVC 2 ctp. If you want to download the binaries you can do so by accessing the artifacts from the build server.  When you go to the team city server it will prompt you for a login. Select the Login as Guest option.

The build server is located here http://teamcity.codebetter.com/project.html?projectId=project10

The MvcContrib home page is still located here:  http://MvcContrib.org