Logos Bible Software Code Blog

Continuation Tasks

2013-05-17T14:40:00-07:00

Last week I posted a video on Starting Asynchronous Work Using Tasks. This week's video is on Continuation Tasks. Continuation tasks allow you to control the flow of asynchronous operations. They are especially useful for passing data between asynchronous operations. Continuation tasks are normally created using the Task.ContinueWith method. They also can be created using methods like TaskFactory.ContinueWhenAll.

Using native DLLs from ASP.NET apps

2013-05-14T10:06:00-07:00

By default, ASP.NET uses shadow copying, which "enables assemblies that are used in an application domain to be updated without unloading the application domain." Basically, it copies your assemblies to a temporary folder and runs your web app from there to avoid locking the assemblies, which would prevent you from updating those assemblies.

This works great for managed DLLs, but not very well for native DLLs. ASP.NET doesn't copy the native DLLs, so the web app fails with an error that doesn't even make it obvious that a native DLL is missing or which one it is.

The simplest solution I've found is to turn off shadow copying, which causes the DLLs to be loaded directly from the bin directory. This is the strategy now being used in production by Biblia.com. Just add a <hostingEnvironment> element to your web.config:

<configuration>
  ...
  <system.web>
    ...
    <hostingEnvironment shadowCopyBinAssemblies="false" />

This also works for local development, but you may find that you need to restart the app pool in order to rebuild the app. Biblia has a pre-build step that runs appcmd stop apppool and a post-build step that runs appcmd start apppool with the corresponding /apppool.name argument.

Alternatively you could consider removing <hostingEnvironment> from your local web.config and putting your bin folder in the PATH system environment variable, but that will be problematic if you have multiple web apps that depend on different builds of the native DLLs.

Starting Asynchronous Work Using Tasks

2013-05-10T15:45:00-07:00

As multi-core processors are quickly becoming ubiquitous, it becomes increasingly important to use parallel and asynchronous programming techniques to create responsive, high-performance applications. The latest .NET releases have responded to this need by introducing the Task Parallel Library (TPL) in .NET 4, and the async/await keywords in C# 5.

We have created a set of fast-paced, code-driven videos on asynchronous programming in C# using TPL and async/await, with a focus on the Task-based Asynchronous Pattern (TAP). If you want a concise introduction to Tasks and async/await, these videos are for you! The videos are under 5 minutes each, and are intended to give a quick overview of each subject. The accompanying blog posts have links for further study.

This first video shows how to start asynchronous work using the Task.Run method, which returns a Task or Task<TResult>. The video also shows how to create tasks that are not run on any thread using TaskCompletionSource<TResult>.

Enjoy!

For further reading, see:

The Task-based Asynchronous Pattern by Stephen Toub (Microsoft)
Parallel Programming with .NET blog: There are many excellent articles here on async/await and tasks.

Next week's video: Continuation Tasks.

Building Code at Logos: Build Repositories

2012-11-19T13:40:00-08:00

As mentioned in my last post (Sharing Code Across Projects), developers work on the head of the master branch “by convention”. This is fine for day-to-day work, but we’d like something a little more rigorous for our continuous integration builds.

For this, we use “build repositories”. A build repository contains a submodule for each repository required to build the project. (In the App1 example, the App1 build repo would have App1, Framework and Utility submodules.) The CI server simply gets the most recent commit on the master branch of the build repo, recursively updates all the submodules, then builds the code.

The problem now: how is the build repository updated? We solve this using a tool we developed named Leeroy. (So named because we use Jenkins as a CI server, and Leeroy starts the Jenkins builds. We weren’t the first ones to think of this.)

Leeroy uses the GitHub API on our GitHub Enterprise instance to watch for changes to the submodules in a build repo. When it detects one, it creates a new commit (again, through the GitHub API) that updates that submodule in the build repo. After committing, it requests the “force build” URL on the Jenkins server to start a build. Jenkins’ standard git plugin updates the code to the current commit in each submodule and builds it.

The benefit is that we now have a permanent record of the code included in each build (by finding the commit in the build repo for that build, then following the submodules). For significant public releases, we also tag the build repo and each of the submodules (for convenience).

We’ve made Leeroy available at GitHub.

Posts in the “Building Code at Logos” series:

Building Code at Logos: Sharing Code Across Projects

2012-11-17T09:00:00-08:00

We often have common code that we'd like to share across different projects. (For example, our Utility library is useful in both the desktop software and in an ASP.NET website.)

One way of sharing code is to place it in its own repository, and add it as a submodule to all repos that need it. But submodules are a bit of a pain to work with on a daily basis (for example, git checkout doesn't automatically update submodules when switching branches; you have to remember to do this every time, or create an alias).

Submodules also make it difficult to “compose” libraries. For example, App1 and App2 might both use Utility, but they might also both use Framework, a desktop application framework that's not general-purpose enough to live in Utility, but is in its own repo. If Framework itself uses Utility as a submodule, then the App1 and App2 repos might contain both /ext/Utility and /ext/Framework/ext/Utility. This is a maintenance nightmare.

Our choice at Logos is to clone all necessary repositories as siblings of each other. In the App1 example above, we might have C:\Code\App1, C:\Code\Framework and C:\Code\Utility as independent repos. Dependencies are expressed as relative paths that reference files outside the current repo, e.g., ..\..\..\Utility\src\Utility.csproj. We've written a shell script that clones all necessary repos (for a new developer) or updates all subfolders of C:\Code (to get the latest code).

By convention, developers are working on the master branch on each repo (or possibly a feature branch in one or more repos for a complex feature). It’s theoretically possible for someone to push a breaking change to Utility and forget to push the corresponding change to App1 (a problem that submodules do prevent), but this happens very infrequently.

Posts in the “Building Code at Logos” series:

Building Code at Logos: Third-Party Repositories

2012-11-16T09:50:00-08:00

Some of our repositories reference third-party code. In many cases, this can be managed using NuGet, but sometimes we need to make private modifications and build from source.

We accomplish this by creating a repository for the third-party code. In some cases, this repository is added as a submodule under ext in the repositories that need it; in other cases, the binaries created from the code are committed to another repository's lib folder. The decision depends on how complicated it is to build the code versus how useful it is for developers to have the source (and not just precompiled binaries).

In the third-party repository, the upstream branch contains the unmodified upstream code, while the master branch contains the Logos-specific modifications.

When cloning the repository locally, the origin remote refers to our repository containing the third-party code. If the original third-party code is available via git, then we add an upstream remote that references the original maintainer's code.

Example: Creating a ThirdParty repo from source on GitHub

# clone a local copy of the remote third-party repository
git clone https://github.com/user/ExampleProject.git
cd ExampleProject

# rename the "origin" remote (created by clone) to "upstream"
git remote rename origin upstream

# add Logos' repo as the "origin" remote
git remote add origin git@git:ThirdParty/ExampleProject.git

# use this code as the "upstream" branch
git checkout -b upstream
git push origin upstream

# work on Logos-specific modifications
git checkout master

** make modifications

git commit -am "Some important changes."

# push the changes to our repo
git push origin master

Example: Creating a ThirdParty repo from source in Subversion

# create the git repo
mkdir ExampleProject
cd ExampleProject
git init

# add Logos' repo as the "origin" remote
git remote add origin git@git:ThirdParty/ExampleProject.git

# seed it with the upstream code
svn export --force http://source.example.org/repos/example/tags/1.0 .

# add all the code
git add -A
git commit -m "Add Example 1.0"

# use this code as the "upstream" branch
git checkout -b upstream
git push origin upstream

# work on Logos-specific modifications
git checkout master

** make modifications

git commit -am "Some important changes."

# push the changes to our repo
git push origin master

Once the repository is created, we will want to update it with new versions of the third-party code when they are released (then merge in our changes).

The new code gets committed to the upstream branch, then that gets merged into master. If necessary, conflicts are resolved, or our changes are edited/removed to reflect changes in the upstream code.

Example: Updating a ThirdParty repository from source on GitHub

# switch to the "upstream" branch, which contains the latest external code
git checkout upstream

# get the latest code from the "master" branch in the "upstream" repo
git pull upstream master

# switch to our local "master" branch, which contains Logos changes
git checkout master

# merge in the latest upstream code
git merge upstream

** fix any conflicts, and commit if necessary

# push the latest merged code to our repo
git push origin master

Example: Updating a ThirdParty repository from source in Subversion

# switch to the "upstream" branch, which contains the latest external code
git checkout upstream

** delete all files in the working copy, except the '.git' directory

# get the latest version of the third-party code
svn export --force http://source.example.org/repos/example/tags/1.1 .

# add all files in the working copy, then commit them
git add -A
git commit -m "Update to Example 1.1."

# switch to our local "master" branch, which contains Logos changes
git checkout master

# merge in the latest upstream code
git merge upstream

** fix any conflicts, and commit if necessary

# push the latest merged code to our repo
git push origin master

Posts in the “Building Code at Logos” series:

Building Code at Logos: Repository Layout

2012-11-15T09:30:00-08:00

We use git for source control, and have adopted a standardised reposistory layout for our projects.

The following example is for a Visual Studio solution on Windows, but can be adapted for other platforms.

Repo\                  -- this is the root of the repository
  Repo.build             -- NAnt build script (or equivalent)
  Repo.sln               -- Visual Studio solution file (at root)

  src\                   -- contains primary source code
    Logos.Project\         -- one subfolder per project
      Logos.Project.csproj
      *.cs
      Properties\
        AssemblyInfo.cs
    other projects\      -- as above
  tests\                 -- contains tests for each 'src' project
    Logos.Project.Tests\   -- one subfolder per test project
      Logos.Project.Tests.csproj
      *.cs
    other test projects\ -- as above

  ext\                   -- contains submodules
    Submodule\             -- third-party source
  lib\                   -- precompiled third-party code
    *.dll
  packages\              -- NuGet packages
    Package.1.0\           -- various packages
    repositories.config    -- configuration

  build\                 -- .gitignore'd, contains build output
  tools\                 -- build tools
    NUnit\                 -- test framework
    other tools\           -- other tools as necessary

At the root of the repository, we have the Visual Studio solution file (used by developers) and the build script (used by the build server). This might be a NAnt build file, a psake build script, a shell script, or something similar.

The src and tests folders contain the bulk of the code we write; this is the code that gets shipped to users or deployed to a web server, and tests that get run by the build server.

ext, lib, and packages contain third-party code (or sometimes Logos code that is consumed as a precompiled binary, rather than as source). Folders under ext are git submodules that reference third-party repos. lib contains pre-compiled DLLs and static libraries. packages is reserved for use by NuGet. (This folder is added to .gitignore if this repo uses NuGet Package Restore.)

build is never committed, but is reserved to contain build output. tools contains code that is required to build the project, but doesn't get shipped. This would include things like NUnit (or another test framework), StyleCop plugins, NAnt extensions, mocking frameworks, etc.

Posts in the “Building Code at Logos” series:

How to Crash Many WPF Applications (WPF 4 Edition)

2012-11-05T10:24:00-08:00

This is a follow-up to my three-year-old post: How to Crash every WPF Application.

Now that we’ve released Logos 5, which updates the version of WPF we target from WPF 3.5 to WPF 4.5, our customers are really helping us stress-test WPF 4.x. (It’s now a little sad that after three years, ours is the first (and only!) WPF 4 application installed on many of our users’ systems.)

On some systems, the application was crashing at startup with the following exception:

System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
  at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
  at MS.Internal.FontFace.PhysicalFontFamily.ConvertDictionary(IDictionary`2 dictionary)
  at MS.Internal.FontFace.PhysicalFontFamily.MS.Internal.FontFace.IFontFamily.get_Names()
  at System.Windows.Media.FontFamily.get_FamilyNames()
  at Libronix.Utility.Windows.FontFamilyUtility.<>c__DisplayClass2.<FindSystemFontByTitle>b__0(FontFamily font)
  at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
  at Libronix.Utility.Windows.FontFamilyUtility.FindSystemFontByTitle(String strTitle)
  at LDLS4.AppModel.CreateMainWindow()
  at LDLS4.OurApp.StartupCompleted()

We traced this to having a font with multiple family names in the same culture (or two cultures that WPF considers equivalent; in this particular case, es-ES and es-ES_tradnl were considered identical). PhysicalFontFamily.ConvertDictionary tries to build a dictionary mapping cultures to names, but assumes the cultures from the font are all unique, so inserting a duplicate value crashes.

The result of this bug is that any WPF 4 application that tries to enumerate the system fonts and get their names will crash. The most common font that causes this bug appears to be "DiagramTTBlindAll", a symbol font installed with ChessBase 11.

Although new to us, this is not a new bug. It was reported against Expression Blend in March 2010, and identified as a WPF bug. In February 2012, it was re-reported against the WPF designer in Visual Studio 2010. At that point a Connect issue already existed (but is unavailable now).

Microsoft, we love WPF, but the fact that simple bugs go unfixed for 30 months is frustrating. I know that open sourcing WPF would be much more complex than open sourcing ASP.NET (due to the unmanaged milcore portion and the deployment considerations), but if you put WPF on CodePlex, I'll submit a pull request with a fix the very next day. :-)

Meanwhile, if you're a WPF 4.5 developer, here's a workaround for the crash. Use FontUtility.GetSystemFontFamilies() instead of Fonts.SystemFontFamilies if you will be accessing the names of the returned fonts.

/// <summary>
/// Provides utility methods for fonts.
/// </summary>
public static class FontUtility
{
    /// <summary>
    /// Gets the system font families.
    /// </summary>
    /// <returns>A collection of system font families.</returns>
    public static ReadOnlyCollection<FontFamily> GetSystemFontFamilies()
    {
        List<FontFamily> systemFontFamilies = new List<FontFamily>();
        foreach (FontFamily fontFamily in Fonts.SystemFontFamilies)
        {
            try
            {
                // trigger the exception
                var unused = fontFamily.FamilyNames;

                // add the font if it didn't throw
                systemFontFamilies.Add(fontFamily);
            }
            catch (ArgumentException)
            {
                // certain fonts cause WPF 4 to throw an exception when the FamilyNames property is accessed; ignore them
            }
        }

        return systemFontFamilies.AsReadOnly();
    }
}

Always wrap GZipStream with BufferedStream

2012-06-08T21:55:00-07:00

GZipStream and DeflateStream don't buffer their input, so they will only compress the individual chunks that are passed to Write (or, worst-case, WriteByte). Unless you can guarantee that large blocks of data are being passed to GZipStream.Write, always wrap GZipStream in a BufferedStream when using CompressionMode.Compress.

In fact, if you call only WriteByte on a compressing GZipStream, it will create “compressed” output that's almost double the size of the input.

Experimentation determined that the optimal buffer size is 8K; above this, no further compression is gained. So, to create a GZipStream, use a method similar to the following:

public static Stream CreateCompressingGZipStream(Stream stream, bool leaveOpen)
{
    return new BufferedStream(
        new GZipStream(stream, CompressionMode.Compress, leaveOpen),
        8192);
}

This chart shows how the compressed output keeps getting smaller as the buffer size increases (and how writing just one or two bytes at a time almost doubles the 1MB input):

// determine best buffer size
foreach (int bufferSize in new[] { 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 1536,
    2048, 4096, 6144, 8192, 16384, 32768, 65536, 131072, 262144 })
{
    using (MemoryStream output = new MemoryStream())
    {
        using (GZipStream compressor = new GZipStream(output, CompressionMode.Compress,
            leaveOpen : true))
        using (BufferedStream buffer = new BufferedStream(compressor, bufferSize))
        {
            // write simple data that will compress easily
            for (int i = 0; i < 1000000; i++)
                buffer.WriteByte(0);
        }

        Console.WriteLine("Buffer Size: {0:n0}, Compressed size: {1:n0}",
            bufferSize, output.Length);
    }
}

Run MbUnit v2 tests under .NET 4

2012-05-01T07:30:00-07:00

We still use MbUnit v2 for some of our assemblies, primarily because the items mentioned in the migration guide still haven't been implemented in MbUnit v3, and we haven't taken the time to port the tests to NUnit.

I wanted to compile our code for .NET 4 and still run all the existing tests against it.

The test runner (MbUnit.Cons.exe) is a .NET 1.1 app, so by default it will fail to load a .NET 4 test assembly. You can use the <supportedRuntime> configuration element to force the program to run under .NET 4, but it still fails to load the test assembly.

The message printed at the console isn't helpful, but if you debug the test runner, the following exception occurs:

NotSupportedException: This method implicitly uses CAS
policy, which has been obsoleted by the .NET Framework.
In order to enable CAS policy for compatibility reasons,
please use the NetFx40_LegacySecurityPolicy configuration
switch.
Please see http://go.microsoft.com/fwlink/?LinkID=155570
for more information.

This occurs because MbUnit uses the obsolete Assembly.Load(string, Evidence) method. To fix this, add the NetFx40_LegacySecurityPolicy configuration element, as instructed by the exception message.

Ultimately, your MbUnit.Cons.exe.config file should look as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration> 
  <runtime>
    <!-- Don't kill application on first uncaught exception. -->
    <legacyUnhandledExceptionPolicy enabled="1" />

    <!-- Use legacy CAS policy so MbUnit's assembly loading succeeds. -->
    <NetFx40_LegacySecurityPolicy enabled="true"/>
  </runtime>

  <!-- Force use of .NET 4. -->
  <startup>
    <supportedRuntime version="v4.0" />
  </startup> 
</configuration>

With this new configuration, MbUnit can successfully run under .NET 4 and load .NET 4 assemblies. However, it still runs as a 32-bit process, so "Any CPU" test assemblies will get loaded as 32-bit. To make it run as 64-bit, you can use the CorFlags utility. As per the StackOverflow wiki, an "Any CPU" application should be a PE32 executable with the 32BIT flag cleared.

To change MbUnit to an "Any CPU" executable (so it runs as 64-bit on an x64 system), run:

CorFlags /UpgradeCLRHeader /32BIT- MbUnit.Cons.exe

Persistent Hash Codes

2012-02-23T06:32:00-08:00

What does "hello".GetHashCode() return?

The answer is: it depends.

Under the Microsoft .NET 4 CLR, that method returns 0xFFF561E1 in a 32-bit application, but 0xEC7BF82A in a 64-bit build. Other runtimes, such as Mono and the Compact Framework, might return other values.

As per the documentation, “The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. … The value returned by GetHashCode is platform-dependent. It differs on the 32-bit and 64-bit versions of the .NET Framework.”

In certain scenarios (e.g., saving a hash code to a file, or creating a hash code on a 32-bit client and using it on a 64-bit server), it's useful to have an algorithm that will always generate the same hash code for the same input.

Based on Paul Hsieh‘s SuperFastHash, Bob Jenkin‘s hash function, and Thomas Wang‘s Integer Hash Function, we developed HashCodeUtility.GetPersistentHashCode. (The C# methods are basically a straightforward port of the corresponding C functions.)

These methods perform a thorough mixing of their input (so the return value works well as a key in a hashtable), have good performance, and will always return the same result no matter what version of the CLR they're running on.

The source is available on GitHub: HashCodeUtility.cs, HashCodeUtilityTests.cs.

For information about the CombineHashCodes method in those files, see my earlier post, Creating hash codes.

Ascii85 implementation in C#

2012-02-18T11:25:00-08:00

Ascii85 is an encoding scheme that converts 4 bytes into 5 ASCII characters (in the range ! through u). As a result, it only has 25% encoding overhead compared to the 33% of Base64.

I recently needed to smuggle some binary data through HTTP headers without exceeding the message length limit; Ascii85 seemed like the best choice.

There were a couple of implementations available on the bathroom wall of code, but they had various problems that precluded their use:

No tests
Few comments
Unknown license
Violated .NET Framework Design Guidelines
NIH

So I wrote my own. The code is available on GitHub: Ascii85.cs, Ascii85Tests.cs

As with the other code on this blog, it's released under a MIT-style license.

WebException: "The message length limit was exceeded"

2012-01-04T13:04:00-08:00

An uncommon WebException thrown by HttpWebRequest.GetResponse() has the message "The underlying connection was closed: The message length limit was exceeded."

By default, HttpWebResponse only allows 64KB of HTTP headers; any more and it will throw this exception.

To resolve the issue, set the MaximumResponseHeadersLength property on the request to a larger value, or to -1 for no limit. (Note that the value is expressed in kilobytes, so the default value 64 allows 65,536 bytes of headers.)

Avoid System.Windows.Rect.ToString()

2012-01-02T12:03:00-08:00

System.Windows.Rect.ToString() is documented as returning a string in “the following form: "X,Y,Width,Height"”.

It seems like this method is the complement to the Parse method, which accepts the “string representation of the rectangle, in the form "x, y, width, height"”.

Unfortunately, while Parse is culture-invariant (as documented), ToString follows the .NET convention of returning locale-sensitive results; you need to call the ToString(IFormatProvider) overload to produce a string in the "x,y,width,height" format (that can be accepted by Parse).

    Rect rect = new Rect(1.5, 2, 3.5, 4);
    string s;

    s = rect.ToString(); // "1.5,2,3.5,4"
    Rect.Parse(s); // success

    Thread.CurrentThread.CurrentCulture = new CultureInfo("de"); // or "es", "fr", etc.

    s = rect.ToString(); // "1,5;2;3,5;4"
    Rect.Parse(s); // throws FormatException

    s = rect.ToString(CultureInfo.InvariantCulture);
    Rect.Parse(s); // success

I filed a bug report, even though this is arguably an error in the documentation, not in the .NET Framework itself.

Printing from .NET 3.5 in Windows 7

2011-12-30T16:01:00-08:00

Our users discovered a curious bug that appears to be caused by:

Printing an XpsDocument
that uses a font embedded in the application's resources
from a .NET 3.5 application
running on Windows 7

The printed output looks like the following image; various glyphs are substituted with larger sans-serif versions of themselves, causing a ransom-note-like appearance.

We found that changing any one of the conditions above fixes the problem, but unfortunately we need to print XPS using an embedded font, we're still using .NET 3.5, and we have to run on Windows 7.

Strangely enough, printing to the XPS Document Writer print driver, and then printing that document with the XPS Viewer built into Windows 7 doesn't reproduce the problem; it only happens when our app prints directly to an actual printer.

Workaround

I noticed that the XPS Viewer is a native application; this led me to discover the Windows 7 XPS Print API. In conjunction with the (also new in Windows 7) XPS Document API, this lets you print XPS documents from native code.

We were able to solve the problem by automating the workaround described above: our code writes its output to an XpsDocumentWriter backed by a temporary file (instead of a PrintQueue); we then use the native APIs to print the temporary XPS file to the currently-selected printer.

The first part is to define the native methods and COM interfaces we will need. (And, as noted in this StackOverflow question, the IXpsPrintJobStream interface is either declared or implemented incorrectly, so we have to call the Close method as if it existed on ISequentialStream.)

With those declared, the printing code can be written. This method (which should be called on a background thread), prints a XPS file to a specific printer, returning true if printing succeeded. (If it fails, the application should fall back to the .NET printing APIs.)

All the code below is also available in a gist.

    internal static class NativeMethods
    {
        [DllImport("XpsPrint.dll", ExactSpelling = true, CharSet = CharSet.Unicode)]
        public static extern int StartXpsPrintJob(string printerName, string jobName, string outputFileName, IntPtr progressEvent,
        SafeWaitHandle completionEvent, [MarshalAs(UnmanagedType.LPArray)] byte[] printablePagesOn, int printablePagesOnCount,
        out IXpsPrintJob xpsPrintJob, out IXpsPrintJobStream documentStream, out IXpsPrintJobStream printTicketStream);
    }

    [ComImport, Guid("E974D26D-3D9B-4D47-88CC-3872F2DC3585"), ClassInterface(ClassInterfaceType.None)]
    internal class XpsOMObjectFactory
    {
    }

    [ComImport, Guid("F9B2A685-A50D-4FC2-B764-B56E093EA0CA"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    internal interface IXpsOMObjectFactory
    {
        void CreatePackage();

        [return: MarshalAs(UnmanagedType.Interface)]
        IXpsOMPackage CreatePackageFromFile([MarshalAs(UnmanagedType.LPWStr)] string filename, bool reuseObjects);

        void CreatePackageFromStream();
        void CreateStoryFragmentsResource();
        void CreateDocumentStructureResource();
        void CreateSignatureBlockResource();
        void CreateRemoteDictionaryResource();
        void CreateRemoteDictionaryResourceFromStream();
        void CreatePartResources();
        void CreateDocumentSequence();
        void CreateDocument();
        void CreatePageReference();
        void CreatePage();
        void CreatePageFromStream();
        void CreateCanvas();
        void CreateGlyphs();
        void CreatePath();
        void CreateGeometry();
        void CreateGeometryFigure();
        void CreateMatrixTransform();
        void CreateSolidColorBrush();
        void CreateColorProfileResource();
        void CreateImageBrush();
        void CreateVisualBrush();
        void CreateImageResource();
        void CreatePrintTicketResource();
        void CreateFontResource();
        void CreateGradientStop();
        void CreateLinearGradientBrush();
        void CreateRadialGradientBrush();
        void CreateCoreProperties();
        void CreateDictionary();
        void CreatePartUriCollection();
        void CreatePackageWriterOnFile();
        void CreatePackageWriterOnStream();
        void CreatePartUri();
        void CreateReadOnlyStreamOnFile();
    }

    [ComImport, Guid("18C3DF65-81E1-4674-91DC-FC452F5A416F"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    internal interface IXpsOMPackage
    {
        void GetDocumentSequence();
        void SetDocumentSequence();
        void GetCoreProperties();
        void SetCoreProperties();
        void GetDiscardControlPartName();
        void SetDiscardControlPartName();
        void GetThumbnailResource();
        void SetThumbnailResource();
        void WriteToFile();

        void WriteToStream(IXpsPrintJobStream stream, bool optimizeMarkupSize);
    };

    // NOTE: It appears that the IID for IXpsPrintJobStream specified in XpsPrint.h --  
    // MIDL_INTERFACE("7a77dc5f-45d6-4dff-9307-d8cb846347ca") -- is not correct, or the object
    // doesn't implement QueryInterface correctly. However, we can QI for ISequentialStream and
    // successfully (at least in Windows 7 SP1 x86) call the Close method as if it existed on that
    // interface.
    // That is, we obtain the ISequentialStream interface, but work with it as the IXpsPrintJobStream interface.
    // Thanks to http://stackoverflow.com/questions/6123507/xps-printing-from-windows-service for this tip.
    [ComImport, Guid("0C733A30-2A1C-11CE-ADE5-00AA0044773D"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    internal interface IXpsPrintJobStream
    {
        // ISequentialStream methods
        void Read([MarshalAs(UnmanagedType.LPArray)] byte[] pv, uint cb, out uint pcbRead);
        void Write([MarshalAs(UnmanagedType.LPArray)] byte[] pv, uint cb, out uint pcbWritten);

        // IXpsPrintJobStream methods
        void Close();
    }

    [ComImport, Guid("5AB89B06-8194-425F-AB3B-D7A96E350161"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    internal interface IXpsPrintJob
    {
        void Cancel();
        IntPtr GetJobStatus();
    };

    /// <summary>
    /// Prints the specified XPS document to a printer using the native XPS Print API.
    /// </summary>
    /// <param name="xpsFilePath">The path to the XPS document.</param>
    /// <param name="printerName">The printer name.</param>
    /// <param name="printTicket">A PrintTicket with settings for this print job.</param>
    /// <returns><c>true</c> if the document was successfully printed; otherwise, <c>false</c>.</returns>
    /// <remarks>This method should be called from a background thread.</remarks>
    public bool Print(string xpsFilePath, string printerName, PrintTicket printTicket)
    {
        // try to create the XPS Object Model factory (only available on Windows 7 and Vista with the Platform Update)
        IXpsOMObjectFactory xpsFactory = null;
        try
        {
            xpsFactory = (IXpsOMObjectFactory)new XpsOMObjectFactory();
        }
        catch (COMException)
        {
            // OS doesn't support the XPS Document API
            return false;
        }

        bool success = false;
        IXpsOMPackage package = null;

        try
        {
            // load the saved document as a native XpsOMPackage
            package = xpsFactory.CreatePackageFromFile(xpsFilePath, false);

            using (ManualResetEvent handle = new ManualResetEvent(false))
            {
                // attempt to start the print job
                IXpsPrintJob printJob;
                IXpsPrintJobStream docStream, ticketStream;
                int hresult = NativeMethods.StartXpsPrintJob(printerName, jobTitle, null, IntPtr.Zero, handle.SafeWaitHandle,
                    null, 0, out printJob, out docStream, out ticketStream);

                // check for success (NOTE: checking HRESULT value directly instead of calling Marshal.ThrowExceptionForHR
                //   to avoid proliferation of 'catch' blocks)
                if (hresult >= 0)
                {
                    // write the current printer settings to the print ticket stream
                    byte[] ticketData = printTicket.GetXmlStream().ToArray();
                    uint bytesWritten;
                    ticketStream.Write(ticketData, (uint)ticketData.Length, out bytesWritten);
                    ticketStream.Close();

                    // write the XPS package to the document stream
                    package.WriteToStream(docStream, false);
                    docStream.Close();

                    // wait for printing to finish
                    handle.WaitOne();
                    success = true;
                }
            }
        }
        catch (COMException)
        {
            // printing failed
        }
        catch (DllNotFoundException)
        {
            // OS doesn't support XPS Print API
        }
        catch (EntryPointNotFoundException)
        {
            // OS doesn't support XPS Print API
        }

        // force the XPS package to be released, so that the temporary file can be deleted
        if (package != null)
            Marshal.FinalReleaseComObject(package);

        return success;
    }