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.