Wintellog

WinDBG 6.9.3.113 Released

jrobbins — Mon, 05 May 2008 15:27:25 GMT

Looks like the WinDBG team was busy over the weekend and posted a new build of WinDBG: 6.9.3.113. The big fixes look like squashed bugs and performance improvements in symbol server portions. I bet you could drop those DLLs into your Visual Studio directories and get the benefit there as well.

Silverlight Page Turning Made Simple

jprosise — Mon, 05 May 2008 00:26:00 GMT

My latest Wicked Code column is now online at MSDN Magazine. Titled "Silverlight Page Turning Made Simple," it presents a Silverlight 1.0 framework for building slick page-turning applications. I mentioned the framework in an earlier blog post but didn't publish the source code because it needed to appear in MSDN Magazine first. Now you can download it, use it, and modify it to your heart's content.

And yes, I'll port the framework to Silverlight 2.0 soon.

My Beef with Vista and IE

jprosise — Sun, 04 May 2008 23:33:00 GMT

I have largely avoided problems with Vista by only running it on PCs on which it comes preinstalled. At least I avoided problems until a few weeks ago. With a total of five PCs and laptops now running Vista in my house, the constant avalanche of automatic updates seems to break something every day. The latest issue I’m fighting is one that causes ASP.NET apps launched in IE 7 from Visual Studio 2008 to sometimes start with JavaScript disabled. It’s pretty hard to teach an ASP.NET class when LinkButtons don’t work.

But worse than having ASP.NET broken on my development box is what IE 7 has done to the PC in the kitchen. For more than 20 years my wife has used my hand-me-down PCs. Last week I bought her her first-ever new PC: a Dell quad-core with 3 GB of RAM, a 500 MB hard disk, a 20-inch LCD monitor, and Vista Home Premium. (For the first time ever, I’m envious of her PC!) At first I was a little hot when Vista didn’t support my trusty USB wireless network adapter, but $70 and a new adapter later, Vista was happy and so was I.

The smiles didn’t last long. My wife fired up IE 7 on her new computer and went to our high school’s parent portal to check my son’s math grade. IE, however, wouldn’t let her get past the login page; it kept insisting “Internet Explorer cannot display the webpage.” She asked if this was another Vista problem. I knowingly assured her it wasn’t, and informed her that she had been running IE 7 on XP for a long time. Just to make sure, I downloaded the latest version of Firefox and went to the parent portal. Much to my surprise, Firefox let me log in and view grades just fine! I spent the next couple of hours toggling settings in IE 7 trying to get past the problem, and a couple of hours after that doing Web searches and analyzing HTTP traffic to find out why IE 7 couldn’t display a page that Firefox had no problem with. (It has something to do with “302 Temporarily Moved” responses coming back over SSL/TLS, but that’s as far as I’ve gotten with it.)

My wife can still check our son’s grades with IE 7 on her old XP PC. She can check grades with Firefox on her new Vista quad-core. But she can’t use IE 7 to check grades on Vista. She’s confused, and so am I.

Vista SP1 for my 64-bit OS has fallen and it can’t get up!

pmehner — Tue, 29 Apr 2008 05:15:00 GMT

Vista SP1 for the 64-bit version of the OS has fallen on my computer, and it can’t get up! I’ve been without my primary computer now for several days due to the release of SP1 for Vista. The symptom is an infinite loop of installations and failures of SP1 (the specific details seem to vary by people reporting to be afflicted with this problem).

Nick White at Microsoft declares that the problem “affects a small number of customers in unique circumstances” on the Windows Vista blog here:

http://windowsvistablog.com/blogs/windowsvista/archive/2008/02/19/update-on-windows-vista-sp1-prerequisite-kb937287.aspx

but Google turns up nearly 36,000 hits for the pretty specific phrase of “configuring updates: stage 3 of 3 vista ultimate 64 sp1”; so I have to believe there are a few more customers being negatively impacted by this than just moi.

This blog was helpful in resolving the infinite patch installation loop in case you happen to get caught by this nasty thing:

http://forums.microsoft.com/technet/showpost.aspx?postid=2873378&isthread=false&siteid=17&authhash=7f2056e7cf93af49d9d8704602bc97be8b4c437b&ticks=633390464558901682&sb=0&d=1&at=7&ft=11&tf=0&pageid=5

It doesn’t “solve” the problem, but it will at least make your computer useable again for awhile so that you can backup your important files, etc. In my case whenever I install a new IIS feature, the pattern of installing/failing SP1 starts all over as soon as I reboot my machine. Everything having to do with attempting to resolve this problem seems to take hours of time (SP1 itself takes nearly an hour to install and then another hour after it aborts to rewind itself). KB937287 has been installed on my machine 5 times now! After SP1 fails in its installation, KB937287 shows back up again in Windows Update. KB937287 is apparently a pre-requisite patch to prepare your computer for the slaughter that is SP1.

I spent nearly two hours on an IM with Microsoft tech support this evening where they took remote control of my computer and declared that the problem was with my Norton 360 antivirus interfering with the service pack installation (even though my anti-virus had already been disabled per the SP instructions). They asked me to remove my anti-virus and re-install SP1 again and then scheduled me for a call back tomorrow. Unfortunately the results were an unsuprising repeat of the “configuring updates: state 3 of 3“ hell that was my weekend (it’s like groundhogs day all over again)! At this point I’m thinking I would be better off simply burning my computer to the ground and reinstalling the OS without the automatic patch feature disabled until MS can get this sorted out. In point of fact, this is exactly what many customers seem to be blogging that they did. It may only be affecting a small number of customers, but the impact to those minority customers seems severe.

Instrumentation, Your App, and You - Part II: Eventing

ahopper — Tue, 29 Apr 2008 00:19:00 GMT

This is a continuation of my inaugural blog series on instrumentation (see part one here).

Eventing is one of those features in the .NET Framework that is incredibly useful, especially if you are an Enterprise or Internet-facing application developer. Proper eventing instrumentation can make the difference between an operable application and something your IT guys would never allow in the datacenter. Unfortunately, it is also really easy to abuse.

OK, this is where I don my Pedantic Instrumentation Guy hat. Yes, I'm going to be an annoying PIG that asks you to do a bit of work in order to have good instrumentation so you don't have to pay some ex-green-beret a lot of money to wade through mini-dumps. (Not that we mind the income, mind you!)

All too often, developers will use the event log as a poor man's trace log - they'll dump informational messages into the Application log or, worse yet, perform full stack dumps into the log when an exception is caught. In addition, it's just too easy to configure programmatically, which can set you up for embarrasing crashes.

You see, the event log was not intended to act as a log file; instead, it is intended to be a place where you can go to see a comprehensive view of important things happening on your system. There are two magic words in there I want to emphasize: comprehensive and important. You must understand that you are not the only application writing to the event log. In fact, there's a phenomenon known as an "event storm" where a poorly written application can flood a computer's event log with so much useless or redundant data that other things that are really useful to see like warnings from SQL or disk I/O errors get missed. This logically brings us to event importance. You really should only be logging significant events. Things like startup, shutdown, catastrophic failures but most importantly, recoverable errors.

Ahhh, recoverable errors. PIG hat still on? Ah, good. This topic could (and probably will) merit a whole series of posts dedicated to knowing/learning how your applications may fail. Here's a Golden Rule of eventing: Do not log an error if all your poor sysadmin can do is see that the application has logged an error. Trust me; he's not going to appreciate the event message for its innate beauty. If there is no possible recovery action documented for a particular error event ID (or even better, included in the event's message), then all your app is doing is indicating to the sysadmin that he should seriously consider uninstalling your application. Consider this: you see the following error event:

Log Name:      Application
Source:        MyApplication
Date:          5/8/2008 7:00:00 AM
Event ID:      0
Task Category: (0)
Level:         Error
Keywords:
User:          N/A
Computer:      datacenter1
Description:
Object not set to an instance of an object.

Did this tell you anything about how you can prevent this error in the future? If not, why is it in the event log? If it doesn't provide me with a way to help my system be happy again, it's just noise. The best I can do is to attach a debugger and snap a minidump when I hit a NullReferenceException, and this is not something to consider lightly when you've got an Internet-facing application (Or tight purse-strings. Do you know how much it costs to hire ex-green-berets these days?).

No, a much better error event would be:

Log Name:      Application
Source:        MyApplication
Date:          5/8/2008 7:00:00 AM
Event ID:      1033
Task Category: (3)
Level:         Error
Keywords:
User:          N/A
Computer:      datacenter1
Description:
Unable to retrieve customer information from the database. Please verify that the 'customer' database at server 'database2' is accessible.

So, what's the difference here? Well, there's the obvious difference and the hidden one. The obvious difference is that the event gives you a pretty good indication of what's going on. In addition, it gave you some things to go check to help your app get back on its feet: is the database server up and running? If so, is the database available? The hidden difference is that the developer anticipated that he may not get a valid object from the call to retrieve an object from the server and wrote error-handling code to capture the information needed to troubleshoot the problem and to write the above entry. I'm not going to lie and say that it's easy to write code that anticipates failure. It's actually pretty hard to know all of the ways in which some component can fail, especially if you didn't write it yourself. Some of this will come from experience and testing, and there are also static analysis tools that can analyze your code's call stacks for exceptions that aren't handled but if you're really lucky, the developers who wrote the component will have included things like <exception> information in their XML documentation. With all of the above and some grunt-work on the developers' part, you should be able to tell your sysadmin what is wrong with your app. So what if you encounter a truly exceptional exception? Well, that falls under the category of catastrophic failure. For obvious reasons, it's your responsibility to try to minimize the scenarios where one of these can occur, but if it were to happen this is where all of the helpful advice I provided in the tracing article (you DID read that, right?) comes in.

Oh, one other thing you may notice in my "new and improved" log message is that there was an event ID. This is also a pretty important concept: once you've spent the time to analyze the manner in which your application can fail, try to assign event IDs to the cause of failures you are logging. For example: an inability to connect to the database server is 1033, an access denied to a configuration file may be 2021, and so on. If you do your homework here you can not only make it easier for a human being to find and correct the issue preventing your application from functioning but you can facilitate the development of auto-recovery actions in monitoring packages like System Center Operations Manager. Spending the time to itemize your event messages also allows you to leverage the string formatting and localization capabilities of the Message Compiler (mc.exe) utility. I'll dedicate a separate post to how one can use MC.exe to generate message files and how you can register and use event sources that use message files.

Finally, let's talk about event source registration. Again, this is one of those areas where things were made a wee bit too easy. A pattern you see too often in managed code is:

if (!EventLog.SourceExists("Foo"))
{
EventLog.CreateEventSource("Foo", "Application");
}
EventLog.WriteEntry("Foo", "Some event", EventLogEntryType.Information);

In fact, I was apalled to discover this code in a Microsoft certification exam! You should never ship code like the above for a couple of reasons, but the most obvious one is that it requires elevated permissions to create an event source. If an unprivileged user account attempts to run the above you will get a SecurityException. Instead, have your installation package leverage Windows Installer's support for registering event message files and use the WriteEvent overload instead - that way, you can create an EventInstance object that contains the event message ID and supply format strings that get plugged into the appropriate place in the message.

Well, there you have it. A whirlwind tour of the philosophy behind proper* event logging in your application.

Whew. Now I can take this stupid thing off.

* "Proper" is in the eye of the beholder. Feel free to ignore any and all of my advice. Tax, tag and title not included in the advertised sale price.

Instrumentation, Your App, and You - Part I: Tracing

ahopper — Mon, 28 Apr 2008 23:38:00 GMT

It's been a while since I've blogged about anything technical, and since I'm here in my new home at Wintellect I decided that I need to begin anew. So, without further ado...

I wish I could find a way to make instrumentation sexy; every time I try to explain to someone about why they should invest in instrumentation, I see them get the “deer in the headlights” look and try to find a way to get away from this crazy bald man. It’s just so BORING… and invaluable.

Basically, my philosophy is that attaching a debugger is well and good, but there are only a few scenarios where that’s going to be possible or acceptable. With Enterprise-facing Web or LOB applications, you have a lot of leeway – they can afford to have you (or one of their technical resources) go to a machine and attach WinDBG or CDB – but I hold Internet-facing sites and client-side code to a much higher bar. With a live Internet-facing site, you can’t just hit a breakpoint and dig around as it brings the app to a screeching halt. Even scripting a breakpoint that snaps a minidump and resumes is no good as it still blocks the app for an indeterminate (although admittedly pretty short) amount of time. With a client-side application, you simply cannot ask a customer to install a debugger and get that minidump to you.

So, how can you instrument your application? Well, there are three primary ways and one interesting way. You can use trace logging (which will be the core focus of this post), event logging, performance counters, and finally, WMI.

There are plenty of times where that hard-won minidump simply isn’t enough; after all, not only is it rocket science to most developers, but all you’ll see stack traces and current values for members – not HOW you got to this point. A lot of the art debugging is intuiting what path the app took to get to this crashing stack, and a good trace log can let the app do a lot of that detective work for you. Even minimal stack tracing (entry/exit) gives you a great deal of behavioral information, and this can be invaluable when you’re trying to figure out WHY you’re waiting on that Mutex again.

Tracing undeniably has a non-zero overhead associated with it, and this overhead takes two forms. First, there’s the behavioral/code overhead that goes with getting people in the mindset of leaving post-it notes in their code for the unfortunate soul who has to troubleshoot their misbehaving app. Second, there’s the performance overhead that goes along with adding more calls to the application. The first is manageable, and the second is fixable.

On the behavioral front, it’s very much an evangelism issue and it’s kinda like selling insurance for your career. Once you have an app out in the field with zero instrumentation and some high-profile customer is screaming for your head because you STILL don’t know why your app is hitting this exception, you gain a deep appreciation for how much you would have loved to know what the response from that SOAP call was. As for the amount of work it requires from the developer, it all depends upon the class of application; there’s a dial you’ll want to turn for the amount of tracing code you write. When I’m wearing my hard hat I want tracing at every decision block, every exception handler to dump the exception and logging the parameters to methods at “verbose” levels. When I’m wearing my “warm fuzzy” hat for simple LOB applications, I want tracing before and after major events in the code like network/IO calls. But in practice, it’s going to be up to the dev to understand how their code might misbehave and to leave a trail of tracing breadcrumbs to help some poor soul noodle out why some button didn’t get enabled.

Now on to the performance overhead. Most developers don’t stop to think about the cost associated with constructing the call stack for a trace call, and when they see that their application’s runtime performance suffers because they have a bazillion trace calls that call ToString or box up a bunch of integers, they’re quick to blame tracing in general and yank it altogether (seen it happen first-hand, that). There’s no reason it has to be this expensive, though. If tracing isn’t enabled, it should just get out of the way – it’s only when we’re debugging that we want that overhead, and then we won’t care as much if we take a hit. It’s an unfortunate reality that all of the wonderful work the driver guys did on TraceWPP is lost in the managed world; there’s no (publicly available, that is) tool for preprocessing managed code and wrapping trace calls with runtime-evaluated conditionals to shortcut the construction of the call stack if tracing is not enabled.

So, if we can't use TraceWPP, what can we do, then? Well, for the time being (hint, hint), we're stuck with hand-generating conditional blocks to detect whether tracing is enabled for a particular trace level. However, I hope to remedy that situation here in this blog: we'll walk through the implementation of a preprocessor in the style of TraceWPP and use it for our managed apps.

Well, this post has become long enough for now. We'll take a look at the other ways your application can help you debug itself later.

Vista x64 is Now Officially Supported on Mac Hardware!

jrobbins — Fri, 25 Apr 2008 16:31:47 GMT

You all know my geek love for Apple hardware. Yesterday Apple released the official drivers for Vista x64 support! You'll need to download and install Boot Camp Update 2.1 and you'll be set. Totally and completely excellent news!

Easily Downloading and Installing the Sysinternals Suite

jrobbins — Sun, 20 Apr 2008 23:18:00 GMT

Everyone uses Mark Russinovich's and Bryce Cogswell's excellent Sysinternals Tools. Tools like Process Explorer and Process Monitor have helped solve some of the toughest bugs I've ever worked on. I've been surprised how many people didn't know that all the tools available in a single download: the Sysinternals Suite.

Whenever I see that one of the tools is updated, I find it easiest to grab the Suite .ZIP file and unzip it to my utility directory. After having done the manual updating a couple of times, I wrote a PowerShell script to do the download and unzipping automatically. I thought others might find it useful. Note that you'll need the excellent and free 7z archive tool in your path.

As I'm still a PowerShell novice, please don't be afraid to point out anything I can do better.

##################################################################
# Get-SysInternalsSuite.ps1 - John Robbins - john@wintellect.com
#
# Note that this script requires the excellent 7Z.EXE in the
# PATH environment variable. You can get 7Z.EXE, which is free,
# at http://www.7-zip.org/.
#################################################################
param ( [string] $Extract ,
        [string] $Save )

# Always make sure all variables are defined.
Set-PSDebug -Strict
function Usage
{
    ""
    "Downloads and extracts all the tools from Sysinternals"
    ""
    "Usage: Get-SysInternalsSuite -extract <directory>"
    "                             [-save <directory>]"
   "Required Parameter :"
    " -extract <directory> : The directory where the SysinternalsSuite.zip"
    "                        tools are extracted."
    "Optional Parameters :"
    " -save <directory> : Saves SysinternalsSuite.zip to the specified"
    "                     directory. If not specified, the .ZIP file "
    "                     is not saved."
    " -? : Display this usage information"
    ""
    ""
    exit
}

function CreateDirectoryIfNeeded ( [string] $directory )
{
    if ( ! ( Test-Path $directory -type "Container" ) )
    {
        New-Item -type directory -Path $directory > $null
    }
}

##################################################################
# Main execution starts here.

# Check for the help request.
if ( ( $Args -eq '-?') -or ( ! $Extract ) )
{
    Usage
}

$paramLog = @"
Param Extract   = $Extract
Param Save      = $Save
"@
Write-Debug $paramLog

[string]$sevenZName = "7Z.EXE"
# Verify I can find UNZIP.EXE in the path.
[string]$sevenZPath = $(Get-Command $sevenZName).Definition
if ( $sevenZPath.Length -eq 0 )
{
    Write-Error "Unable to find $sevenZName in the path."
    exit
}

# If the extract directory does not exist, create it.
CreateDirectoryIfNeeded ( $Extract )
# If there's a save directory set, us that otherwise, use the %TEMP% directory.
[Boolean]$deleteZipFile = $TRUE
[String]$downloadFile = ""
if ( $Save.Length -gt 0 )
{
    CreateDirectoryIfNeeded ( $Save )
    $downloadFile = $Save
    $deleteZipFile = $FALSE
}
else
{
    # Use the %TEMP% path for the user.
    $downloadFile = $env:temp
}

# Build up the full location and filename.
$downloadFile = $(Get-item $downloadFile).FullName
$downloadFile = Join-Path -path $downloadFile -childpath "SysinternalsSuite.zip"

# Let the download begin!
Write-Output "Starting download of the Sysinternals Suite"
$webClient = New-Object System.Net.WebClient
$webClient.DownloadFile("http://download.sysinternals.com/Files/SysinternalsSuite.zip" ,
                        $downloadFile)
Write-Output "Sysinternals suite downloaded to $downloadFile"

# I don't like to see all the output from 7z unless there's a problem so I'll
# redirect to a temporary file and if there's any problems, I'll show it.
$temp7zOutput = [System.IO.Path]::GetTempFileName()

# Since the -o option to 7Z.EXE cannot have a space between it and the
# directory there's a bit of a problem. PowerShell does not expand the
# line -o$Extract if passed directly on the command line.
$outputOption = "-o$Extract"
Write-Output "Extracting files into $Extract"
&$sevenZPath x -y $outputOption $downloadFile > $temp7zOutput
if ( $LASTEXITCODE -ne 0 )
{
    # There was a problem extracting.
    Get-Content $temp7zOutput
    # Don't delete the download file.
    $deleteZipFile = $FALSE
    Write-Error "Error extracting the .ZIP file"
    Write-Error "The downloaded .ZIP file is at $downloadFile and will not be deleted."
}
# Delete the file that held the extraction output.
del $temp7zOutput
# Delete the downloaded .ZIP file if I'm supposed to.
if ( $deleteZipFile -eq $TRUE )
{
    Remove-Item $downloadFile
}

Paraffin 1.03 – Couple of Bug Fixes

jrobbins — Sat, 19 Apr 2008 23:19:08 GMT

Last year I released a tool to help make maintaining WiX 2.0-based installations easier called Paraffin. I've fixed the following two issues:

I was relying on the short name of the file when generating an updated .PARAFFIN file. Sadly, it looks like the short file names are essentially random. I now only rely on the File element, Source attribute when looking for existing files.
I had swapped INSTALLDIR and TARGETDIR when generating the fragment.

Hope you find it useful! Get the latest source code here.

Finding an Object’s GC Generation in the Visual Studio Debugger

jrobbins — Fri, 18 Apr 2008 19:05:16 GMT

As a .NET developer, your top three concerns are 1) Memory, 2) Memory, and the last one is the toughest, 3) Memory. While .NET takes away the pain of manual memory management if you aren't constantly worrying about what's in your Gen 2 heap, you're going to suffer with bad performance or worse, unexplained OutOfMemoryExceptions. The garbage collection system in .NET is fantastic, but when you trigger a garbage collection, none of your code is executing. That's why it's so important to have that feel for which of your objects are sitting in which generation.

While you can use WinDBG and Steve Johnson's excellent SOSEX extension to look up your objects, it's a bit painful. My ultimate dream would be that the CLR team would expose a heap walking functionality in the debugging API so this was a natural part of the Visual Studio debugger. While that may happen in a future version, I wanted to show you a way you can get this today. While I'll show this with Visual Studio 2008, everything should work exactly the same in Visual Studio 2005.

Finding an object's generation in your code is easy with the GC.GetGeneration function. Just pass the object as a parameter and the return value will be 0, 1, or 2. Since the debugger has supported calling functions from the debugger Watch window forever, there's nothing stopping you from calling GC.GetGeneration on your own. In fact, the debugger wants you call functions from the Watch window so they provide Intellisense and tool tip support to make it easy.

If I wanted to find out what generation the sb variable is in, just pass it as the parameter.

If the object you want to look at is in scope, calling GC.GetGeneration on it works great. The bigger question is how can you look at those objects that are not in scope? That's probably the case that you're most interested in seeing. Fortunately, there's a barely mentioned technique you can use to observe your interesting objects: Make Object ID.

In any debugger window where the expression evaluator is used, such as the Watch, Me/This, Locals, Quick Watch, and Data Tips, you can right click on the variable to bring up the context menu where you can access the Make Object ID command.

After selecting Make Object ID, you'll see that in the Value column or Data Tip display, there will be a decimal integer followed by the number (#) sign. That's the ID applied to that object. Note that Make Object ID will not add a reference to the object inside the debuggee. Think of Make Object ID as watching the object, but not referencing it.

In the screen shot below, I created an Object ID for the XmlDocument variable doc. That added the {1#} in the value column after the type. What's nice is that the Object ID can be viewed directly. In the second row, I typed in 1# so I could continue to observe that XmlDocument no matter where I stop later in the debugger. The important point of Make Object ID is that you can observe objects even when they are not in scope!

You might be wondering what happens if you add an Object ID to a second object in your program. What happens is that the second Object ID will be 2#, the third 3# and so on. If you want to observe thirty or forty objects, you'll need to put everything down in a table so you can keep them straight. I would love to see the ability to provide your own names to Object IDs in a future version of the debugger.

What I especially like about making an Object ID is that if the object you're watching is garbage collected, you'll see the that when you stop in the debugger. You may need to click the green recycle icon on the right hand side of the Value column if the line is grayed out when you stop.

While Make Object ID lets you observe objects outside of the current scope and see if its garbage collected, how does that help with determining the generation? The good news is that it helps tremendously as the expression evaluator in Visual Studio seems to know about the Object ID values and can parse them.

The documentation does not explicitly state that using the Object ID in different types of expressions is supported but in the discussion of Make Object ID, it says that you can use Make Object ID to set per instance breakpoints. Unlike native code, you don't have any object addresses while debugging in .NET. In native code, you'd set a per instance breakpoint with a condition of this == 0x1234567, where 0x1234567 is the address of the instance pointer. For .NET, add an Object ID to the this/Me of the object you want to stop on. In the breakpoint condition, you, if the Object ID is 5#, you'd enter this == 5# or Me = 5# for C# or VB, respectively.

I figured it could not hurt to try passing the Object ID to GC.GetGeneration to see what would happen.

Excellent! The expression evaluator does the correct parsing and you now have a way to watch what generation an object while using Visual Studio even if it's not in scope. While it's still a manual process, it might let you stay in Visual Studio a bit longer before you have to do the deep spelunking with SOSEX. Hopefully future versions of Visual Studio will make it easy to determine our object's generation, but at least you have a tip that works with today's debugger.

Control Interop, Silverlight-Style

jprosise — Sat, 12 Apr 2008 04:16:00 GMT

A number of people have asked me in recent weeks whether two Silverlight 2 controls hosted in the same page can communicate with each other, and if so, how. I tell them they need to build a JavaScript bridge between the controls and then the controls can talk to each other just fine.

Tonight I built a sample app to demonstrate. Here's what it looks like:

You drag the red ball in the upper rectangle and the blue rectangle in the lower rectangle mirrors the red ball's moves. The interesting aspect of this application is that each rectangle represents a different Silverlight control instance. In other words, the page hosts two Silverlight controls, and the red ball lives in one control while the blue ball lives in the other.

Here are the OBJECT tags used to instantiate two Silverlight controls:

type="application/x-silverlight-2-b1" width="400"

height="300" id="SourceControl">

</object>

</div>

type="application/x-silverlight-2-b1" width="400"

height="300" id="TargetControl">

</object>

</div>

Each control has its own DIV, and each loads a different XAP file. How did I get Visual Studio to build two XAP files, each containing a separate control assembly? I just added a second Silverlight Application project to the solution. If you already have a Web project in the solution, Visual Studio asks if you want the new project linked to the existing Web project:

Visual Studio obligingly adds the Silverlight project to the solution and configures the build settings so that building the project creates a second XAP file that, like the XAP file from the first project, is copied into the Web site's ClientBin directory.

To link the two Silverlight controls together, I began by converting the code-behind class for the second control (the one containing the blue ball) into a scriptable class and adding a scriptable method named MoveBall:

[ScriptableType]

public partial class Page : UserControl

{

public Page()

{

InitializeComponent();

HtmlPage.RegisterScriptableObject("other", this);

}

[ScriptableMember]

public void MoveBall(double x, double y)

{

Ball.SetValue(Canvas.LeftProperty, x);

Ball.SetValue(Canvas.TopProperty, y);

}

Then I added the following JavaScript function (the "bridge") to the HTML page:

var _target = null;

function moveBall(x, y)

{

if (_target == null)

_target = document.getElementById('TargetControl');

_target.content.other.MoveBall(x, y);

}

Finally, I added the following statement to the MouseMove handler in the first control (the one with the red ball):

HtmlPage.Window.Invoke("moveBall", x, y);

The X and Y coordinates passed in represent the current position of the red ball--the position I just moved it to in response to the latest mouse move.

See how it works? You move the red ball. The MouseMove handler that moves the ball also calls the JavaScript moveBall function, which in turn calls the second control's MoveBall method. The red ball moves and the blue ball moves, too. This sample takes advantage of Silverlight 2's rich DOM integration features which allow C# methods to call JavaScript functions, JavaScript functions to call C# methods, and a whole lot more.

I'll post the source code this weekend. For now, it has been a long week, it's late, and I'll be locked away in a hotel all weekend building slides for my Silverlight precon at TechEd and taking care of other jobs that have piled up in my to-do list. Time to get some sleep.

UPDATE: The source code has been posted and you can download it here. In addition, I posted a new version of SilverLife that uses DispatcherTimer rather a Storyboard to drive cell animations. You can download the new version here.

Reading XAML from a Silverlight Application Assembly

jprosise — Tue, 08 Apr 2008 04:54:00 GMT

I was having dinner with Walt Ritscher tonight when he posed an interesting question: how can a Silverlight app load its own XAML from an application assembly?

I thought I knew the answer, because I had just finished doing a lot of research into the various ways to package code and resources in Silverlight 2.0. And I knew that the XAML files in a Silverlight 2.0 app get embedded as resources in the application assembly, which in turn gets embedded in the application package (the application's XAP file). But when I got back to my hotel and tried it, it didn't work. So I played around some and found the secret incantation.

Here's the Page.xaml file in the test app that I wrote:

<UserControl x:Class="SilverlightTestApp.Page"

xmlns="http://schemas.microsoft.com/client/2007"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Width="400" Height="300">

</Grid>

</UserControl>

And here's the output from the program:

Finally, here's the code in Page.xaml.cs that produces the output by loading Page.xaml from the application assembly and assigning it to a TextBlock object:

StreamResourceInfo sri = Application.GetResourceStream

(new Uri("SilverlightTestApp;component/Page.xaml", UriKind.Relative));

StreamReader reader = new StreamReader(sri.Stream);

Output.Text = reader.ReadToEnd();

The trick is to include "assemblyname;component" in the URI passed to GetResourceStream, even though the assembly you're loading from is the application assembly and not a library assembly. Normally you don't have to include the assembly name if you're targeting the application assembly, but this is obviously an exception--at least in Beta 1.

I don't know how useful this information is, but it ought to make a good icebreaker at a Silverlight party.

Silverlight Deep Zoom

jprosise — Tue, 01 Apr 2008 22:25:00 GMT

Like a lot of folks, I was pretty impressed the first time I saw Silverlight 2.0's new Deep Zoom feature at work. So I downloaded Deep Zoom Composer and starting building apps to see what makes Deep Zoom tick. Deep Zoom Composer is cool, but what really makes Deep Zoom shine is the MultiScaleImage control. It is amazing how much you can do with so little code.

I built an app that incorporates some of my favorite travel photos:

You can zoom in and out with the mousewheel or pan around by dragging with the left mouse button down. Some of the photos I used are higher-res than others, but in most of them you can zoom in enough to reveal quite a lot of detail.

You can view the app online, and you can download the source code. The download doesn't include the images because the images comprise more than 30 MB. But you can generate your own images and metadata with Deep Zoom Composer and plug them into my demo. All you have to do is copy the output folder created by Composer into DeepZoom_Web's ClientBin folder and point the MultiScaleImage control declared in Page.xaml to the info.bin or items.bin file in the output folder. Then fire up the app and zoom away.

When I exported from Deep Zoom Composer, I checked the "Create Collection" box to export a collection of images rather than one monolithic image. Although my code currently doesn't take advantage of it, exporting a collection allows you to use the SubImages property of the MultiScaleImage control to addess the individual images and even to change their position, aspect ratio, opacity, and Z-index. It appears (though I haven't tried it yet) that you can also change the zoom factor of individual images. Look for an updated demo in the near future that demonstrates some of these enticing capabilities.

Updated Deep Dive CSS code

Tue, 01 Apr 2008 21:25:35 GMT

Thanks to all the folks that came to my Deep Dive CSS for the ASP.NET Developer session at this past weekend's Atlanta Code Camp. I got some really great feedback from the evaluations and will definitely incorporate some suggestions into this presentation in the future. The abstract, updated code and slides are available here: Deep Dive CSS for the ASP.NET Developer...(read more)

Threading and Marshaling in Silverlight 2.0

jprosise — Wed, 26 Mar 2008 23:45:00 GMT

Quick: can you spot what's wrong with this code?

Thread thread = new Thread(new ThreadStart(RunClock));

thread.Start();

...

private void RunClock()

{

while (true)

{

Clock.Text = DateTime.Now.ToLongTimeString();

}

The intent is to launch a thread and have that thread run an infinite loop updating a XAML TextBlock object that shows the current time of day. Aside from the questionable design (there are much more efficient ways to keep a time-of-day display up to date), there's something seriously wrong with this code. In fact, if you run it you'll find that the time-of-day display never updates at all. And therein lies a story.

I was surprised last year when I saw that the Silverlight 1.1 alpha had a System.Threading namespace complete with all the classes I needed to launch threads, synchronize threads, acquire threads from a thread pool, etc. Silverlight 2.0 Beta 1 contains all these classes and more. I'm still amazed that I can write multithreaded apps that run in a browser, and I've been doing a lot of that lately--not because I need to, but just because I can. Silverlight 2.0's BackgroundWorker class simplifies the process of running tasks on background threads, and DispatchTimer is a handy alternative to empty Storyboards for programmable game timers. But you don't have to use either of them; you can use Thread.Start, ThreadPool.QueueUserWorkItem, asynchronous delegates, and other mechanisms familiar to .NET developers to relegate tasks to background threads.

There is one nuance to Silverlight threading that you should be aware of, however: controls and other XAML objects can only be updated by the UI thread (the main thread that drives a Silverlight app). The reason the attempt to set the TextBlock's Text property in the example above fails is that we're attempting to set it from a background thread. For the sample to work, you need to modify it as follows:

private delegate void UpdateUIDelegate();

...

Thread thread = new Thread(new ThreadStart(RunClock));

thread.Start();

...

private void RunClock()

{

UpdateUIDelegate action = new UpdateUIDelegate(UpdateUI));

while (true)

{

Clock.Dispatcher.BeginInvoke(action);

}

private void UpdateUI()

{

Clock.Text = DateTime.Now.ToLongTimeString();

}

In the corrected code, the background thread marshals the call back to the UI thread by calling UpdateUI through a delegate invoked via the TextBlock object's Dispatcher property. Dispatcher is inherited from DependencyObject and is therefore present in all UI objects. For old folks like me who used to program Windows, this is analagous to using PostMessage to post a message to another thread. You don't have to use the Dispatcher property of the object you intend to update; you can use Dispatcher on any UI object to marshal the call to the UI thread.

Programmers who have written multithreaded WPF apps won't be surprised by any of this because WPF also requires UI objects to be updated by UI threads. And of course there are ways to avoid using Dispatcher altogether. The BackgroundWorker class, for example, fires events on UI threads, so there's no need to do any marshaling before updating a UI object. But there are times in Silverlight when you simply can't avoid marshaling from a background thread to a UI thread, and when those circumstances arise, it's useful to know about Dispatcher.