Twitter Updates

Twitter Updates

    follow me on Twitter

    Entries in .net (2)


    Server-Side Office Document Generation Bug

    One of my current projects includes the capability of generating what can be very large Word 2007 documents. The size of the document is mostly driven by embedded Word, PDF and image files, with the business requirement of handling file sizes up to 150MB. We're using the Microsoft SDK for OpenXML Formats for generating these files, and all was well with the world, until we started testing large files on the server. Once we got to file sizes around 10MB, strange exceptions started showing up in the logs and the generation operation began failing when calling OpenXmlPart.FeedData():

    System.ObjectDisposedException: Can not access a closed Stream.

    This was particularly frustrating since the operation worked fine on local development machines, but failed miserably when deployed to the Windows Server 2003 development environment, and again, only when the file size of the documents being embedded got around 10MB+. After a lot of log4net debugging, strategically placed try/catch blocks, and a whole lot of Reflector spelunking, I was finally able to sort out what was actually going on, and it seems to be a bug in the .NET Framework.

    Why me?!

    The OpenXML SDK uses System.IO.Packaging for various operations and Packaging then uses the MS.Internal.IO.Packaging.SparseMemoryStream for various stream operations. This class is meant to use MemoryStreams for small files, and then switch to an IsolatedStorageFile stream for large files. I discovered this by putting a try/catch block directly around the call to OpenXmlPart.FeedData(), resulting in this error:

    Unable to open the store. (Exception from HRESULT: 0x80131460) System.IO.IsolatedStorage.IsolatedStorageException: Unable to open the store. (Exception from HRESULT: 0x80131460) at System.IO.IsolatedStorage.IsolatedStorageFile.nOpen(String infoFile, String syncName) at System.IO.IsolatedStorage.IsolatedStorageFile.Lock() at System.IO.IsolatedStorage.IsolatedStorageFileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, IsolatedStorageFile isf) at MS.Internal.IO.Packaging.PackagingUtilities.SafeIsolatedStorageFileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, ReliableIsolatedStorageFileFolder folder) at MS.Internal.IO.Packaging.PackagingUtilities. CreateUserScopedIsolatedStorageFileStreamWithRandomName(Int32 retryCount, String& fileName) at MS.Internal.IO.Packaging.SparseMemoryStream.SwitchModeIfNecessary() ...

    As we can see from the error, the application was failing when attempting to open the IsolatedStorageFile stream after SparseMemoryStream switched modes. It's important to highlight again that SparseMemoryStream only switches to IsolatedStorageFile-based streams when files being processed are large (~10MB, but I'm not sure on the exact size). This explains why everything worked fine on the server and developer machines when files were small.

    Now we've got the issue of why large files worked on developer machines, but not on the server. This seems to be caused by the type of IsolatedStorageFile being instantiated by SparseMemoryStream through the use of the MS.Internal.IO.PackagingUtilities+ReliableIsolatedStorageFileFolder.ctor and it's corresponding call to MS.Internal.IO.Packaging.PackagingUtilities.UserHasProfile() to decide between a user- or machine-scoped IsolatedStorageFile. On a local developer machine, applications are commonly executing under the developer's account, so a user-scoped IsolatedStorageFile is instantiated and everything works fine. On Windows Server, however, ASP.NET applications are typically running as Network Service, and a user-scoped IsolatedStorageFile does not work for this account.

    Unfortunately, the MS.Internal.IO.Packaging.PackagingUtilities.UserHasProfile() method checks the registry for the existence of a user profile node in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and Network Service does, in fact, have a profile in the registry. This means that the .NET Framework is selecting a user-scoped IsolatedStorageFile and failing due to permissions (a machine-scoped IS would work fine).

    Having finally understood what exactly was going on, I then set out to discuss the issue with some Microsoft contacts and verify that this is an issue in the framework (it is) and put together a sample application to more fully describe the issue to them. It may be easier to understand by looking at that sample, so you can check that out as well. The last word I've gotten back from Microsoft is that this issue will be resolved in future releases of the framework, but there wouldn't be any hotfixes in the short-term.

    Any solutions?

    While understanding what exactly was going on was a pain, we still had to find a solution to the problem. Luckily, another developer on the team had the bright idea of simply impersonating a user that doesn't have a profile in the registry at the time of document generation. While this isn't an ideal solution, it is an effective work-around for the problem. Since the impersonated user doesn't have a profile in the registry, the machine-scoped IsolatedStorageFile is instantiated and everything works fine.

    Whew . . . I've got to admit that this was one of the most fun issues I've come across in my short career. That said, I'm still glad it's over!


    JS IntelliSense with Namespaces in VS 2008

    When ASP.NET AJAX came out and my interest in the UpdatePanel had waned, I really dug into the client-side library. I'd never gone very deep into JavaScript until then, so the structure of the library was intriguing and, over time, became a pattern that I began adopting in my own work.

    A corner-stone to this structure is partitioning your JavaScript into namespaces (using Type.registerNamespace), which are split up in a manner similar to .NET itself, and also avoid naming conflicts with third-party components and non-global page functions.

    Of course, with my increased adoption of JavaScript, I was excited to hear of JavaScript IntelliSense support in VS2008. I had assumed that namespace support for IntelliSense would work as expected, since so much of the ASP.NET AJAX library uses it and that I would soon be reveling in all the contextual help provided by my diligent use of JavaScript doc comments. After converting my current project to VS2008, I was confused by the seemingly utter lack of IntelliSense when using namespaces. So, as with most things that confuse me, I searched around on the 'net to see if anybody else had solved this problem. To my chagrin, I found a disturbing post stating that a bug had been submitted to Microsoft for this issue, and that the response was, effectively, that the namespace pattern would not be supported in VS2008.

    Dejected, I continued on with my project, having conceded that my namespaced script wouldn't be quite as easy to work with as I had hoped. It wasn't long, however, that I noticed that the namespaces worked properly when they were defined in a different file from the active document, which is the expected behavior as stated in the Microsoft Feedback report. In fact, this is the same functionality that provides us with IntelliSense for the ASP.NET AJAX client-side framework itself.

    Add all of this together and you can, in fact, get JavaScript IntelliSense for script that uses namespaces (through Type.registerNamespace) by doing a few tricks within your application. Read on for more details.

    Step 1: Add a Namespace definition file

    Since any Type.registerNamespace calls in the active document aren't parsed, we need to add a new file to the project for storing namespace registration calls. This file is also the root JS file that will reference the MircrosoftAjax.js file for client-side library IntelliSense support. For the example, we'll refer to this as SampleApp-Namespaces.js:

    /// <reference name="MicrosoftAjax.js" />

    Step 2: Reference this Namespace definition file

    In order to get proper IntelliSense support in the files where we would normally define namespaces and then use them, we now need to reference this namespace definition file. It's important to point out that nothing else in this your existing JavaScript code has to change. The Type.registerNamespace() call does nothing if the namespace already exists, so you can (and should, more later) leave your standard Type.registerNamespace() calls alongside the object definitions they correspond to. Here's what SampleApp-Core.js might look like:

    /// <reference path="~/Scripts/SampleApp-Namespaces.js" />

    * Coderoni.JsSampleApp.Utility.RandomGenerator
    Coderoni.JsSampleApp.Utility._RandomGenerator = function()
    /// <summary>
    /// Provides convenience utility methods for generating random values.
    /// </summary>

    Coderoni.JsSampleApp.Utility._RandomGenerator.prototype =
    generateRandomString: function(length)
    /// <summary>
    /// Generates a random string of the specified length.
    /// </summary>
    /// <param name="length" integer="true" optional="false">
    /// Length of the string to generate.
    /// </param>
    /// <returns type="String">
    /// Randomly generated string of the specified length.
    /// </returns>
    var chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
    var randomString = "";

    for (var i = 0; i < length; i++)
    var randomNum = Math.floor(Math.random() * chars.length);
    randomString += chars.substring(randomNum, randomNum + 1);
    return randomString;
    Coderoni.JsSampleApp.Utility.RandomGenerator =
    new Coderoni.JsSampleApp.Utility._RandomGenerator();

    The important parts of this code is the call to registerNamespace() with the same namespace information as that found in SampleApp-Namespaces.js. After making the reference to the namespace file, you should find that your namespaces appear and work as expected in IntelliSense. This is because the parser that analyzes references does realize that registerNamespace() creates objects, and therefore, everything works.

    Step 3: Don't reference the namespace definition

    Of course, we all know that the fewer requests the browser needs to send when loading a page, the better off our users are, so adding a JavaScript file to the application for design-time IntelliSense is not a smart move. Fortunately, the work-around relies on the reference hints you give to Visual Studio in JS comments, so you shouldn't add a script link to the namespace definition file within your application; it's simply not necessary. This is also the reason you leave the duplicate registerNamespace() calls in the SampleApp-Core.js file; these calls are the ones that actually register your namespaces at runtime.

    <asp:ScriptManager runat="server" ID="ScriptManager">
    <asp:ScriptReference Path="~/Scripts/SampleApp-Core.js" />
    <asp:ScriptReference Path="~/Scripts/Default-Script.js" />

    Everything also works right if you reference the objects defined in SampleApp-Core.js from a third script file, such as Default-Script.js:

    /// <reference path="~/Scripts/SampleApp-Core.js" />

    function ShowRandomString()
    str = Coderoni.JsSampleApp.Utility.RandomGenerator.generateRandomString(10);
    element = $get("MessageDiv");
    element.innerHTML = str;

    Again, this is because the multiple calls to registerNamespace() do nothing if the namespace already exists.

    Summing Up

    While it's not the prettiest work-around that ever existed, it's relatively painless and allows those of us that have adopted the namespace structure in their JavaScript to enjoy the many benefits of VS-based IntelliSense. Hopefully a future release or update for VS will allow the parsers to work without this extra bit of effort, but until then, at least it's possible with just a bit of extra code and no real impact on your application. Now all those JavaScript doc comments weren't a complete waste of time after all.