Skip Ribbon Commands
Skip to main content

Quick Launch

Home
Jon Galloway
January 22
Microsoft's Evolving Virtualization Strategy

No, not that Calista

Microsoft announced today that they bought Calista. Not Calista Flockhart, the frighteningly thin actress – Calista Technologies. The press releases have some vague info about Calista’s technology doing something to “make virtualization run better”. There’s more info on the Calista website:

The Calista Virtual Desktop (CVD) platform directly addresses the two major barriers to widespread virtual desktop adoption: the quality of the user experience and the cost per desktop. CVD provides a traditional desktop quality experience, including rich media and 3D graphics, to virtual desktops. CVD also dramatically increases the number of users per virtual desktop server resulting in decreased costs and form factors; thus, CVD is well suited to multi-core CPU and virtualized server trends and today’s densely populated datacenters.

And Citrix, Too…

Along with that announcement, they announcing a closer partnership with Citrix. The Citrix thing is interesting for two reasons:

1. Microsoft’s Terminal Server / Remote Desktop product is based on the WinFrame technology they licensed from Citrix back in 1997.

2. Citrix recently bought XenSource, the leading open source virtualization platform. That puts some real pressure on VMWare, since the Xen platform has some traction in the Linux / open source server market.

Hyper-V is a bit late to the party

One thing still remaining in Microsoft’s virtualization strategy is a hypervisor, which moves the hardware emulation to run more completely beneath the operating system:

Microsoft offers some virtualization components already. But it doesn't yet offer a key layer of software, called a "hypervisor," that emulates the physical features of a computer and runs beneath an operating system. Hyper-V is expected to add that capability.(WSJ article cited above)

Microsoft’s Hyper-V hypervisor was supposed to ship with Windows Server 2008, but it’s been delayed to the 3rd quarter:

The company plans to offer a virtualization component with its coming Windows Server 2008 operating system, which is scheduled to be delivered this quarter. But the feature, known as Hyper-V, won't be ready for six months, or sometime in the third quarter, said Larry Orecklin, general manager of Microsoft's server-infrastructure business. (WSJ article cited above)

Microsoft’s Virtualization Strategy: The Historical Perspective

Microsoft’s had a history of buying a lot of Virtualization technologies recently:

· They bought Softricity back in 2006. Softricity’s technologies included an application streaming technology (for delivering applications on demand) as well as an application virtualization technology that runs apps in a sandbox. I’ve been hoping they’d do more with application virtualization, but everything I’ve seen so far indicates that they’re abandoning that technology except for its use in application streaming.

· Microsoft acquired Virtual PC from Connectix back in 2003.

Our Virtual Future

Jeff and I have had a running debate on the future of virtualization technologies. While I think it’d be foolish to say that VM’s aren’t growing in importance, I’m looking forward to something that provides a better integration than the “install everything in segregated VM’s” way of doing things. While the hardware and software increasing the performance of virtualized solutions, the end result isn’t significantly better. Instead having all my applications living in a separate but connected environment (like cities in the same country, sharing a common infrastructure), VM-land is more of a nuclear option approach which banishes and segregates all our applications and data to separate planets. To my way of thinking above technologies don’t fundamentally change any of that – each virtual machine may run faster, but I can’t do something as simple as search for a text document across multiple virtual machines.

So, in the end, it’s obvious that headed towards a virtualized future. I just hope that it’s better than the present.

September 17
Program Silverlight 1.0 in C# with Script#

A big part of the excitement around Silverlight 1.1 is the client-side .NET runtime, which lets you write client side code in C#. Silverlight 1.0’s programmability story is Javascript only. However, there’s a way to write your Silverlight 1.0 code in C#, using the Script# Compiler.

Nikhil Kothari (the author of Script#) has a great post on writing a Photo Carousel in Silverlight 1.0 with Script#. I’ll run over the background and usage of Script#, but my main goal is to convince you to go read more on Nikhil’s blog and the Script# project page. Nikhil is an architect on the Web Platform and Tools team at Microsoft, responsible for the Webforms features area. He’s been with ASP.NET since it was called XSP, so I think we can trust him. Oh, hey, my reader boredom sensors just went off! Time for a screenshot of the carousel control Nikhil created with Script# and Silverlight:

The magic of Script#

Script# compiles C# code to Javascript, so you can write your entire application in C#. Javascript is a great language (better than C# in some respects), but by writing in C# you can take advantage of some things that just aren’t available in Javascript, such as:

  • Visual Studio’s support for C# refactoring 
  • Contextual output from a common code base – for instance, a debug build includes method names for what would otherwise be anonymous methods to aid in debugging, while a release build can output minimized code which removes whitespace and uses short identifier names. 
  • Smooth integration with ASP.NET AJAX 
  • IntelliSense and compile time checking 
  • Library support for the kinds of things you’ll want to be doing in ASP.NET Javascript like Cross Domain AJAX with JSONP, Silverlight, UI Controls and Behaviors, RSS, and managed HTTP Request / Response handling 
  • Did I mention you can write an entire Silverlight 1.0 application in C#?

Installing Script# gives you a Script# project type, which includes both the binaries and the compilation magic:

If you’re writing Silverlight Javascript code, you’ll want to set a reference to ssagctrl.dll (as in Script Sharp Ag Control – Ag being the chemical symbol for Silver), which includes the metadata for the Silverlight Javascript interfaces. That will give you access to classes like System.Silverlight.Presentation, complete with IntelliSense for all supported objects.

The simplest way to use Script# is by adding a Scriptlet control to your page:

ScriptSharp Scriptlet control

 

Clicking the “Edit C# Code…” Scriptlet Task brings up an editor window:

ScriptSharp-Editor

When your project is compiled, the Scriptlet code is automatically compiled to Javascript and included in your page.

You can also create a Script# class library by adding a Script# class file to your project (which includes the correct build settings), the write standard C# class code:

public sealed class PhotoControl : IDisposable {
    private Canvas _containerCanvas;
    private Canvas _frameCanvas;
    private Image _image;

    public PhotoControl(Canvas rootCanvas) {
        // Find the interesting XAML elements we want to program against
        _containerCanvas = (Canvas)rootCanvas.FindName("photo");
        _frameCanvas = (Canvas)_containerCanvas.FindName("photoFrame");
        _image = (Image)_containerCanvas.FindName("photoImage");

        // Center the photo within the silverlight control
        SilverlightControl control = rootCanvas.GetHost();
        Canvas.SetLeft(_containerCanvas, (control.Content.ActualWidth - _containerCanvas.Width) / 2);
        Canvas.SetTop(_containerCanvas, (control.Content.ActualHeight - _containerCanvas.Height) / 2);
    }
 
    public string PhotoUri {
        get { return _image.Source; }
        set { _image.Source = value; }
    }
 
    public void Dispose() {
        if (_containerCanvas != null) {
            _image = null;
            _frameCanvas = null;
            _containerCanvas = null;
        }
    }
}

When you build, your code is automatically converted to Javascript and placed in your App_Scripts folder.

How does it all work?

Script# includes its own compiler, ssc.exe. You can call it directly, but the preferred approach is to use the Script# MSBuild .targets file (which is included automatically when you use the Script# project templates). Since your code is C#, it’s compiled in both the C# compiler (csc.exe), mostly to check for compilation errors, but also to generate a DLL which can be used in debugging, via reflection, etc. It’s also compiled by the Script# compiler (ssc.exe), which outputs Javascript in the appropriate format.

ScriptSharp Compiler