An msi is really a relational database made up of a number of tables. When an installation runs the windows installer parses the msi and then queries tables to see what actions it must perform. Msdn has a complete list of tables that the windows installer uses and it’s very worth while checking it out because it will give you a good idea of what you’re install is going to do and why.   If you use certain wix elements you may notice they create tables that are not listed in the msdn documentation. This...

On the 10th September a new version of wix was released. This included two library files that would add the necessary elements to you’re wix file to drive the custom actions. This means creating a new user now works correctly. I’ve even tested adding the user to a group seems to work okay, although I am little cynical to whether this will work on a machine set up in a foreign language as the name of well know groups varies here. I will be testing this when I return to Denmark on tomorrow.

  A couple of days ago I was reading a post about dynamic languages (scripting languages with good PR) on lambda the ultimate. The author wrote “’strong’ typing is not the same as ‘explicit typing’”, which is very true and got me thinking about inferred type system, such as the one F# uses.   The big advantages is that doesn’t seem to be talked about much is that because in inferred type you don’t explicitly say what type an identifier is you get a lot more choice about what you compile it down to. This is...

If you have had a look at the documentation you’ve probably noticed a few elements like “ServiceInstall”, “User” and “WebVirtualDir”. What these elements all have in common is that if you add them to a wix document they will compile and link with out any problem, but they will not do anything at all on installation. If you take a closer at the msi produced using the reason they do nothing becomes clear, for example the User elements generates a table called user in the Msi and if you read the windows installer documentation you will quickly see there is...

I’ve always been interested in the inner workings of ASP.NET, and with ASP.NET 2.0 coming out along with a new version of F# I decided I’d have a better stab at creating some kind of support of ASP.NET in F#.   To create a page the framework compiles the aspx source into a .NET type that derives from System.Web.UI.Page. In the frameworks version 1.0 and 1.1 the API that did the compilation of ASP.NET pages was very closed. Most of the classes in them were declared as internal. Sure the model was extensible you control...