DCSIMG
November 2010 - Posts - Manu Cohen-Yashar's Blog

Manu Cohen-Yashar's Blog

November 2010 - Posts

The Future of Silverlight

In PDC 2010 there where many talks about Silverlight vs. HTML 5.  more info.

 

In PDC there were plenty of mentions of HTML 5 and Microsoft’s commitment to that technology yet Silverlight was considered to be the leading technology concerning the mobile market.

 

Bob Muglia, the Microsoft President in charge of the company’s server and tools said that Silverlight will continue to be a cross-platform solution, working on a variety of operating system/browser platforms, going forward, he said. “But HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform”.

 

Many developers understood that Microsoft is actually killing SilverLight or at least shifting the focus from It. This caused panic and lots rumors where spread around.

 

In TechEd Eilat 2010 we had a chat with Jason Zander  who is responsible for Visual Studio.

 

He said that fact that Microsoft is investing in HTML 5 does not mean that Silverlight is being abandoned.

 

The world of web application is divided into two main domains:

 

·         Scripting languages (i.e. HTML, Java Script etc.)

 

·         Complied code (i.e. Silverlight or flash)

 

Microsoft wants to supports both domains. Each domain Zander said has a large developer community and Microsoft does not want to lose any of those crowds.

 

We all know that flash lived side by side with Html and JS so there is no reason why Silverlight will not succeed side by side with HTML 5.

 

Silverlight developers do not worry. Silverlight is here to stay

 

Manu

Using http proxy with local sites

If you run a typical ASP.NET application with the cassini server (VS 2010 debugging server), you'll notice that Fiddler or any other http proxy is not capturing any traffic. 

To remedy this situation, you can simply add a period ('.') to the end of "localhost" in the address bar (http://localhost.:1234/mysite).

This will allow you to view your application’s traffic data with Fiddler.

Things happen in Windows Azure

PDC is behind us. Now it is possible to say that the high expectations were met.

According to the announcements given at PDC Windows Azure is doing one major step forward. If you were developing in Azure you noticed that many issues were kept open.

The IT Pros and the developer communities asked many questions that could not be answered.

Now things change. Windows Azure will provide in the next few months a wide range of features that will solve most of the issues that were not supported and prevented application migration to the cloud.

The full list of new features can be found at: PDC announcements

In this post I would like to discuss the3 features that I find most important.

VM Role: Up till now there where 2 types of roles: Web and worker roles. The new VM role allows taking an existing Windows Server 2008 image (which contains your application) and uploading it to the cloud. This means real zero migration effort and full control experience.

Azure Connect: Now it possible to connect your on premise network to your cloud servers on an IP level. This means that you can keep your data in your own database but upload the application server to the cloud. With Azure connect it is possible to domain join your Azure application with your on premise AD. Last but not least it is possible to do remote desktop to the Azure VM which enables monitoring activities and troubleshooting common problems.

All these were obstacles that prevented migration to the cloud.

Elevated Privileges and Full IIS management: With Elevated Privileges you get greater flexibility and control in developing, deploying and running your cloud applications. For example: Write to the VM registry.
Web role will provide Full IIS functionality, which enables multiple IIS sites per Web role and the ability to install IIS modules.

Thing are happening…

Manu

Come to my talk in TechEd

In the coming TechEd I will be giving a talk about Azure Storage.

The talk will be given in the Cloud Track and it will take place on the third day at 4pm. (The last talk in TechEd)

In this talk I will cover the Azure Storage Technologies and will explore patterns and best practices.

In the talk you I will describe the logics behind the storage architecture. Such understanding will help you to use it correctly and enjoy its power.

So come to my talk in the TechEd.

Tables in a sync scope must be ordered

Before doing synchronization using the Microsoft Sync Framework 2.0 it is required to provision a sync scope. In the scope you define which tables and columns are synchronized and specify any filters if required.

Detailed instruction can be found at the following resources:

Provisioning for Synchronization (SQL Server),

Walkthrough: Defining Filtered Scope and Provisioning Server Database,

Walkthrough: Defining Scope and Provisioning a Server Database

Yet one important detail is missing in all these references: The order of the tables in a scope.

 

When creating a scope for synchronizing multiple tables with parent child relationship the child must be declared first.

var scopeDesc = new DbSyncScopeDescription(scopeName);

scopeDesc.Tables.Add(
SqlSyncDescriptionBuilder.GetDescriptionForTable(chiledTable, serverConn));

scopeDesc.Tables.Add(
SqlSyncDescriptionBuilder.GetDescriptionForTable(parentTable, serverConn));

 

If you fail to do so the sync process will crash with OutOfMemory Exception.

It is not documented but multi table scopes assume that the tables are ordered according to the database constrains. If this assumption breaks loading the scope in the GetKnowledge method (In the beginning of the sync process) creates a huge memory block and the process fails.

 

I spent quite some time with this bug.

 

Manu

Custom Workflow Activity - Property or Argument

In WF 3.5 custom activity input was written to properties. The developer who would use these activities would set values to properties directly in the designer or using binding.

In WF 4.0 it is possible continue to use regular CLR properties or to use Input Arguments exposed as properties.

The question is when to do what.

Well…

1.       When the input value is needed before the activity is executed, for example in the CacheMetadata method - CLR properties are your only option. Input Arguments are visible only with a context object provided in the Execute method. I had a project where I wanted to create arguments on the fly using information supplied by the WF developer. This could only be achieved using CLR properties as dynamic arguments are created in  CacheMetadata.

2.       If the value needs to be persisted it must be contained in an Argument because the activity's CLR properties are NOT persisted. (It is always possible to use a persistence participant to solve this problem)

3.       CLR properties cannot be set in the designer property pane with an expression. Only simple kind of types can be set (for example: System.Type)

I hope these considerations will help …

Manu