Skip to content

Updated fsharp to 4.3.1 and .NET to 4.5.1#15

Open
diskdan wants to merge 2 commits into
jack-pappas:masterfrom
diskdan:UpgradeFSharp
Open

Updated fsharp to 4.3.1 and .NET to 4.5.1#15
diskdan wants to merge 2 commits into
jack-pappas:masterfrom
diskdan:UpgradeFSharp

Conversation

@diskdan
Copy link
Copy Markdown

@diskdan diskdan commented Jun 16, 2014

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

@jack-pappas
Copy link
Copy Markdown
Owner

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.

@DanielFabian
Copy link
Copy Markdown
Contributor

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 notifications@github.com 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
#15 (comment).

@dsyme
Copy link
Copy Markdown

dsyme commented Jun 22, 2014

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

@jack-pappas
Copy link
Copy Markdown
Owner

@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)?

@DanielFabian
Copy link
Copy Markdown
Contributor

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 notifications@github.com 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
#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
#15 (comment).

@jack-pappas
Copy link
Copy Markdown
Owner

@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?

@diskdan
Copy link
Copy Markdown
Author

diskdan commented Aug 12, 2014

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.

@sergey-tihon
Copy link
Copy Markdown
Collaborator

No, the latest in 0.8.8-alpha
https://www.nuget.org/packages/Facio/
this link is from Facio site.

@jack-pappas
Copy link
Copy Markdown
Owner

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants