Posts tagged ‘c#’

November 4, 2013

Continuous deploy of multiple Azure Cloud Services within a single solution using TFS Online

Team Foundation Server is a fantastic configuration management system that integrates with the full Microsoft development stack.

With Windows Azure and its TFS online integration, continuous deploy can easily be set up and customized. However, one frustration I came across, is that I have a solution that has a worker role and a web role. I want these deployed to separate Cloud Services within my Azure Subscription, but the AzureContinuousDeployment build process only supports targeting the first project to be deployed.

In order to get around this, we can modify the AzureContinuousDeployment process to allow the developer to dictate which Cloud Service project to deploy. The first step to do this is to duplicate the AzureContinuousDeployment.11.xaml workflow. You can do this by opening the Source Control Explorer in Visual Studio, and navigating to the BuildProcessTemplates folder.

You will see, in the right hand pane, a list of the Build Process Templates that are available to you.

Build Process Templates

You can copy AzureContinuousDeployment.11.xaml and use the copied Build Process Template to create the alternate template that will allow you to dictate which Cloud Service is deployed.

When you open the copied xaml file you will see the, hopefully familiar, Windows Workflow designer. What we are going to do is modify the process flow to allow the definition of the Cloud Service to deploy.

When you open the xaml file, find the block that defines the Cloud Service to deploy, it will look like this:

Find the Azure Project

You’ll notice that the action that finds the Azure Project in the solution has no inputs to it, this is because it simply looks for the first Azure Project in the solution. In order to look for others, we need to define the MSBuild target name of the Azure Project.

To do this we first need to add an argument to the build process template that can then be configured in the build definition.

Open the argument editor by clicking “Arguments” at the bottom of the content pane and add a new argument.

Next, we can change the block that defines the Azure Project to check if the Alternate MS Build Target has been set and if it is, set ccProjName, the variable that captures the Azure project name, to that value.

We can now save this build process template, and select it in the build definition.

Finally, we need to choose the project that we want to deploy from the build definition.

We do this by setting the AlternateMSBuildTarget argument to the target name that we want to deploy. This is usually the name of the project with _ (underscore) replacing . (period). So, for example, if your project name was “Ebenezer.Web.Azure”, you would use “Ebenezer_Web_Azure”.

September 17, 2010

Code driven auto-model generation using DynamicObject

The DynamicObject base class is a new base class that was released with version 4 of the .NET framework. The DynamicObject base class gives us a number of very cool pieces of functionality, particularly in ORM applications, which will be very familiar to users of interpreted languages such as PHP, Python, Ruby, etc.

DynamicObject sits in the System.Dynamic name space, and gives us inverse functionality of the dynamic keyword. Where the dynamic keyword, when applied to a variable allows method resolving at runtime, such as

dynamic myObj = new MyObj();

//MyObj may or may not have a method called run, this will be resolved at runtime;

DynamicObject allows an object to resolve, at runtime, calls to it’s own methods. Instances of DynamicObject will preferably be instanciated as dynamic objects, as above, but in addition to the call being resolved at runtime, the object itself will respond to the call at run time.

To this end DynamicObject gives us a number of basic methods to override, which will allow us to access and set Properties (TryGetMember, TrySetMember) and Methods (TryInvokeMember). In addition, it allows us to specify what happens when the object is interacted with as an array (TryGetIndex, TrySetIndex, TryDeleteIndex).

As an example, the TryGetMember may be overridden as follows

FieldCollection myCustomFields = new FieldCollection();
PropertyCollection properties = new PropertyCollection();

public override bool TryGetMember(GetMemberBinder binder, out object result)
	//Check if we hold a field of this type
	if (myCustomFields.ContainsField(binder.Name))
		//return the property object associated with that name
		result = properties[binder.Name];
	return base.TryGetMember(binder, out result);

As can be seen this code is implemented very simply, and, in this case, we can use a simple dictionary structure to store names against values.

Where this can really come into its own is in auto generating models based in database definitions. Using the metadata views in SQL Server (all_objects, all_columns etc.), we can pull the fields for a table, and, in the constructor of the dynamic object populate our fields collection. This means when we do CRUD operations, such as a load, we can build queries dynamically, based on the composition of the model. The best thing about this is that no objects need to be changed when database structure is changed, new properties are simply accessed as a property of the dynamic object.

As such we can build up the Fields by pulling all User generated fields for a particular table from all_columns view in a SQL database, filtering by the object name, joining to all_objects view, and the object type (‘U’ for user).

Using this pattern we can build a base class which needs very little extension to handle the vast majority of objects, and we only extend when we need to implement validation, and individual business logic.