Build

ovatsus edited this page Dec 9, 2012 · 11 revisions
Clone this wiki locally

The FSharpx project is using "FAKE - F# Make" as the build system.

There are different modes available:

  • ./build.v3.5.bat - builds FSharpx.Core for .NET Framework 3.5
  • ./build.v4.0.bat - builds FSharpx.Core, FSharpx.Observable, FSharpx.Http FSharpx.TypeProviders for .NET Framework 4.0
  • ./build.all.bat - builds all the projects for all compatible .NET framework versions

Building FSharpx.TypeProviders

Due to missing fsc.exe and fsi.exe there is no automated build for the type providers project at the moment. The nuget package is created by the following steps:

  • Fix the version no. at the top of build.fsx
  • Run build.v4.0.bat
  • Upload the package from nuget/TypeProviders manually to nuget.org.

Testing FSharpx.TypeProviders

Testing the full flow

  • Open FSharpx.WithTypeProviders.sln with Visual Studio 2012
  • Set FSharpx.TypeProviders as startup project
  • In the properties of FSharpx.TypeProviders:
    • Set the start action to "external program" and "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe"
    • Set the command line argument to "C:\code\fsharpx\FSharpx.TypeProviders.Tests.sln" (adjust the path to match to your system)
  • Run the project --> A new Visual Studio 2012 instance should opened with FSharpx.TypeProviders.Tests.sln
  • When opening the relevant files or compiling if there are breakpoints in the type provider code they will be hit

Previewing the types that will be generated

  • On each type provider project there's a test .fsx file that will allow you to see the types and members that will be generated in F# interactive without having to run another instance of Visual Studio, by using the generate and prettyPrint functions
  • If you want to use the debugger, you can also temporarily change the output type from Class Library to Console Application, rename the that .fsx file to .fs and run the project. You can use the this output as a form of regression testing when refactoring type providers
    • Note that if you do something similar but in a different project, VS will lock the type provider dll and you'll need to restart VS on each run. If you do this inside the same project this problem doesn't occur
  • This will only simulate the process and won't be exactly the same as running the type providers for real