Jason Zander's WebLog : Silverlight

Popfly Game Engine Source Code Released

Jasonz — Thu, 27 Aug 2009 05:42:28 GMT

Ben Anderson just released the source code for the Popfly Game Engine on codeplex. You can read Ben’s full post here and download the source code here. The project is a C# Silverlight application that demonstrates several concepts of XAML and .NET for RIA.

Tulsa Techfest 2007 Keynote Slides

Jasonz — Sat, 20 Oct 2007 00:46:00 GMT

This morning I gave the opening keynote for the Tulsa TECHFEST 2007 event. There is great attendance at the event and 16 tracks! As promised, I have made the slides available online for you to download:

Slides are here
I've blogged information on getting started with Silverlight here

At the event about 40% of the group had already downloaded Visual Studio Beta 2.

I also gave a demo of the latest version of Popfly, now in open beta (way to go team!).

If you are attending TECHFEST I look forward to meeting you (Oktoberfest this evening?). Don't be shy!

Getting Started With Silverlight

Jasonz — Fri, 21 Sep 2007 08:06:00 GMT

I've had a number of queries on how to get started with Silverlight after my talk in NYC on Monday. The best place to get going is the www.silverlight.net site. There is a wealth of information up there including partner show cases, downloads for the software (runtime and tools), samples, etc.

If you want to play with the show cases, start on the main site and click the "See More..." link:

This will give you the full show case:

You can select any item (like the Fantastic Four or Halo HD vidoes) then click the "See It" button to activet he content.

The next place to go is the "GET STARTED" link on the top of the page which gives you step by step instructions for downloading all of the software I showed (runtime, VS add-on, preview Expression, etc):

Finally there are a ton of code samples you can download under the "LEARN" and "COMMUNITY" links at the top of the page. You can build up a lot of experience with just these steps. We also have a great deal of material out there in blogs.

Enjoy!

Slides from VSLive New York Keynote

Jasonz — Mon, 17 Sep 2007 18:57:00 GMT

This morning I presented the keynote on Silverlight at VSLive in New York. As promised, here are some links related to the talk:

Slides for the talk are here
You can find everything you need to get started on Silverlight at www.silverlight.net, including bits, demos, sample code, etc
You'll find a lot of additional supporting material on our various blogs. If you aren't already a subscriber, I highly recommend ScottGu's blog

For those attending the conference, I will be around all day Monday and Tuesday. I'm happy to answer any questions you have, so don't be a stranger!

Jason

Final .NET Show with Scott Guthrie and Jason Zander

Jasonz — Tue, 21 Aug 2007 23:23:00 GMT

Scott and I had the opportunity to do the final .NET show on Silverlight. The show is live now:

I want to thank Robert for having us on his final show!

Visiting Microsoft India Campus

Jasonz — Fri, 10 Aug 2007 11:07:00 GMT

I've spent this week visiting the Microsoft Campus in Hyderabad, India. On Wednesday I had a chance to give a talk about the upcomming VS 2008 release and do an overview of Silverlight. The VS2008 overview can be found here. ScottGu did a great job pulling together a lot of our Mix material in one deck here.

Everything you need to get started with Silverlight is here. Enjoy!

Code Sample: Is Your Process Using the Silverlight CLR?

Anonymous — Sat, 12 May 2007 01:23:00 GMT

In my previous post I described how multiple CLRs can now be run in the same process starting with Silverlight. In the sample video I had a small console application that could be used to track managed processes on the machine and which version(s) of the CLR they had in them. I’ve included the code for this tool below.

The CLR debugger APIs implement ICorPublishProcess to find managed processes, but these APIs have not been updated for Silverlight and are likely to be deprecated in the future. Instead, in my first version I used System.Diagnostics.Process. I found these wrappers to be extremely slow due to grabbing all file version information from all modules loaded. I’m sure this is pretty useful for a one time snapshot, but my tool needed to refresh itself very frequently. Because of this I wound up using p/invoke on top of kernel32!CreateToolhelp32Snapshot (first part of the code).

The rest of the code is pretty simple: every 3 seconds take a process list snapshot and search for CLR instances by name, add them into the process list, then display them to the console. The code recognizes the CLR as follows:

· mscorwks.dll is the name of the CLR engine for version 1.0, 1.1 and 2.0 (3.0 and 3.5 build on top of 2.0)

· coreclr.dll is the name of the Silverlight CLR engine

I didn't spend a huge amount of time on this code and would put more structure in it if I ever put it in production (I'd also replace the dipslay code with a decent GUI). It’s nothing fancy, but it got the job done. Enjoy!

using System;

using System.Collections.Generic;

using System.Text;

using System.Runtime.InteropServices;

using Microsoft.Win32.SafeHandles;

using System.Runtime.ConstrainedExecution;

namespace EnumClrConsole

{

// The safe handle class is used to safely encapsulate win32 handles below

public class ToolHelpHandle : SafeHandleZeroOrMinusOneIsInvalid

{

private ToolHelpHandle()

: base(true)

{

}

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]

override protected bool ReleaseHandle()

{

return NativeMethods.CloseHandle(handle);

}

// The following p/invoke wrappers are used to get the list of process and modules

// running inside each process.

public class NativeMethods

{

[DllImport("kernel32.dll", SetLastError = true)]

static public extern bool CloseHandle(IntPtr hHandle);

[DllImport("kernel32.dll")]

static public extern bool Module32First(ToolHelpHandle hSnapshot, ref MODULEENTRY32 lpme);

[DllImport("kernel32.dll")]

static public extern bool Module32Next(ToolHelpHandle hSnapshot, ref MODULEENTRY32 lpme);

[DllImport("kernel32.dll")]

static public extern bool Process32First(ToolHelpHandle hSnapshot, ref PROCESSENTRY32 lppe);

[DllImport("kernel32.dll")]

static public extern bool Process32Next(ToolHelpHandle hSnapshot, ref PROCESSENTRY32 lppe);

[DllImport("kernel32.dll", SetLastError = true)]

static public extern ToolHelpHandle CreateToolhelp32Snapshot(SnapshotFlags dwFlags, uint th32ProcessID);

public const short INVALID_HANDLE_VALUE = -1;

[Flags]

public enum SnapshotFlags : uint

{

HeapList = 0x00000001,

Process = 0x00000002,

Thread = 0x00000004,

Module = 0x00000008,

Module32 = 0x00000010,

Inherit = 0x80000000,

All = 0x0000001F

}

[StructLayoutAttribute(LayoutKind.Sequential)]

public struct PROCESSENTRY32

{

public uint dwSize;

public uint cntUsage;

public uint th32ProcessID;

public IntPtr th32DefaultHeapID;

public uint th32ModuleID;

public uint cntThreads;

public uint th32ParentProcessID;

public int pcPriClassBase;

public uint dwFlags;

[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]

public string szExeFile;

};

[StructLayoutAttribute(LayoutKind.Sequential)]

public struct MODULEENTRY32

{

public uint dwSize;

public uint th32ModuleID;

public uint th32ProcessID;

public uint GlblcntUsage;

public uint ProccntUsage;

IntPtr modBaseAddr;

public uint modBaseSize;

IntPtr hModule;

[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]

public string szModule;

[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]

public string szExePath;

};

}

// The ProcessList is used to track all running processes that have managed code

// running in them. Each RootProcess item in turn tracks all CLR instances running

// inside the process, which as of Silverlight could be more than one.

class Program

{

public Dictionary<string, RootProcess> ProcessList;

public Program()

{

ProcessList = new Dictionary<string, RootProcess>();

}

// Build will find all running processes and search them for an instance of

// the CLR engine. mscorwks.dll is the enging for CLR V1.0 -> 2.0 (which includes V3.0 and 3.5).

// coreclr.dll is the new Silverlight CLR engine.

public void Build()

{

// Reset the old list of running processes and then get a list of everything running.

ProcessList.Clear();

ToolHelpHandle hProcessSnap;

NativeMethods.PROCESSENTRY32 pe32 = new NativeMethods.PROCESSENTRY32();

hProcessSnap = NativeMethods.CreateToolhelp32Snapshot(NativeMethods.SnapshotFlags.Process, 0);

if (hProcessSnap.IsInvalid)

{

Console.WriteLine("Failed on call to CreateToolhelp32Snapshot");

return;

}

pe32.dwSize = (uint)System.Runtime.InteropServices.Marshal.SizeOf(pe32);

if (NativeMethods.Process32First(hProcessSnap, ref pe32))

{

// For each running process, get the list of modules. If it has CLR running

// inside, add it to the running list.

List<ClrInstance> list = new List<ClrInstance>();

if (GetClrList(ref list, pe32.th32ProcessID))

{

string key = String.Format("{0}:{1}", pe32.szExeFile, pe32.th32ProcessID.ToString());

// If this process is already in the list, use that instance.

RootProcess p;

if (ProcessList.ContainsKey(key))

p = ProcessList[key];

// Otherwise create a new entry.

else

{

p = new RootProcess(pe32.th32ProcessID.ToString(), pe32.szExeFile);

this.ProcessList.Add(key, p);

}

foreach (ClrInstance c in list)

{

p.AddClr(c);

}

} while (NativeMethods.Process32Next(hProcessSnap, ref pe32));

}

hProcessSnap.Close();

}

// Counter data for display.

int iCounter = 0;

int iLastLineCount = 0;

int iLineCount;

private void WriteLine(string str, params Object[] o)

{

++iLineCount;

Console.WriteLine(str, o);

}

// The display method dumps the process tree to the screen in a pretty

// dumb way. This routine could easily be replaced with a GUI.

private void DisplayProcessList()

{

iLineCount = 0;

Console.CursorLeft = 0;

Console.CursorTop = 0;

WriteLine("{0}", ++iCounter);

foreach (KeyValuePair<string, RootProcess> rp in ProcessList)

{

String ProcPid = String.Format("{0} - {1}", rp.Value.ProcName, rp.Value.pid);

WriteLine("{0,-79}", ProcPid);

foreach (ClrInstance c in rp.Value.rgClr)

{

WriteLine(" {0,-75}", c.ClrName);

}

for (int i = iLastLineCount - iLineCount; i > 0; --i)

{

Console.WriteLine("{0,-79}", " ");

}

iLastLineCount = iLineCount;

}

// Returns true if this is a managed process.

bool GetClrList(ref List<ClrInstance> list, uint pid)

{

bool IsManaged = false;

ToolHelpHandle hModuleSnap;

NativeMethods.MODULEENTRY32 me32 = new NativeMethods.MODULEENTRY32();

hModuleSnap = NativeMethods.CreateToolhelp32Snapshot(NativeMethods.SnapshotFlags.Module, pid);

if (hModuleSnap.IsInvalid)

return (IsManaged);

me32.dwSize = (uint)System.Runtime.InteropServices.Marshal.SizeOf(me32);

if (NativeMethods.Module32First(hModuleSnap, ref me32))

{

// mscorwks.dll == a CLR of version V1.0, V1.1, V2.0

// coreclr.dll == Silverlight

if (String.Compare(me32.szModule, "mscorwks.dll", true) == 0 ||

String.Compare(me32.szModule, "coreclr.dll", true) == 0)

{

ClrInstance c = new ClrInstance(me32.szExePath);

list.Add(c);

IsManaged = true;

}

} while (NativeMethods.Module32Next(hModuleSnap, ref me32));

}

hModuleSnap.Close();

return (IsManaged);

}

static void Main(string[] args)

{

Program p = new Program();

while (true)

{

p.Build();

p.DisplayProcessList();

System.Threading.Thread.Sleep(3000);

}

public class RootProcess

{

public string pid;

public string ProcName;

public List<ClrInstance> rgClr;

public RootProcess(string inpid, string inproc)

{

pid = inpid;

ProcName = inproc;

rgClr = new List<ClrInstance>();

}

public void AddClr(ClrInstance clr)

{

rgClr.Add(clr);

}

public class ClrInstance

{

public string ClrName;

public ClrInstance(string strClr)

{

ClrName = strClr;

}

Side by Side In Process CLRs Start with Silverlight

Anonymous — Thu, 10 May 2007 22:31:00 GMT

When we started working on managed code for Silverlight one scenario I wanted to see working was the ability to create a new browser or shell in managed code that could still browse to and execute rich web content. We spent (endless) time debating if this scenario should simply target the desktop CLR if it were installed and just use one CLR. In the end my main concern about that solution was ensuring 100% behavior compatibility. We strive really hard to reach this on the desktop already, and at some point just being able to execute what you wrote against is the best solution. So instead we went down the road of creating a separately factored CLR which could run side by side in the same process. To test this, I wrote a small managed application which hosted shdocvw.dll (IE’s core browser engine) and browsed to a Silverlight enabled web site. The first few times this was not a pretty experience <g>, but that was quickly fixed.

Enabling side by side CLRs in the same process not only enables this scenario, but it removes a long standing complaint from developers trying to write applications that implement add-in models for extensibility. In these cases, you often want to load and bind to the version of the CLR your add-in was built for. Previously one had to roll forward to the latest and greatest version to pull this off. It does work, but can be a little painful.

This video gives a demonstration of running two CLRs in the same process using a WPF demo I blogged about here:

There are a few things to notice in this diagram:

· There is no retroactive change to Versions 1.0, 1.1, or 2.0 of the CLR. Only one of these may be in the process at the same time. The diagram shows V2.0 (3.0 and “3.5” are built on top if used).

· Silverlight can run side by side with any one of the V1.0, V1.1, or V2.0 CLRs.

· Future versions of the CLR (which are under development already) will run side by side with the original desktop CLR instances and Silverlight.

Now that we have this feature, you may ask why it wasn’t there from the beginning. There were always two main considerations we had historically for not going down this road. The first is thread suspension. You need to ensure that if two CLRs are suspending threads to do a GC they don’t suspend each other in the process (there are some XML dlls out there today which do a poor job of this). The second consideration is the performance of the resulting process. Each CLR has its own GC heap and loaded code; they do not share data with each other (any interop between them must be done through unmanaged code / COM).

Given all of this, it is still our recommendation that if you are designing a new extensibility API for your application, try to make it work well with the add-in running out-of-process. This really does provide the cleanest way to isolate 3^rd party code and keep the best possible compatibility. However if you are using an existing API extensibility model (sidebar, browser, etc) that was not designed for this, this new feature does simplify your life a lot.

Silverlight Podcast on HanselMinutes

Anonymous — Fri, 04 May 2007 05:05:00 GMT

ScottGu and I did a podcast with Scott Hanselman at Mix on Silverlight. You can get the podcast from Scott's blog here. Scott also posted an update version of his .NET Framework diagram here. In the podcast we cover the origin of the Silverlight CLR, some differences between Silverlight and WPF on the desktop, etc.

Thanks Scott for having us on HanselMinutes!

Origin of the Silverlight CLR and .NET Framework

Anonymous — Wed, 02 May 2007 02:01:00 GMT

One of the common questions I’ve been asked at Mix is exactly where did the CLR / .NET Framework in Silverlight come from? We actually started building this version of the CLR right after we shipped V2.0 in October 2005. The approach was simple: figure out the minimal required core that would allow a set of very common developer scenarios to be fulfilled. Size was of utmost importance and all feature contributions would have to be justified in the context of the scenarios and how much they cost us on the download. The other requirements included ensuring first rate performance and the highest compatibility bar we could get with the desktop CLR.

With this set of goals in mind, we started from the bottom up (quite literally). To keep up performance and compatibility, we kept the same core type system, garbage collector, JIT compiler, etc. This engine also includes all of the generics work added to the V2.0 release. The same approach was then applied to the .NET Framework libraries. Again the goal was simple: what is the minimal library support you need to build a compelling application. With this you wind up including XmlReader/XmlWriter, but not the richer object layers on top. Those are great features (and still readily available for you in the desktop .NET Framework). But we needed a small package. There were tons of debates and lot’s of tweaking over the last 16 months.

In order to get this done in a short time frame with high compatibility, we decided to start with the desktop CLR/NETFX. We did the factoring in that code base. In most cases, the Frameworks code is quite literally the same code from the desktop version. In other cases we kept the API signatures the same, but plumbed out the implementation on top of the browser support.

The result is a pretty small stack that still gives you superior performance and access to all your core features. We are using the same metadata / IL file format, same language semantics, etc. The real test came when we tried to run LINQ on top of the new stack and it just worked! That’s right, we took the ‘Orcas’ LINQ assembly and copied it over to run on this stack and started executing sample code. The cool thing about this is you can take a Silverlight application and your source code will be compatible with the desktop version of the .NET Framework. It is very easy at that point to extend the application to use more features of the desktop if you like. The key thing here is developer choice.

Scott Hanselman has an interesting picture on his blog of the various versions of the CLR/.NET Framework which is pretty accurate. ScottGu and I did a podcast for Hanselminutes this afternoon which covers a lot of this ground in more detail. I will post a link to that podcast when Scott publishes it.

Announcing .NET Framework Support for Silverlight!

Anonymous — Mon, 30 Apr 2007 21:17:00 GMT

This morning at Mix’07 in Las Vegas we announced something we have been working on since we shipped V2.0 of the .NET Framework in 2005: .NET support for Silverlight. I want to congratulate the team for all the hard work that has gone into getting to this point! It’s been a blast getting everything going, and over the last four months things have really started to come online. I think you will be very excited as you pick up the bits and see what we have been up to.

There are a ton of things I love about Silverlight. This is my top 10 list from a developer’s point of view:

1. All of your .NET skills transfer to Silverlight. All of the .NET APIs we are releasing are subsets of the existing support on the desktop. That means if you know the .NET API set you will be able to start using Silverlight right away (this is similar to the approach we took with the Compact Framework).

2. The APIs we are releasing are “right sized”. That means we looked for the most powerful subset we could find while keeping the size small.

3. You can use HTML and XAML. You can add Silverlight features to your favorite HTML/AJAX based application very easily and seamlessly mix the two. You can use a consistent and easy .NET programming model to write code against both. ASP.NET AJAX also supports using Silverlight through new controls we are releasing. And all of this works in your favorite browser (IE, FireFox, Safari, and (coming soon) Opera).

4. You get the same CLR from the desktop, just factored for size. This isn’t an interpreter. You get the desktop JIT and GC for superior code performance. Because we support generics and runtime type helpers (Reflection et al), we get LINQ support too. Finally you will be able to use Visual Studio for debugging on both the Windows *and* the Mac.

5. Let’s repeat that again: it runs on the Mac. And you can do full x-debugging from Visual Studio. That’s worth its own bullet J

6. Your favorite languages are supported on the client. C# and VB.Net work out of the box. With the new DLR, we have support for IronPython, IronRuby, Javascript, and the new dynamic VBx compiler. It is called the Common Language Runtime for a reason and we are raising the bar with Silverlight.

7. Visual Studio is your developer tool. You can use Visual Studio “Orcas” to write Silverlight code, debug it, etc. This is the same tool you have learned over the years and you will feel right at home working on Silverlight projects.

8. Expression is your designer tool. You can use the same Expression suite of tools to design for Silverlight projects as well. The code projects round trip between Expression and Visual Studio so you can have the user experience pro beef up your content. As an engine guy, I’m more adept at stick figures and console apps so this one is really handy J

9. Deployment is friction free. I’m going to write a longer blog entry on this one feature alone, but in a nutshell you can download Silverlight in a compact format without reboots on the machine. Your code is pulled down via the normal browser cache and executed. There is no GAC to figure out here, just point and go.

10. Silverlight is a secure sandbox system. The system was designed to support the browser sandbox from day one. This includes a new simplified security model which requires user code to be Transparent (a feature introduced in CLR V2).

The code you can build on top of this powerful base is astonishing! You get all of the power of .NET and familiarity with the class libraries only in a wonderfully factored package (easily < 5 MB compressed).

Now that we’ve announced the product I have a bunch of new blog content I’m planning to post on dynamic languages, friction free deployment, what it means to have a new CLR, porting to the Macintosh, when to use Silverlight vs the full .NET Framework, etc. Please let me know if there are particular topics you are interested in. As with our original .NET announcement at PDC 2000, this one comes with a lot of new stuff that will take a while to consume. Hang in there, it’s worth the effort!