Doug King

Updating the GAC...

  • Authoring .NET shareware programs - tackling the framework redist problem

    It looks like the Thinstall installer will solve several problems that I am facing as a .NET shareware author. (Disclaimer: by mentioning Thinstaller in my blog I eligible for a discount on the purchase)

    The biggest issue for me regarding .NET shareware, is distribution of the proper version of the .NET framework to users that don't have it. The other issues I am facing are obfuscation, licensing (trail timeouts, etc.) and installer packaging.

    For a shareware product, you don't want to raise any barriers that will hinder the customer or give a bad first impression. If you require that users download the .NET framework as a separate download, you are going to loose them. Thinstall bundles the necessary framework assemblies into a single .exe along with your program assemblies. So the user downloads one .exe and runs it. This single .exe should run on all Windows platforms (95, 98, ME, XP, 2K, 2003). The .NET framework bits are not installed on the users machine, just unpacked and made available to your program upon execution, and then deallocated when the the app closes.

    From what I understand, Thinstall links it's own loader/Virtual Operating System into the packaged executable. This loader unpacks the assemblies from the .exe at runtime, builds a virtual file system for the assemblies to live in and then calls your application. The VOS occupies about 90k of disk space and around 1MB of memory while running depending on which components are loaded. Once the VOS has been loaded it will load an EXE from the package archive into the same process. The user never has access to any of the unpacked virtual files and they are not visible from explorer and can't be disassembled. However, you have the option to make any of your files non-virtual and visible so you can allow the user to manage settings files, etc.

    I was worried that because everything is embedded into one .exe you could not use reflection to implement 'smart client'/application updater/plug-in techniques. I did some quick experiments and was able to demonstrate that you could dynamically update parts of you application by pushing down new assemblies. The Thinstall VOS overlays it's virtual file system on top of the local file system so that the unpacked invisible virtual files share the physical directory that contains any local files, which are visible in explorer. What happens if there are two files (one local, one virtual) with the same path and name? You have the option to set up the VOS (via an installer switch) to use the local file (if it exists) instead of the virtual file. This allows your app to download updated assemblies, config files, plug-ins, etc.

    Thinstaller also handles obfuscation, licensing and installer packaging. There are a few drawbacks, the main one being the finished package size and the runtime memory requirements. Remember, if your are including an instance of the .NET framework assemblies in your finished .exe it will increases the size of the final product. For small utility apps, this might be a serious drawback. But for major applications, your customers are going to expect a medium to large download and .exe memory footprint. For these larger apps, the overhead of the Thinstaller VOS becomes an acceptable percentage of the overall size.

    All-in-all a nice tool that solves several problems, especially the .NET framework redistribution faced by .NET shareware authors.

    I would be interested in hearing from any other users of Thinstall, especially their experiences with .NET shareware distribution.


  • Code generation with NANT and IIS/ASPX

    Recently I have been experimenting with a simple technique for code generation that has a lot of power and flexibility. I use NANT to intelligently drive the rendering of code. This is accomplished via HTTP GET of web pages or via XSLT transforms from an NANT task. The ASP.NET web pages are written to transform metadata (database schema, UML model, O/R mapping, UI descriptions, etc.) into source code plain-text in the same way that you would render HTML from data in an ordinary web application.

    The advantages of this approach are:

    • Known technology lowers the barriers to acceptance by management and other programmers. IIS/ASP is a known factor that does not need to be explained and researched.

    • Using a build tool such as NANT is a good practice and should also be well accepted as a familiar technology and process.

    • The technique for building the code generation templates (ASPX pages) is familiar to a programmer. You will be using the same toolset as you do today, so the process is mature and low risk. You get to use a million dollar IDE (Visual Studio) to build and debug your templates, as opposed to a simple template editor or proprietary wizard environment that ships with many code generators.

    NANT has many useful commands that assist in managing code generation. This is key, because generation of output files is only half the battle. Management of templates, dependencies, configurations, metadata files, and source control integration are major issues in making code generation a success on any non-trivial project. NANT has facilities for source control integration, unit testing integration, CRC/Hash generation and comparison (useful for ensuring generated code does not get modified), XML manipulation via Xpath and XSLT, logging and more. The key command that allows us to use NANT for generation with IIS/ASPX is the HTTP GET command. For a list of all the NANT commands look here and here.

    Using this open ended toolset is in contrast to many code generators on the market today that are proprietary, closed and require some education, acceptance and a certain amount of faith in the vendors framework and worldview. The value of this shouldn’t be underestimated. Some of the most serious problems hindering code generation acceptance are the barriers imposed by closed, proprietary systems that have little flexibility, minimal documentation and tribal knowledge. ASPX and IIS together are extremely flexible and robust, incredibly well documented and there is a glut of tribal knowledge and source code out there.

    In part II I will describe some of the details of how I implement this method, with some tips and discussion of trade-offs in various approaches.


  • Rock, Paper, Scissors, Flash, Sparkle: Rumors of Flash killer to ship with Longhorn/Avalon

    According to this article at Microsoft is working on a tool set that will allow developers to build Flash-like applications built on top of the Avalon subsystem.

    Code-named "Sparkle," the tools under development would be integrated with Microsoft's .NET  runtime environment. That would ultimately mean developers could have Flash- and Director-like animation and graphics tools ready-built for them soon after Longhorn hits the marketplace.

    One source familiar with the project, who saw examples of the "Sparkle" toolset integrated with Microsoft's C#, said early prototypes have given rise to talk of its potential as a "Flashkiller" or even a "Director-killer," referring to Macromedia's popular Flash animation software and Director tool, which is best known for building small animations for CDs.

    I didn't make it to PDC, but did anyone hear about this? I don't see any posts on or