Sunday, October 30, 2011

Calling F# Libraries from Metro Style Apps

This weekend, I finally got around to trying to build a polyglot Metro style app (C# front-end + F# back-end). This post will talk about the project file changes that were required and the one outstanding issue that I'm still working. Additionally, a VSIX package is provided that provides the F# Metro Library project template as it exists today.

Note: This approach has only been tested with the simplest of examples.

Getting Setup:

1. In order to create a Metro style app, you need to install Windows 8 Developer Preview with Developer Tools.
2. To also have F#, you'll then need to install Visual Studio 11 Developer Preview.
3. Now create a new C# Windows Metro style application (I chose the Application template).

Adding F#:

If you have installed the VSIX that is linked at the bottom of this post, you can simply add the F# Metro Library, write some code, wire it up, and test. If not, you'll need to add a standard F# Library project and modify the project file.

Modifying the F# Project File:

To allow a F# Library project to be called from a Metro app., the project file must be modified so that it imports the Microsoft.Windows.UI.Xaml.Common.targets. While this small adjustment allows the project to be interacted with, the reference shown in the Metro style project will provide a warning indicating that something isn't quite copacetic. This warning can be eliminated by adding the following elements to the property group:

<TargetFrameworkIdentifier>.NETCore</TargetFrameworkIdentifier><TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Unfortunately, adding these elements causes some sort of conflict with the F# targets, which I am still working to resolve. I have not yet run into an issue (other than the unsightly warning display) that is caused by leaving out these two elements, so for the moment only the common Xaml targets import has been added.   

Conclusion:

While there is still a lot of work to do, adding the import of the common Xaml targets to the F# project file will allow you to start using F# projects from Metro style apps (Note: In simple cases only--for now).  Once the remaining issues are identified and resolved, I'll add the F# Metro Library VSIX to Visual Studio Gallery. Until then, you can find the F# Metro Library VSIX (with the known issues) here.

Sunday, October 16, 2011

Two New F# 3.0 Type Provider Related NuGet Packages

There are two new NuGet packages available that can help you get started with authoring or consuming custom type providers. Both NuGet packages depend on the FSharpx.TypeProviders library that I wrote about in my last post and that Mauricio introduced in his most recent post.

FSharpx.TypeProviders.Sample:

The FSharpx.TypeProviders.Sample package provides an example of how to consume the custom type providers included in the FSharpx.TypeProviders library. The package adds a Test.config file as well as a F# source file that contains example code for using the TypedAppSettings type provider.

FSharpx.TypeProviders.DslSample:

The FSharpx.TypeProviders.DslSample package makes it easy to quickly get started with authoring a custom type provider. The package adds a F# source file that contains the source for a very simple custom type provider, a F# script file that can be used to test the custom type provider, and a batch file that makes it easy to do manual test/debug activities.

You may be curious about the commands in the batch file and why they are needed. Section 5.6 of the document on Writing F# 3.0 Type Providers that was provided by the F# team on 09/24/2011 includes development tips that make this more clear:

5.6.1 Run Two Visual Studio Instances. You can use one Visual Studio to develop the type provider. You can test it in another, since the test IDE will take a lock on the DLL preventing it being rebuilt. Thus, the second instance of Visual Studio must be closed while the provider is built in the first instance, and then reopened. 

5.6.2 Debug type providers by using invocations of fsc.exe. Type providers are invoked by 

- fsc.exe (The F# Command Line compiler)
- fsi.exe (The F# Interactive compiler)
- devenv.exe (Visual Studio)

Debugging type providers can often be easiest using fsc.exe on a test script file (e.g. script.fsx). This is because

- You can launch debug using a command-line prompt devenv /debugexe fsc.exe script.fsx - You can use print-to-stdout logging

I have tried both approaches and agree that the second is definitely the easiest. The .fsx and .bat files provided in this NuGet package make this approach even easier. Simply modify the code of the type provider, then test/debug by launching the batch file. Note: If/when changes to the Test.fsx file are required, it is recommended that these changes be made in an editor outside of Visual Studio.

Friday, October 7, 2011

Authoring Type Providers with the TypeProviderDSL from FSharpx

Several days ago, I submitted my AppSettings Type Provider to the FSharpx project. FSharpx is an open source library that adds a number of useful "functional constructs on top of the core F# library". I strongly encourage checking it out.

One of the many things in FSharpx that I find useful is the TypeProviderDSL. This is a DSL that sits on top of the ProvidedTypes module provided in the F# 3.0 Sample Pack. With this DSL and a few other helpers in FSharpx, the code from the AppSettings Type Provider that I showed in a previous post becomes easier to read. Plus, a few lines of code are shaved off in the process.

Let's look at a few of the features of the TypeProviderDSL that are used by the AppSettings Type Provider.

1. The erasedType function provides a simple way to create a ProvidedTypeDefinition.
2. The staticParameter function encapsulates the code needed to define a static parameter.
3. The literalField function makes it slightly easier to create a ProvidedLiteralField.
4. The addXmlDoc function provides a common way to add XML documentation.
5. Lastly, the |+> operator makes it very easy to add members.

Here's the end result:



You can get FSharpx.TypeProviders from the NuGet Gallery at http://www.nuget.org/List/Packages/FSharpx.TypeProviders and find the source on GitHub at https://github.com/fsharp/fsharpx/tree/TypeProviders.

Monday, October 3, 2011

MSDN Magazine Article: Authoring an F#/C# VSIX Project Template

My MSDN Magazine article entitled Authoring an F#/C# VSIX Project Template is now available in the October 2011 issue of MSDN Magazine.

A big thanks to Elijah Manor, Rick Minerich, and Chris Marinos for reviewing the article!

You can find the online version at http://msdn.microsoft.com/en-us/magazine/hh456399.aspx, the full code samples at http://fsharpmvc3vsix.codeplex.com/, and an enhanced version of the associated VSIX on Visual Studio Gallery at F#/C# ASP.NET MVC 3 Empty Web Application Template (see this previous post for more information about the extension that is available on Visual Studio Gallery).

Saturday, October 1, 2011

New F#/C# ASP.NET MVC 3 Template

There is a new F#/C# ASP.NET MVC 3 template now available on Visual Studio Gallery.


This template requires the ASP.NET MVC 3 Tools Refresh to be installed on the target machine and it provides functionality slightly similar to that which the Tools Refresh adds for C#/VB. Information on installing the ASP.NET MVC 3 Tools Refresh can be found at http://www.asp.net/mvc/mvc3.

With this project template, you will be able to create an empty ASP.NET MVC 3 Web Application. During the creation process, you will see a screen similar to the following with options that allow selection of ASPX or Razor view engine. Additionally, you can optionally choose to include a project which can be used to contain unit tests.


As usual, you can find the full source on my GitHub. Note: This template is an enhanced version of a template that is described in the MSDN Magazine article entitled "Authoring an F#/C# VSIX Project Template". I will be posting something about this article very soon.