Even a chimp can write code

Saturday, December 31, 2005

Capt. Keith Compton and baby Noor

Ashley's cousin Keith, who's serving as a pediatrician with the 10th Mountain Division’s 1st Brigade Combat Team in Iraq, has been taking care of a baby with a birth defect for the past 3 weeks. He was one of the doctors that diagnosed the baby -- referred to as baby Noor -- with myelomeningocele spina bifida, a birth defect in which the backbone and spinal cord do not close before birth.

He recently told his mom he'd been extra busy lately because there's been a lot of press interest in what he and the fine folk from the 1st Battalion, 121st Infantry Regiment’s Charlie Company are doing. Capt. Fournier, Lt. Morgan and other soldiers from Charlie Company have been trying hard to arrange medical care for the baby in the United States. Their efforts paid off when several organizations offered to support the endeavor financially and logistically. Prior to this, Keith and his team had decided that with lack of resources in Iraq, the baby wouldn't live for too long. They have declared her medically fit to fly to Atlanta where doctors will operate on the tumor. The soldiers have even lobbied to get passports and visas for the child's parents.

Regardless of what you think of the war, this is a great story of the American will. Keith left a good practice stateside to serve his country in Iraq when the Reserves were his unit was called [ed: Thanks, Brian]. We know his wife, his kids and parents are really proud of what he is doing. As are we.

Email this | Bookmark this

Friday, December 30, 2005

The Dead Sea Scrolls will be in Seattle

The Dead Sea Scrolls, widely considered the greatest archaeological discovery of the 20th century, will be in town next September. The Pacific Science Center has started selling tickets and I snagged a couple just a minute ago.

Email this | Bookmark this

Monday, December 19, 2005

Windows Vista and WinFX December CTPs are out!

Get them here. I am excited about the first drop of "Cider", the Visual Designer for Windows Presentation Foundation, in Visual Studio Extensions for WinFX.

As always, give these a whirl and tell the team what you think and how we can do better: WPF Forum, WPF Newsgroup, Cider Forum.

Update: German and Japanese language packs for Dec CTP have now been released.


Email this | Bookmark this

Sunday, December 04, 2005

How to: Reference a file embedded within a DLL in WPF

In Windows Presentation Foundation, you can access a file embedded within a reference assembly via markup and in code using a special Component qualifier in your relative URI.

Suppose you have a reference assembly (declared as Reference in your project), which contains an image file that you'd like to access. In markup, you can write:

<Image Source="/MyReferenceAssembly;Component/MyImage.jpg" />

The Component qualifies MyReferenceAssembly as being a reference assembly. The reference assembly must always be the first segment in such a relative URI. The example above is a common short form of the actual usage. The full form involves the assembly's strong name in order to unambiguously address a specific assembly at runtime. You can extend this concept to assemblies in the Global Assembly Cache (GAC) as well.

The actual long form of this URI syntax involves referencing the assembly in a URI segment with the following syntax:

  • Each parameter within this URI segment is delimited by a semi-colon (;)

  • ComponentDisplayName is the display name of the assembly or library, and is mandatory

  • The optional VersionNumber is a dotted-decimal string prefixed with a v.

  • The optional PublicKeyToken is the hexadecimal form of the public key token. In string form, it is represented in 16 characters

  • The keyword Component is mandatory when referencing assemblies or libraries

  • A true strongly named component requires all of the above to be specified.

None of the above parameters are required to be case-sensitive. Each of the following represents a legal use of this syntax:

<Image Source="/MyLibrary;v1.0.0.1;9b35aa32c18d4fb1;Component/MyImage.jpg" />

<Image Source="/MyLibrary;Component/MyImage.jpg" />

<Image Source="/MyLibrary;v1.0.0.1;Component/MyImage.jpg" />

<Image Source="/MyLibrary;9b35aa32c18d4fb1;Component/MyImage.jpg" />

<Image Source="/MyLibrary;9B35AA32C18D4FB1;component/MyImage.jpg" />


Email this | Bookmark this

Saturday, December 03, 2005

More on resource loading in WPF

I recently posted an entry on Resources in Windows Presentation Foundation. That topic covered a whole gamut of things such as Resource and Content build actions and referencing files at an application's site of origin without using a hardcoded URL. I also talked about why you would use one approach over the other.

Andrey Skvortsov commented on that post: Could you elaborate more last variant with pack:// uri syntax for local windows app?You were speaking about win apps and suddenly jump to web based deployment model though it's completly different things IMHO.

I had touched ever so briefly on the Pack URI syntax but didn't give details because I figured that was a whole different topic on it's own, and was much better addressed by the XPS (a.k.a Metro) specification. However, I will try to clarify the issues he's raised.

Pack URIs
The Metro package is a logical entity comprised of a number of parts. The Pack URI scheme defines a way to use URIs to refer to part resources inside a Metro package. It uses RFC 2396's (Uniform Resource Identifiers: Generic Syntax) extensibility mechanism for defining new kinds of URIs based on new schemes. You're probably aware that the scheme is the prefix in a URI, e.g. http, ftp. So Metro defines pack as a new scheme. The URI format is so:


The authority component in a Pack URI is itself an embedded URI pointing to a package. This must be a legal URI per RFC 2396. Of course, since it is embedded in the Pack URI, you must escape reserved characters. In our case, slashes ("/") are replaced by commas (","). Other characters like "%", "?" etc. must be escaped. See the spec for complete details. Windows Presentation Foundation provides an application with two built-in authorities: application and siteoforigin.

The application authority abstracts the deployed application itself. Any resources embedded in that application assembly, one of it's satellite resource assemblies or even loose files accompanying that application may be referenced using this authority. Of course, your project must define these files as Resource and Content, respectively. I should add though, that you need not use the Pack URI syntax for application files such as these. You can just use regular relative URIs.

The siteoforigin authority abstracts the conceptual site of origin of the deployed application. So if you had a file test.jpg at the location where the application binaries and manifests reside, say C:\myfiles\, then you need not hardcode the URL file:///C:/myfiles/test.jpg. You can instead use the abstraction pack://siteoforigin:,,/test.jpg. Notice that I said need not: in a full-trust application (Window-based installed application), you can do pretty much what you want. But in a web-browser application, you cannot access files on disk so adding a reference such file:///C:/myfiles/test.jpg pretty much binds you to a full trust app, and moreover you have to worry about how to get that image into that location for everyone that uses your app.

So, to go back to Andrey's question, if he were prototyping a WPF app, it would be prudent to use these abstractions and make the app portable, no matter if the prototype started out an installed or browser-hosted app flavor. Remember that with WPF, you use the same programming model for an installed app and a browser-hosted app. You can switch between these two flavors merely by changing the HostInBrowser and Install properties in your project, and pretty much nothing else. Besides, ClickOnce does the heavy lifting of downloading all loose content files for your application during deployment, so you don't have to.

Is there an easier way to construct Pack URIs?
Yes, look at the System.IO.Packaging.PackUriHelper class and try experimenting with the Create method by passing it different types of URIs as parameters.

You don't really need Pack URIs
That's right. The novice WPF programmer can survive without knowing how Pack URIs work. I've talked about how you can use simple relative URI references instead of the pack://application notations. Further, if you're looking for a package part or better still, the stream for an embedded resource you can use Application.GetResourcePart(Uri relativeUri). To get a stream for an XML file embedded in your application:

Stream stream = Application.GetResourcePart(
new Uri("RssFeed.xml")).GetStream();

To get the stream for a loose content file you can use Application.GetContentPart(Uri relativeUri). For e.g. here's how to get a stream for a declared loose image file with your application:

Stream stream = Application.GetContentPart(
new Uri("MyImage.jpg")).GetStream();

To get the stream for a file at the location from where the application was launched, you can use Application.GetRemotePart(Uri relativeUri). For e.g. here's how to get a stream for an undeclared text file at the site of origin:

Stream stream = Application.GetRemotePart(
new Uri("Contacts.txt")).GetStream();

Update [Apr 2009]: If you came here looking for resources and URIs in Silverlight, then you will find this post helpful. Note that Silverlight does not support pack URIs.


Labels: , ,

Email this | Bookmark this