PRISM 4.0 P&P Features Survery

Patterns and Practices is soliciting feedback on the features that should make it into PRISM 4.0. If you have experience or knowledge of PRISM, please take few moments to fill out the online survey. It was 20+ questions and took about 5 minutes.

Features Survey

RockNUG: Silverlight 4 Code and Notes

On April 14, I presented an introduction to Silverlight 4 at the Rockville .NET User Group. My sample project code, along with presentation notes, are available here.

Azure team blogs and voting sites

The Azure team has several blogs announcing new features, Azure sites, integration tools, customer stories, and general platform updates:

• Windows Azure blog – visit this blog to see the latest platform updates, as well as OS updates and tools for platform integration (such as Jetty).
• SQL Azure blog – this blog is dedicated to the Azure-specific version of SQL Server. This blog will provide information around new and upcoming features such as MARS.
• Azure AppFabric blog – this blog is specific to AppFabric features such as access control, service bus, and experimental features, called AppFabric LABS.
• Azure Storage blog – this blog is dedicated to blob and table storage, including code samples and useful tools (such as the recent storage explorer tool compilation).
• Codename Dallas blog – this blog covers the latest information about the new Azure data-provider service.

Aside from blogs, the Azure team is soliciting feedback for future features. You can cast your votes and be heard here:

• Windows Azure feature voting
• SQL Azure feature voting
• SQL Azure Data Sync feature voting
• AppFabric feature voting
• Codename Dallas feature voting

May 12 – Launching and Monitoring your First Azure App

Join me online May 12 at 4pm Eastern, when I present at the Azure User Group, hosted in LiveMeeting. During this talk, we’ll go over the basic building blocks of an Azure application. We’ll then create our first Azure app and see how to deploy it into the cloud. We’ll also see how to monitor an app once it’s deployed.
Please register here if you’d like to attend.
For more information about the Azure User Group, visit the LinkedIn group page or follow AzureUG on twitter.

Silverlight Ramp-up Resources

I completed a several part series of 200 and 300 level blogs that can be used by any experienced developer to quickly spin up Silverlight 4, MVVM, Custom RIA Domain Services and Data Binding.

• Silverlight 4 Hands On Lab - Free MS Hands on lab that you can use to get started.
• Silverlight 4 using MVVM Pattern, RIA Services and Custom Domain Service - Jump right into learning MVVM pattern with Silverlight and RIA Services. In this scenario we could not use Entity so we had to understand how RIA Services work without them.
• Silverlight Custom Authentication Domain Service with RIA Services - Shows a quick way to do custom authentication services and shows how to create a domain service factory.
• Binding ComboBox and AutoComplete Controls in Silverlight DataGrid - Discuss advanced binding concepts and how to bind using column templates in a grid.
• RIA Service Domain Service Method Life-Cycle - Discusses the life-cycle of RIA Service methods.
• Silverlight Localization and Resource Files - Good references on how to utilize resources files in your Silverlight apps.
• Deep Dive into Custom RIA Service and Transactions - A deep dive in building DTOs with RIA Services and how the ChangeSet works to manage transactions.

Windows Phone Developer Tools and Visual Studio 2010 RTM

Just a warning that if you are developing applications using the CTP of Windows Phone Developer Tools, do not upgrade to the RTM of Visual Studio 2010. The two are not compatible. You need to stay on the Release Candidate of Visual Studio 2010 until the Phone Developer Tools are updated. If you want to be notified when that happens, you can sign up to receive an email here.

Silverlight 4 is available!

Today, Microsoft officially released Silverlight 4. As a developer, you’ll want to head over to www.silverlight.net/getstarted – you’ll find links for all needed tools:

• Visual Studio 2010
• Silverlight SDK
• Silverlight Toolkit
• Expression Blend 4 RC

Using an ADO.NET Entity Model Against SQL Server and SqlCE

I ran into a problem recently with Visual Studio generated entity models. We have a partially connected application that uses the same data model as the server, however the client uses Sql Compact and the server uses SQL enterprise. We generated a single EDM diagram in visual studio against the server database. When doing this the storage metadata schema (SSDL) gets generated based on the provider. In order to use your datamodel against a seperate compatible store your consumers need to keep the SSDL in sync for each provider. This proved easy to do wrong an difficult to keep in sync as we would have to keep making local copies after each build that get updated. In order to make life alittle easier I decide to use automation of course. The differences in the SSDL in this case are only the providername and providermanifest:

Server :

<schema namespace="Model.Store" alias="Self" provider="System.Data.SqlClient" providermanifesttoken="2008"></schema>

Client:

<schema namespace="Model.Store" alias="Self" provider="System.Data.SqlServerCe.3.5" providermanifesttoken="3.5"></schema>

Given the minute differences we looked at how to merge a different ssdl along with the same msl and csdl. The simplest solution was to modify the consumer application project file to include a custom MSBUILD task.

The default behavior of the EDMX designer is to embed all three meta data artifacts into the containing assembly. By leaving this as is on the assembly we can post build load the assembly and read the metadata to do translations.

Here is the completed class:

   1: public class RegenerateClientSsdlTask : Task

2: {
3: public RegenerateClientSsdlTask()
4: {
5: }
6:
7: public string AssemblyName { get; set; }
8: public string ProviderName { get; set; }
9: public string ProviderManifestToken { get; set; }
10: public string OutputPath { get; set; }
11: public string SsdlPath { get; set; }
12:
13: public RegenerateClientSsdlTask(ResourceManager taskResources) : base(taskResources)

  14:         {

  15:         }

  16:  

  17:         public RegenerateClientSsdlTask(ResourceManager taskResources, string helpKeywordPrefix) : base(taskResources, helpKeywordPrefix)

  18:         {

  19:         }

  20:  

  21:         public override bool Execute()

  22:         {

  23:  

  24:             var setup = new AppDomainSetup { ApplicationBase = Path.GetDirectoryName(GetType().Assembly.Location) };

  25:  

  26:             AppDomain load = AppDomain.CreateDomain("Analyze", AppDomain.CurrentDomain.Evidence, setup);

  27:  

  28:             try

  29:             {

  30:                 var instance = load.CreateInstance(GetType().Assembly.FullName, typeof (SSDLProcessor).FullName);

  31:  

  32:                 var processor = instance.Unwrap() as SSDLProcessor;

  33:  

  34:                 processor.AssemblyName = AssemblyName;

  35:                 processor.ProviderName = ProviderName;

  36:                 processor.ProviderManifestToken = ProviderManifestToken;

  37:                 processor.OutputPath = OutputPath;

  38:                 processor.SsdlPath = SsdlPath;

  39:  

  40:                 load.DoCallBack(processor.ProcessSSDL);

  41:  

  42:                 return true;

  43:  

  44:             }

  45:             catch (Exception)

  46:             {

  47:                 return false;

  48:             }

  49:             finally

  50:             {

  51:                 AppDomain.Unload(load);

  52:             }

  53:  

  54:         }

  55:  

  56:         private class SSDLProcessor : MarshalByRefObject

  57:         {

  58:             public string AssemblyName { get; set; }

  59:             public string ProviderName { get; set; }

  60:             public string ProviderManifestToken { get; set; }

  61:             public string OutputPath { get; set; }

  62:             public string SsdlPath { get; set; }

  63:  

  64:             public void ProcessSSDL()

  65:             {

  66:                 var assm = Assembly.ReflectionOnlyLoadFrom(AssemblyName);

  67:  

  68:                 var ssdl = assm.GetManifestResourceStream(SsdlPath);

  69:  

  70:                 var ssdlDoc = XDocument.Load(ssdl);

  71:  

  72:                 if (ssdlDoc.Root != null)

  73:                 {

  74:                     XAttribute providerAttribute = ssdlDoc.Root.Attribute("Provider");

  75:  

  76:                     if (providerAttribute != null)

  77:                     {

  78:                         providerAttribute.Value = ProviderName;

  79:                     }

  80:  

  81:                     XAttribute manifestAttribute = ssdlDoc.Root.Attribute("ProviderManifestToken");

  82:  

  83:                     if (manifestAttribute != null)

  84:                     {

  85:                         manifestAttribute.Value = ProviderManifestToken;

  86:                     }

  87:                 }

  88:  

  89:                 ssdlDoc.Save(OutputPath);

  90:             }

  91:  

  92:         }

  93:  

  94:       

  95:     }

Within the previous task several things occur. In the calling build script we configure the task to tell it where to locate the dll, what the path is to the ssdl and what to change the provider configuration to and then lastly where to write out the generated ssdl. You'll notice we load all this into a seperate app domain as well as late load the tasks assembly. If we directly retrieve the metadata into the task the dll will get loaded in the current AppDomain which in our case was part of the visual studio build process. Doing this well work the first time but lock the dll and not allow for subsequent builds to be successful because of file locking.

So now that you have the code how do you use it? The first requirement is to make the assembly located in your visual studio solution so that the project file can reference it. In our solution we have a third party solution folder that contains all these references called Lib. Being centrally located in the solution we can just add relative paths. Once you have a compiled version in your solution you will need to open the end consumers csproj file in notepad. Once you have the file open at the top you will need to add the following directly under the project node:

<usingtask taskname="BuildTasks.RegenerateClientSsdlTask" assemblyfile="..\Lib\BuildTasks.dll"/>

Once you have done that scroll to the bottom and locate the following text:

   1: <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

   2: <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 

   3:       Other similar extension points exist, see Microsoft.Common.targets.

   4:      <Target Name="BeforeBuild">

   5:  

   6:      </Target> 

   7:     <Target Name="AfterBuild">

   8:     </Target>

   9: -->

You will need to uncomment the "AfterBuild" Target and update it to the following:

   1: <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

   2:      <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 

   3: Other similar extension points exist, see Microsoft.Common.targets.

   4:     <Target Name="BeforeBuild">

   5:  

   6:     </Target> -->

   7:     <Target Name="AfterBuild">

   8:     <Message Text="Running SSDL Gen..." />

   9:     <RegenerateClientSsdlTask AssemblyName="$(TargetDir)\EvapSpec.Data.dll" ProviderName="System.Data.SqlServerCe.3.5"     

  10:      ProviderManifestToken="3.5" SsdlPath="ES.ssdl" OutputPath="$(TargetDir)\ES.ssdl" />

  11:     <Message Text="Finished SSDL Gen..." />

  12:    </Target>

Now lets look at the parameters we have configured and how get those.

AssemblyName="$(TargetDir)\Data.dll" This is the reference containing the EDMX model. Since our project references this dll it gets copied into the ouput directory. By using $(TargetDir) we always get the output directory no matter how the project or build configuration changes.

ProviderName="System.Data.SqlServerCe.3.5" This is the provider we use in our connection string on the client

ProviderManifestToken="3.5" This is identifier for the provider.

SsdlPath="Model.ssdl" This is the resource name in the containing dll. The easiest way to get this is to look at the EntityConnection string in your app config. ie: "res://./Model.SSDL" indicates that the resource is at the root of the assembly and called Model.SSDL. Alternatively you can open Reflector and look at the resource tables.

OutputPath="$(TargetDir)\Model.ssdl" This is where we want the generated ssdl file to live. In order to simplify we write the file to where the client assembly lives. This is important as we have to update the connection string on the client to match.

Now to update the consuming application. Once we have the task configured we run a build and should see the SSDL file in the output directory. Lets update the app.config file to utilize it. If you haven't already copy the existing entity connection from your data project. It should look like this:

<add name="ModelEntities" connectionstring="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=System.Data.SqlClient;provider connection string="Data Source=(local);Initial Catalog=Model;Integrated Security=True"" providername="System.Data.EntityClient"/>

We need to update the SSDL path, provider name and connection string:

<add name="ModelEntities" connectionstring="metadata=res://*/Model.csdl|Model.ssdl|res://*/Model.msl;provider=System.Data.SqlServerCe.3.5;provider connection string="Data Source=Model.sdf"" providername="System.Data.EntityClient"/>

Notice I removed res://*/ from in front of Model.ssdl, this tells the loader to use a relative path to the executable on the filesystem versus attempting to read it from the assembly. We still use the same csdl and msl so we can leave those untouched. I also changed the provider name and connection string to use our local database.

In doing all this we now have a common business layer that can leave on the client or the server that is capable of using the same entity model queries.

Azure: Staging and Compute-Hour Metering

In this post, I talked about how web and worker roles are considered live the moment they are deployed, whether stopped or running. I received a few follow-up questions about billing when using the Staging area, as well as clarification on how compute-hours are measured.

 

Production and Staging

When deploying to Azure, you have a choice between Production and Staging:

 

This comes in handy when upgrading your application. Let’s say you have an application already in Production, and you now have a new version you’d like to upgrade to. You can deploy that new version to a separate Staging area, which provides you with a separate “test URL” as well as any worker and web roles your application needs. You can run this app just like you’d run your production app. When you’re done testing, swap staging and production. This is effectively a Virtual IP address swap, so your end-users simply see an upgraded application as soon as you choose to execute the swap.

This is a terrific feature, allowing you to test an application without service disruption. It also allows you to quickly swap back to the previously-deployed version if something go wrong after deploying your new version to production.

Once you’re sure your new version is working ok, consider deleting your service from Staging. Be aware that your staging area is also consuming virtual machine instances. Staging instances and Production instances are equivalent: Each instance is a Virtual machine; Staging instances are billed just like Production instances. If you leave your service deployed to both Production and Staging, you will be accruing Compute-Hour charges for both. Just keep this in mind when estimating your monthly Azure costs.

 

How the hour is metered

As each application is deployed, its virtual machines are created. The moment those virtual machines are in place, metering begins. This includes stopped services. For instance: assuming we clicked Deploy on the Production area of our service, and uploaded an application comprising one worker role and one web role, we’d then see our deployment in a stopped state:



At this moment, the billing clock begins for each of the instances, and billing is based on a 60-minute window: If you deploy at 4:16pm, your 60-minute window is from 4:16pm to 5:16pm (it’s not 4pm-5pm). In this example, I have two roles, with a combined consumption of 2 compute-hours per clock-hour.
If I decide to stop either of these roles before the entire hour is consumed, it’s still metered for the full hour.

 

Multiple Deployments in a Clock-Hour

Let’s say I delete my deployment after only 5 minutes. And then I decide to deploy again to Production. At this moment, the clock starts again for my new deployment. Using our sample app above, with one worker role and one web role:

• Deploy to Production at 4:16pm, delete deployment at 4:21pm. Compute-hours billed: 2
• Deploy again to Production at 4:25pm, delete deployment at 4:30pm. Compute-hours billed: 2
• Total clock time: 14 minutes. Total compute-hours: 4

I realize this is a contrived example, but I want to emphasize the fine details of compute-hours:

• Each instance is metered from the moment it comes to life in a Virtual Machine.
• Compute-hours are rounded up to the nearest hour. So a service is metered at 1 compute-hour, whether it runs for only 5 minutes or 59 minutes.
• Services deployed within the same clock-hour are completely unrelated, billing-wise. If you stop and delete your application and then deploy it again, all within the same clock-hour, you will still be billed separately for each deployment.

Azure: New Guest OS 1.2

On April 5, Azure Guest OS 1.2 became available. If you’ve published any new Azure services in the past day or two, your new deployments are probably using v1.2. In the Azure Portal, take a peek at the service configuration:

So: what does v1.2 have?

• HTTP dynamic compression for webroles
• Updates to the IIS URL Rewrite module
• .NET 4 RC
• Security patches

Ooh - .NET 4 RC??? Does that mean we can now deploy .NET 4 RC builds to Azure??? Well… Not yet. The Azure 1.1 SDK only supports .NET 3.5 build output. If you try changing your role’s target framework to .NET 4, you’ll get an error:

The .NET 4 RC framework is installed for compatibility testing. According to this MSDN article about Guest OS 1.2, there’s a known issue with unversioned performance counters.

This is a good sign though! April 12 is the Release-to-manufacturing (RTM) date for .NET 4. At MIX earlier this year, the Azure team announced that we’d see .NET 4 support within 90 days of RTM. Hopefully, having this new guest OS will help accelerate testing and bring that date closer to April 12. That also means you should send the Azure team any feedback you have regarding issues with the new Guest OS.