Random Rants & Raves

With the BUILD conference just completed where Microsoft showed off a huge number of new features in it’s upcoming Windows 8 OS, the major questions revolving around the developer story was about the relationships between the different components to create apps for it. “Is .NET/SilverLight dead?”, “Do we create only HTML5/CSS/JS apps now” etc. were the ones that everyone had. However, while the conference cleared up a lot of things, it still kept the discussions going.

Here’s my take on the Windows 8 Developer Stack. This was created after a lot of discussion with very knowledgeable and bright people – my fellow RDs. Any omissions or errors are mine.

Let’s dissect this image for a better understanding.

First and foremost, there are now going to be two “types” of apps – the traditional Desktop apps – everything that you’ve seen and worked with in Windows till now, and the new “Metro” apps. The Metro apps run on the new touch screen paradigm and use a whole new stack for development.

The traditional stack remains more or less the same – you can create native Windows (forms) apps with C++ and Win32. Or you can use .NET (now in a new 4.5 flavor) with WinForms or XAML as front-end and C#/VB/C++ as the language. For better compatibility with future versions of Windows, it seems sticking to the XAML path would be more beneficial.

The new “Metro style” apps is where all the enhanced stuff sits. You can create Metro apps using a combination of HTML5/CSS + JavaScript OR XAML + C#/VB/C++. Note that the XAML used for Metro (which I term as M-XAML above), while syntactically identical to the Desktop XAML, has other enhancements and changes tailored for Metro specifically.

The other main change is that the C#/VB/C++ code runs not on ".NET per se, but again a syntactically identical, but Metro enhanced runtime called WinRT. This is a new base API that does not replace Win32 API completely (as yet) but provides services (in the form of services and APIs) that can be used by Metro style apps. WinRT can still call and use subsets of .NET and Win32 as and when needed. I assume that in the future .NET will embed completely into WinRT and Win32 will be replaced by this new stack.

What does this mean for developers? Well, if you are on .NET today, you can simply start learning the new WinRT using the M-XAML/C#/VB route and start creating Metro apps. If you are a HTML/CSS/JS developer, ramp up on HTML5/CSS3 and the JavaScript extensions and frameworks available as well as the WinRT code. If you want to build an application that would run both on Windows 7 and Windows 8 you can create it with XAML and then for Windows 8 also provide a M-XAML frontend. We will of course need to see how all of this comes together as we start getting more information out of Microsoft.

Windows 8 looks really nice and brings in a new way of interacting with your apps and devices Make sure you get on board right now.

Microsoft recently released the Exchange Web Services Managed API SDK 1.0. This mouthful which I’ll just call EWSMAS is useful for writing custom applications that work with Exchange Server (2007 SP1 or 2010). In one of the projects we are currently working on, we need to send emails over Exchange with both normal attachments as well as inline in the mail body.

Now here’s the good thing – if you’re already on Exchange 2010, there is a simple property called IsInline that will allow you to specify the attachment as inline. However, if you’re on Exchange 2007 SP1 still (like in the case of Exchange Online/BPOS), you’re stuck as the property returns an exception stating it’s only for Exchange 2010. Here’s how to solve this problem. Note that I’ve created a simple console app to demonstrate this method only. I assume you know how to download the SDK and add reference to it in VS2008/2010.

   1:  ExchangeService service = 

   2:       new ExchangeService(ExchangeVersion.Exchange2007_SP1);

   3:   

   4:  // Use when machine is IN Domain

   5:  //service.UseDefaultCredentials = true;

   6:  //service.AutodiscoverUrl("user@domain.com");

   7:   

   8:  // Use when machine is NOT in Domain

   9:  service.Credentials = new WebCredentials("user@domain.com", "password");

  10:  service.Url = new Uri("https://Your-CAS-Server/EWS/Exchange.asmx");

  11:   

  12:  // Create an e-mail message and identify the Exchange service.

  13:  EmailMessage message = new EmailMessage(service);

  14:   

  15:  // Add properties to the e-mail message.

  16:  message.Subject = "Testing from .NET Client";

  17:   

  18:  // Add the image as inline attachment

  19:  FileAttachment attachment = 

  20:       message.Attachments.AddFileAttachment("C:\\temp\\attach.png");

  21:  attachment.ContentId = "01"; // this should be unique - say a GUID

  22:   

  23:  // Add the message body which refers to this contentID

  24:  message.Body = "Sent from a .NET with inline image <img src='cid:01'>";

  25:  message.Body.BodyType = BodyType.HTML;

  26:   

  27:  // Add recipeint

  28:  message.ToRecipients.Add("anotheruser@domain.com");

  29:   

  30:  // Send the e-mail message and save a copy.

  31:  message.SendAndSaveCopy();

Notes:

1. Lines 5-6 should be used when the machine sending the mail is in the same AD domain as the Exchange server (say, an in-house Exchange server)
2. Lines 9-10 should be used when the machine sending the mail is in a different AD domain from the Exchange server (say, hosted Exchange or BPOS)
3. Line 21 is the one that sets a ContentId property for the image attachment – this will now NOT show the image as an attachment anymore. In case you need to simply add it again – this time without the ContentId.
4. Line 24 uses this ContentId with the cid: property in a standard HTML image tag. This is what makes the image show up inline in the right place.

 
This is what the inline image looks like once it is sent and received.

Microsoft's development team has been quite busy lately. Last week we saw the release of SQL Server 2008 and this week we have the Visual Studio 2008 Service Pack 1 and .NET Framework 3.5 Service Pack 1 released as well. There are a whole bunch of things in this release:

• Bunch of bug fixes
• ASP.NET Dynamic Data
• ASP.NET MVC
• SQL Server 2008 RTM support
• Entity Framework
• IIS 7.0 managed module templates
• Tons of more stuff...

You can read about the new features of VS2008SP1 and .NET 3.5 SP1 for more details. You might also want to install and run the Visual Studio 2008 Service Pack Preparation Tool to ensure that any old SP betas and hotfixes are removed correctly before attempting to install the RTM version of the service pack.