Home → Support →

F# 3.1.

• Edit

rowinginmotion

Nov 13, 2014 @ 12:22 PM

It appears AppHarbor cannot build F# 3.1. projects that use F# 3.1. specific features (so this is not about FSharp.Core etc but the actual compiler):

E.g. using the new named fields on discriminated unions (introduced in F# 3.1) fails to compile on AppHarbor:

  type Sample = 
    | SomeSample of t : float *  x : float

F# 3.1. is out for exactly one year now, is there any chance we can get the 3.1. compiler on the AppHarbor build boxes shortly?

1. Support Staff 1 Posted by rune on Nov 13, 2014 @ 11:50 PM

   

   Hi,

   The build servers have F# version 3.1.1 installed already - what error are you seeing and do you have a link to a build that's affected by this issue?

   Best,
   rune

   • Edit

2. 2 Posted by rowinginmotion on Nov 14, 2014 @ 01:16 PM

   

   https://appharbor.com/applications/rowinginmotion-analytics/builds/...

   I can see that one of our PCL projects is compiled with the 3.1 fsc.exe while our standard (full) .NET F# projects get compiled with 3.0 apparentl C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\fsc.exe

   I think that is the case because the standard vs snippet in our fsprojs appears to be
   

     <Choose>
       <When Condition="'$(VisualStudioVersion)' == '11.0'">
         <PropertyGroup>
           <FSharpTargetsPath>$(MSBuildExtensionsPath32)..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
         </PropertyGroup>
       </When>
       <Otherwise>
         <PropertyGroup>
           <FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
         </PropertyGroup>
       </Otherwise>
     </Choose>
   

   So, apparently our build in AppHarbor fell back to the 3.0 sdk. Updated that to 3.1 and builds are fine now. Thanks for confirming 3.1 is on the build servers! (Btw. it would be awesome if there was some sort of an image / directory catalog of the build servers so devs can check for themselves what is there and what is not).

   • Edit

3. Support Staff 3 Posted by rune on Nov 14, 2014 @ 10:29 PM

   

   OK great, glad it worked out and thanks for sharing the cause and solution for this issue!

   I agree that it'd be helpful with a list of dependencies installed and available on the build servers, and perhaps also the directory structure as you mention. The directory structure might change though so it'd likely have to show directory structure relative to the the MsBuild macros (like MSBuildExtensionsPath32, which will be populated regardless of the actual physical location).

   Until that's ready you're of course still more than welcome to reach out if/when you hit issues like this. Ideally it wouldn't be necessary to know much about the implementations and software installed on servers - to make that happen it's useful to know what dependencies developer often experience issues with.

   Best,
   Rune

   • Edit

4. rowinginmotion closed this discussion on Nov 17, 2014 @ 09:20 AM.