jack-pappas
Updated fsharp to 4.3.1 and .NET to 4.5.1
Hi,
I've upgraded to FSharp 4.3.1 and .NET 4.5.1 - Dany Fabian should contact you about this, we had Problems using the old Version on our stack.
Thanks !
Daniel
Hi @diskdan (and @DanielFabian) -- Can you tell me more about the problems you were having with facio before making these changes?
If possible, I'd like to keep facio so it'll build with either VS2012 or VS2013. Many developers are still using VS2012, and facio isn't currently using any F# 3.1-specific features, so I think it's reasonable to try to keep the project compatible between the two versions, at least for now.
I do think it's reasonable to update facio to target .NET 4.5 though; .NET 4.5.1 and 4.5.2 are in-place upgrades on top of .NET 4.5, so there shouldn't be any issues there. I'll need to look into multi-target builds with FAKE though -- some of the binaries (like the table interpreter) will need builds targeting both .NET 4.0 and 4.5.
I wonder if it would be possible to modify the NuGet packages so that the binding redirect for FSharp.Core (e.g., in Graham's app.config) is modified when the package is referenced in a project, such that the upper-version-bound of the redirection is set to whatever version of FSharp.Core is being targeted by that project...I'll look into it.
We have only VS2013 and F#3.1 for this project and the trouble was that somehow assembly redirection did not want to work properly. That said, I do see your point about rather compiling with the earlier version and just redirecting.
@diskdan knows the things more in detail. One question though, what is
graham's app.config?
On 22 June 2014 22:48, Jack Pappas [email protected] wrote:
Hi @diskdan https://github.com/diskdan (and @DanielFabian https://github.com/DanielFabian) -- Can you tell me more about the problems you were having with facio before making these changes?
If possible, I'd like to keep facio so it'll build with either VS2012 or VS2013. Many developers are still using VS2012, and facio isn't currently using any F# 3.1-specific features, so I think it's reasonable to try to keep the project compatible between the two versions, at least for now.
I do think it's reasonable to update facio to target .NET 4.5 though; .NET 4.5.1 and 4.5.2 are in-place upgrades on top of .NET 4.5, so there shouldn't be any issues there. I'll need to look into multi-target builds with FAKE though -- some of the binaries (like the table interpreter) will need builds targeting both .NET 4.0 and 4.5.
I wonder if it would be possible to modify the NuGet packages so that the binding redirect for FSharp.Core (e.g., in Graham's app.config) is modified when the package is referenced in a project, such that the upper-version-bound of the redirection is set to whatever version of FSharp.Core is being targeted by that project...I'll look into it.
— Reply to this email directly or view it on GitHub https://github.com/jack-pappas/facio/pull/15#issuecomment-46792479.
Where possible public-facing libraries should continue to target FSharp.Core 4.3.0.0 for as long as possible, in order to allow a maximum number of upstack consumers, i.e. not to force dependencies upstack. This is even if they use F# 3.1. All language features in F# 3.1 work with FSharp.Core 4.3.0.0 (the 3.1 slicing syntax for getting 1-D arrays from 2-D arrays may be the only exception).
I know this can be painful but it is worth it :)
Cheers Don
@DanielFabian Are you asking about what an App.config is used for in general? Or how it's specifically being used with Graham and other facio tools?
I was putting together an example project using facio for @sergey-tihon a couple of weekends ago and I think I ran into a similar issue as you and @diskdan.
I have a new machine at home which only has VS2012 installed, so it only has FSharp.Core 4.3.0.0 on it. The facio tools and libraries make extensive use of my ExtCore library for performance reasons, and I've been targeting FSharp.Core 4.0.0.0 in ExtCore builds so it'd be forward-compatible from F# 2.0 onwards; pretty much every F# library/tool now uses App.config files to do a binding redirect from previous versions of FSharp.Core to 4.3.0.0 or 4.3.1.0 so this ordinarily works just fine.
App.config files are only loaded (recognized by the CLR) for the assembly which is the entry-point for a given process. When you run fsharplex or fsharpyacc directly from the command-line, they are the entry-point assemblies, so their .config files are picked up and the binding redirect works as expected. However, once you use the MSBuild tasks to integrate the tools into your build process, it seems the binding redirects are no longer applied, and the tools crash because ExtCore is unable to find FSharp.Core 4.0.0.0.
I haven't thought of a good permanent solution to this problem yet. However, if you need a temporary workaround -- I added the binding redirects to the machine.config files in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config and that fixed the assembly resolution issues so the tools stopped crashing during builds. Once that was fixed, I think I ran into #14 , but that's a separate problem...
@dsyme Would it be possible to add the machine.config binding redirects for FSharp.Core to the installer for the next OOB F# release (3.1.2)?
I was referring to how it is used in Graham and Facio. Because, I was looking for a way, how to make it work without the older FSharp.Core. And hacking the machine.config is ok for just your local machine, but it's not how one wants to solve the problem on a CI server...
On 13 July 2014 15:56, Jack Pappas [email protected] wrote:
@DanielFabian https://github.com/DanielFabian Are you asking about what an App.config is used for in general? Or how it's specifically being used with Graham and other facio tools?
I was putting together an example project using facio for @sergey-tihon https://github.com/sergey-tihon a couple of weekends ago and I think I ran into a similar issue as you and @diskdan https://github.com/diskdan.
I have a new machine at home which only has VS2012 installed, so it only has FSharp.Core 4.3.0.0 on it. The facio tools and libraries make extensive use of my ExtCore library for performance reasons, and I've been targeting FSharp.Core 4.0.0.0 in ExtCore builds so it'd be forward-compatible from F# 2.0 onwards; pretty much every F# library/tool now uses App.config files to do a binding redirect from previous versions of FSharp.Core to 4.3.0.0 or 4.3.1.0 so this ordinarily works just fine.
App.config files are only loaded (recognized by the CLR) for the assembly which is the entry-point for a given process. When you run fsharplex or fsharpyacc directly from the command-line, they are the entry-point assemblies, so their .config files are picked up and the binding redirect works as expected. However, once you use the MSBuild tasks to integrate the tools into your build process, it seems the binding redirects are no longer applied, and the tools crash because ExtCore is unable to find FSharp.Core 4.0.0.0.
I haven't thought of a good permanent solution to this problem yet. However, if you need a temporary workaround -- I added the binding redirects to the machine.config files in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config and that fixed the assembly resolution issues so the tools stopped crashing during builds. Once that was fixed, I think I ran into #14 https://github.com/jack-pappas/facio/issues/14 , but that's a separate problem...
@dsyme https://github.com/dsyme Would it be possible to add the machine.config binding redirects for FSharp.Core to the installer for the next OOB F# release (3.1.2)?
— Reply to this email directly or view it on GitHub https://github.com/jack-pappas/facio/pull/15#issuecomment-48841171.
@DanielFabian @diskdan I think this issue should be fixed in the latest version of facio (0.8.7-alpha). Can you give it a try to confirm?
Hi - the latest Version I can get over nuget is 0.8.6-alpha - is this the correct Version to test, i.e. is the above a typo ?
Apologies for the delay on this, I've been a bit swamped at work.
@diskdan The original package name was "FSharp.Tools". That was a bit too generic, so I renamed the project and package name to "Facio"; I think it was for 0.8.6 or 0.8.7. You should just be able to find/replace "FSharp.Tools" -> "Facio" in your .fsproj and packages.config files, then change the version number to 0.8.8.