add simple and MSI-based installers, add support for using F# CodeDom through CreateProvider, and more

[drvink]

There are a lot of changes; here is a summary of what's included:

• An installutil.exe-compatible installer, suitable for use with either .NET (works) or Mono (untested, but should work)
• A simple MSI-based installer (works, but using MSI to install assemblies to the GAC is a little tricky because MSI has no way of making an "AnyCPU" package--you must specify an architecture, so we default to x86, which works fine on x64 systems too)
• If the module is installed using either of the above installers, support for using the module through CodeDomProvider.CreateProvider will work. This allows for libraries to support generating F# code without having to hard-code a dependency on the module (it becomes possible to do CodeDomProvider.CreateProvider("f#")--in fact this is the correct way to use CodeDom but it seems most people get this wrong and hard-code choices of only C# and VB; even Microsoft gets it wrong in the WPF build system and the T4 template engine!)
• Support for emitting assembly attributes via the F# CodeDom provider
• An alternate implementation of CodeCompiler.fs that uses Microsoft.FSharp.Compiler (it is slower than the existing implementation and requires FSharp.Compiler.Service so I did not replace the existing implementation; merely it is offered as a working example because for many invocations/compilation units, it ought to be faster than the current implementation because it doesn't fork fsc/fsharpc each time)
• Some optimizations/style cleanups (mostly changing length checks and use of head/tail to pattern matches)
• Cleaning up some unnecessary space bar holding :)

[dsyme]

Hi @drvink

That's a lot of work! Could you elaborate on the scenarios where the machine-wide install is needed? I understand that many original uses of CodeDom do rely on a machine-wide install - I'm curious as to which particular use was driving you in this direction. There's a pretty strong trend away from machine-wide install of components, MSI installers etc. towards nuget packages and I'd like to understand what the future looks like for this.

I'll take a closer look at the code too.

thanks
don

[drvink]

Hi Don,

CodeDom is designed such that programs making use of it need not, and ideally should not, hard-code a list of acceptable target languages, i.e. it should be enough that a CodeDom provider is installed for a given language because programs should simply call System.CodeDom.Compiler.CodeDomProvider.CreateProvider(lang) instead of explicitly loading or referencing the assembly of a specific provider. Unfortunately, in order for this mechanism to work, providers must be registered in the .NET runtime's machine.config file, hence the machine-wide install--but afterwards, anything that (correctly :)) uses CodeDom can emit F# code! If installation is not desired or possible, the provider can still be used through e.g. a NuGet package, but the language-neutral aspect of CodeDom output language selection won't work.

I did this work because I wanted to allow for better support of F# within Visual Studio in general. One thing that will work right now if you install the provider is that you can embed F# instead of C# for MSBuild inline tasks. Installing the provider could also potentially enable F# support for T4 (the text template/macro system) or better integration of F# with WPF (the WPF build system uses CodeDom in places), though unfortunately right now both of those hard-code support for only the C# and VB CodeDom providers.

Cheers,
Mark Laws

[dsyme]

OK, I see.

I think this is the first new MSI installer I've seen for a very, very long time. It's a shame you can't "install" the CodeDom into a solution via a nuget package or VS addin - the machine-wide model is really problematic these days. What if the MSBuild stuff gets used on a build server like AppVeyor, for example? You'd have to install the MSI there too.

I don't really know what the solution is. However, because the MSI installer is somehow "old-school" (even if it's the only way to do things) I wonder if the MSI installer should be in a separate repo. Also we should consider where/how/who would publish the MSI installer.

[drvink]

You reminded me of an important issue: since the provider gets installed to the GAC, it has to go through the usual strong name dance (i.e. signing), which means there needs to be some sort of procedure for publishing the MSI installer. We could just punt on this and let people make their own key + build their own installer unless there's sufficient demand, though having a more polished product seems preferable if possible.

[drvink]

Once you're able to get it installed, you can try this to confirm it works: https://gist.github.com/drvink/37782838e3611b5b7a83

[dsyme]

It looks a little odd to use "static let" though is valid - I think just make them "let"

[dsyme]

I'm happy to integrate this - can you follow up with the minor changes mentioned above?

For building and publishing the MSI I recommend using GitHub releases pages in this project for now? I don't use those but @forki or the interwebs should provide the info you need

[dsyme]

Great work BTW

[dsyme]

For strong name signing, I suggest just signing with https://github.com/fsharp/fsharp/blob/master/src/fsharp/test.snk or the standard mono.snk for now.

[drvink]

Should I just copy the key from that repo and add it to this one?

[dsyme]

Yes, sure