Crash when upgrading to FSharp.Formatting 1.4.0.4 #337

eiriktsarpalis · 2015-09-04T15:33:02Z

I came across the following crash when upgrading FSharp.Formatting in the mbrace-docs repository:

Generating 'c:\Users\eirik\Development\mbrace\mbrace-docs\docs\tools\..\content/azure-tutorial.html'
System.MethodAccessException: Attempt by method 'FSharpVSPowerTools.Lexer.|GenericTypeParameterPrefix|StaticallyResolvedTypeParameterPrefix|Other|@92(System.String, Microsoft.FSharp.Compiler.SourceCodeServices.FSharpTokenInfo)' to access method 'Microsoft.FSharp.Compiler.Parser.tokenTagToTokenId(Int32)' failed.
   at FSharp.CodeFormat.CodeFormatAgent.ParseSource(String file, String source, FSharpOption`1 options, FSharpOption`1 defines) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.CodeFormat\CodeFormatAgent.fs:line 390
   at FSharp.Literate.ParseScript.parseScriptFile(String file, String content, CompilerContext ctx) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\ParseScript.fs:line 198
   at FSharp.Literate.Literate.ParseScriptFile[d](String path, FSharpOption`1 formatAgent, FSharpOption`1 compilerOptions, FSharpOption`1 definedSymbols, FSharpOption`1 references, FSharpOption`1 fsiEvaluator) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 67
   at FSharp.Literate.Literate.ProcessScriptFile(String input, FSharpOption`1 templateFile, FSharpOption`1 output, FSharpOption`1 format, FSharpOption`1 formatAgent, FSharpOption`1 prefix, FSharpOption`1 compilerOptions, FSharpOption`1 lineNumbers, FSharpOption`1 references, FSharpOption`1 fsiEvaluator, FSharpOption`1 replacements, FSharpOption`1 includeSource, FSharpOption`1 layoutRoots, FSharpOption`1 generateAnchors, FSharpOption`1 assemblyReferences, FSharpOption`1 customizeDocument) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 167
   at <StartupCode$FSharp-Literate>[email protected](String file, String output) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 184
   at <StartupCode$FSharp-Literate>.$Main.processDirectory@199(FSharpOption`1 format, Boolean processRecursive, FSharpFunc`2 processScriptFile, FSharpFunc`2 processMarkdown, String indir, String outdir) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 218
   at FSharp.Literate.Literate.ProcessDirectory(String inputDirectory, FSharpOption`1 templateFile, FSharpOption`1 outputDirectory, FSharpOption`1 format, FSharpOption`1 formatAgent, FSharpOption`1 prefix, FSharpOption`1 compilerOptions, FSharpOption`1 lineNumbers, FSharpOption`1 references, FSharpOption`1 fsiEvaluator, FSharpOption`1 replacements, FSharpOption`1 includeSource, FSharpOption`1 layoutRoots, FSharpOption`1 generateAnchors, FSharpOption`1 assemblyReferences, FSharpOption`1 processRecursive, FSharpOption`1 customizeDocument) in c:\Tomas\Public\tpetricek\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 181
   at FSI_0003.processDir@88(String topdir) in c:\Users\eirik\Development\mbrace\mbrace-docs\docs\tools\generate.fsx:line 93
   at FSI_0003.buildDocumentation() in c:\Users\eirik\Development\mbrace\mbrace-docs\docs\tools\generate.fsx:line 85
   at <StartupCode$FSI_0003>.$FSI_0003.main@() in c:\Users\eirik\Development\mbrace\mbrace-docs\docs\tools\generate.fsx:line 105
Stopped due to error

The text was updated successfully, but these errors were encountered:

dsyme · 2015-09-10T15:05:38Z

FCS 1.4.0.4 is not binary compatible with previous versions because some things have been made internal. FSharp.Formatting uses a version constraint ">= 0.0.87" for FCS which is inherently dangerous since binary compat has never really been promised for FCS. I think a constraint ">= 0.0.87" and "<= 1.3.0.2" will work OK though in practice

tpetricek · 2015-09-10T17:26:25Z

I guess we should just update FSharp.Formatting to use the latest version then. But we are also relying on Visual F# PowerTools, so we might need to wait for them first...

In the meantime, is there a way to specify range in a nuspec file?

dsyme · 2015-09-10T18:29:18Z

Note 1.4 is for F# 4.x support. That might not be what you want when processing scripts as it may induce dependencies on having FSHarp.Core 4.4.0.0 available, at least check for that. (The default behaviour should be to look at the FSharp.Core referenced by the ultimate host .EXE of the DLL, which sounds sensible, but be careful!)

tpetricek · 2015-09-12T01:37:18Z

I see, didn't realize this is for F# 4.x. I'm testing a fix (specifying range in the NuGet package)

tpetricek · 2015-09-12T01:56:44Z

Ok, new version of F# formatting fixes this, but there is a big but....

If you are using Paket, you need to explicitly tell it that you want at least the current version of F# Formatting:

nuget FSharp.Formatting >= 2.10.3

As we did not have the constraint before, there is another valid resolution which is to get the latest F# Compiler Service and older release of F# Formatting. This will not work - but I think there is no way to prevent this - because the new incompatible version of FCS has a higher version :-(

tpetricek · 2015-09-12T01:59:51Z

Actually, maybe you only run into the issues if you also explicitly require FCS, which was the case in my project, which had:

nuget FSharp.Compiler.Service
nuget FSharp.Formatting >= 2.10.3

So, this should be OK for normal uses...

CumpsD · 2015-10-13T16:59:48Z

I am resolving into this:

    FSharp.Compiler.Service (0.0.90)
    FSharp.Formatting (2.11.0)
      FSharp.Compiler.Service (>= 0.0.90 <= 1.3)
      FSharpVSPowerTools.Core (1.9.0)
    FSharpVSPowerTools.Core (1.9.0)
      FSharp.Compiler.Service (>= 0.0.90)

However I am still getting the same error

System.MethodAccessException: Attempt by method 'FSharpVSPowerTools.Lexer.|GenericTypeParameterPrefix|StaticallyResolvedTypeParameterPrefix|Other|@92(System.String, Microsoft.FSharp.Compiler.SourceCodeServices.FSharpTokenInfo)' to access method 'Microsoft.FSharp.Compiler.Parser.tokenTagToTokenId(Int32)' failed.
   at FSharp.CodeFormat.CodeFormatAgent.ParseSource(String file, String source, FSharpOption`1 options, FSharpOption`1 defines) in c:\Projects\FSharp.Formatting\src\FSharp.CodeFormat\CodeFormatAgent.fs:line 388
   at FSharp.Literate.ParseScript.parseScriptFile(String file, String content, CompilerContext ctx) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\ParseScript.fs:line 198
   at FSharp.Literate.Literate.ParseScriptFile[d](String path, FSharpOption`1 formatAgent, FSharpOption`1 compilerOptions, FSharpOption`1 definedSymbols, FSharpOption`1 references, FSharpOption`1 fsiEvaluator) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 67
   at FSharp.Literate.Literate.ProcessScriptFile(String input, FSharpOption`1 templateFile, FSharpOption`1 output, FSharpOption`1 format, FSharpOption`1 formatAgent, FSharpOption`1 prefix, FSharpOption`1 compilerOptions, FSharpOption`1 lineNumbers, FSharpOption`1 references, FSharpOption`1 fsiEvaluator, FSharpOption`1 replacements, FSharpOption`1 includeSource, FSharpOption`1 layoutRoots, FSharpOption`1 generateAnchors, FSharpOption`1 assemblyReferences, FSharpOption`1 customizeDocument) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 167
   at <StartupCode$FSharp-Literate>[email protected](String file, String output) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 184
   at <StartupCode$FSharp-Literate>.$Main.processDirectory@199(FSharpOption`1 format, Boolean processRecursive, FSharpFunc`2 processScriptFile, FSharpFunc`2 processMarkdown, String indir, String outdir) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 218
   at FSharp.Literate.Literate.ProcessDirectory(String inputDirectory, FSharpOption`1 templateFile, FSharpOption`1 outputDirectory, FSharpOption`1 format, FSharpOption`1 formatAgent, FSharpOption`1 prefix, FSharpOption`1 compilerOptions, FSharpOption`1 lineNumbers, FSharpOption`1 references, FSharpOption`1 fsiEvaluator, FSharpOption`1 replacements, FSharpOption`1 includeSource, FSharpOption`1 layoutRoots, FSharpOption`1 generateAnchors, FSharpOption`1 assemblyReferences, FSharpOption`1 processRecursive, FSharpOption`1 customizeDocument) in c:\Projects\FSharp.Formatting\src\FSharp.Literate\Main.fs:line 181
   at FSI_0003.buildDocumentation() in D:\Code\GH-Exira\ges\docs\tools\generate.fsx:line 140
   at <StartupCode$FSI_0003>.$FSI_0003.main@() in D:\Code\GH-Exira\ges\docs\tools\generate.fsx:line 147

What do I exactly need to do to fix this?

forki · 2015-10-13T17:19:55Z

not sure, but would releasing #345 help?

CumpsD · 2015-10-13T17:20:27Z

Here are the relevant files which cause it:
https://github.com/exira/ges/blob/ca747a75b544259b714af65cf6535b776360296a/paket.dependencies
https://github.com/exira/ges/blob/ca747a75b544259b714af65cf6535b776360296a/paket.lock

That repo build.cmd right now fails on it. (commit ca747a75b544259b714af65cf6535b776360296a)

CumpsD · 2015-10-13T17:32:47Z

@forki perhaps, if I ran with this it worked:

nuget FSharp.Formatting 2.8.0
nuget FSharpVSPowerTools.Core 1.7.0

but I wanted to upgrade FSharp.Formatting :)

forki · 2015-10-13T17:36:15Z

yeah but paket can't do magic. if stuff is in compatible we need to express this in the dependencies.

CumpsD · 2015-10-13T17:39:53Z

Does this issue need to be reopened then? Since the current dependencies actually don't work?

forki · 2015-10-13T17:43:54Z

Yes it's breaking other things too. Like fsreveal
On Oct 13, 2015 7:39 PM, "David Cumps" [email protected] wrote:

Does this issue need to be reopened then? Since the current dependencies
actually don't work?

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

tpetricek · 2015-10-13T17:45:55Z

Reopened. @matthid - do you have any thoughts on this? Feel free to do a new release if that can help. (Though it looks like the dependencies in the paket.lock posted by @CumpsD are reasonable...?)

CumpsD · 2015-10-13T18:04:59Z

For completeness sake, this is the last thing I managed to get working:

nuget FSharp.Formatting 2.8.0
nuget FSharpVSPowerTools.Core 1.7.0

    FSharp.Compiler.Service (1.4.0.6)
    FSharp.Core (4.0.0.1)
    FSharp.Formatting (2.8.0)
      FSharp.Compiler.Service (>= 0.0.86)
      FSharpVSPowerTools.Core (>= 1.7.0)
    FSharpVSPowerTools.Core (1.7.0)
      FSharp.Compiler.Service (>= 0.0.81)

Whenever I play with increasing version to something higher, things break at various places

Best case I would simply need nuget FSharp.Formatting defined :)

tpetricek · 2015-10-13T18:10:40Z

If my understanding is correct, this is fundamentally because we get a version of FSharpVSPowerTools and a version of FSharp.Compiler.Service that are not compatible.

So perhaps we need some help from @dungpa and @vasily-kirichenko to better understand how to correctly reference VSPowerTools? (So that new releases of FSharp.Compiler.Service do not break FSharp.Formatting...??)

CumpsD · 2015-10-13T18:12:47Z

I tried forcing FSharp.Formatting 2.8.0 with the latest Powertools and latest compiler services (since the dependencies on powertools allow that) but strangely enough in that case I had a problem coming from powertools.

You can try with:

nuget FSharp.Formatting 2.8.0
nuget FSharpVSPowerTools.Core 2.1.0

    FSharp.Compiler.Service (1.4.0.6)
    FSharp.Core (4.0.0.1)
    FSharp.Formatting (2.8.0)
      FSharp.Compiler.Service (>= 0.0.86)
      FSharpVSPowerTools.Core (>= 1.7.0)
    FSharpVSPowerTools.Core (2.1.0)
      FSharp.Compiler.Service (>= 1.4.0.6)

matthid · 2015-10-13T19:44:08Z

The problem here is https://github.com/exira/ges/blob/ca747a75b544259b714af65cf6535b776360296a/docs/tools/generate.fsx#L30
Because this is the 'first' #I line and because FAKE bundles a FSharp.Compiler.Service.dll (the latest) that one will be taken instead of the version our load script would load.

We cannot do much here at FSharp.Formatting and our dependencies are in fact correct as far as I can see.
One thing we could do would be to drop 'nuget' support and load our references via relative path (instead of by name) in FSharp.Formatting.fsx, but this may have different side-effects in other scenarios.

I think this issue can be closed.

TLDR:
@CumpsD Switch the #I Line (linked above) with the #load FSharp.Formatting.fsx line (directly below)

CumpsD · 2015-10-13T20:00:58Z

Ah, this was coming from ProjectScaffold https://github.com/fsprojects/ProjectScaffold/blob/master/docs/tools/generate.template#L30-L31

CumpsD · 2015-10-13T20:38:43Z

Confirmed to solve it.

My paket.dependencies:

redirects: on
source https://nuget.org/api/v2

nuget FSharp.Core
nuget FSharp.Formatting
nuget NUnit
nuget NUnit.Runners
nuget FAKE
nuget SourceLink.Fake
nuget EventStore.Client
nuget FsPickler.Json
nuget ExtCore
nuget Microsoft.Owin

github fsharp/FAKE modules/Octokit/Octokit.fsx

My paket.lock:

REDIRECTS: ON
NUGET
  remote: https://nuget.org/api/v2
  specs:
    EventStore.Client (3.3.1)
    ExtCore (0.8.45)
    FAKE (4.5.7)
    FSharp.Compiler.Service (0.0.90)
    FSharp.Core (4.0.0.1)
    FSharp.Formatting (2.11.0)
      FSharp.Compiler.Service (>= 0.0.90 <= 1.3)
      FSharpVSPowerTools.Core (1.9.0)
    FSharpVSPowerTools.Core (1.9.0)
      FSharp.Compiler.Service (>= 0.0.90)
    FsPickler (1.5.2)
    FsPickler.Json (1.5.2)
      FsPickler (1.5.2)
      Newtonsoft.Json (>= 6.0.5)
    Microsoft.Bcl (1.1.10)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21) - import_targets: false
    Microsoft.Net.Http (2.2.29)
      Microsoft.Bcl (>= 1.1.10)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Owin (3.0.1)
      Owin (>= 1.0)
    Newtonsoft.Json (7.0.1)
    NUnit (2.6.4)
    NUnit.Runners (2.6.4)
    Octokit (0.16.0)
      Microsoft.Net.Http
    Owin (1.0.0)
    SourceLink.Fake (1.1.0)
GITHUB
  remote: fsharp/FAKE
  specs:
    modules/Octokit/Octokit.fsx (4982e503ccc973ed1f047a52ff69a675ec4b66e1)
      Octokit

The fix:

#load "../../packages/FSharp.Formatting/FSharp.Formatting.fsx"
#I "../../packages/FAKE/tools/"

Probably should be ported back to the guys from ProjectScaffold

tpetricek · 2015-10-13T23:04:58Z

If you can send a fix to ProjectScaffold, that would be awesome!

CumpsD · 2015-10-13T23:07:25Z

fsprojects/ProjectScaffold#212

tpetricek · 2015-10-14T08:34:42Z

Thanks!

I see what's happening now - there are two different copies of FSharp.Compiler.Service (one coming with FAKE and one coming with F# Formatting) and the ordering determines which one gets loaded...

forki · 2015-10-14T08:39:54Z

ah so maybe we should internalize that into FSharp.Formatting. I'd like to
do this in FAKE, but I know a couple of scripts that assume that the file
is there

2015-10-14 10:34 GMT+02:00 Tomas Petricek [email protected]:

Thanks!

I see what's happening now - there are two different copies of
FSharp.Compiler.Service (one coming with FAKE and one coming with F#
Formatting) and the ordering determines which one gets loaded...

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

forki · 2015-10-14T08:41:09Z

or wait. maybe I can still do this FAKE

2015-10-14 10:39 GMT+02:00 Steffen Forkmann [email protected]:

ah so maybe we should internalize that into FSharp.Formatting. I'd like to
do this in FAKE, but I know a couple of scripts that assume that the file
is there

2015-10-14 10:34 GMT+02:00 Tomas Petricek [email protected]:

Thanks!

I see what's happening now - there are two different copies of
FSharp.Compiler.Service (one coming with FAKE and one coming with F#
Formatting) and the ordering determines which one gets loaded...

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

tpetricek · 2015-10-14T08:46:33Z

In F# Formatting, we could have two NuGet packages - one with everything internalized (for "tool-like" use) and one with nothing internalized (for "library-like" use). Though even then, I can imagine scenarios where things would not be ideal.

I guess internalizing FSharp.Compiler.Service in FAKE is safer, because it is always used as a tool. But what happens when the F# Compiler Service running inside FAKE tries to load another F# Compiler Service that remains a mystery to me (I guess it might work though...)

forki · 2015-10-14T09:39:33Z

FAKE 4.6 comes with internalized FCS. Please check it out.

forki · 2015-10-15T19:44:16Z

yeah. the other thing didn't work. When I ILRepack into FakeLib.dll the I get an invalid CLR program ...

tpetricek · 2015-10-17T17:13:27Z

@Krzysztof-Cieslak just reported an error with FsLab journals, which was caused by this too.

I tried understanding what's going on, but I have absolutely no idea what is compatible with what. I get the above error with the following combo:

FSharp.Compiler.Service (= 0.0.90)
FSharpVSPowerTools.Core (= 1.9.0)
FSharp.Formatting (= 2.11.0)

But at the moment, that's the only allowed mix... Do we need to:

a) Just update to FCS 1.4 (now that there is a matching VFPT release)?
b) Use VFPT 1.9 with FCS 1.3.1?

What is better option?

tpetricek · 2015-10-17T17:16:33Z

This also does not work:

FSharp.Compiler.Service (= 1.3.1.2)
FSharpVSPowerTools.Core (= 1.8.0)
FSharp.Formatting (= 2.10.0)

Is there any combination at the moment that actually works??

tpetricek · 2015-10-17T17:21:07Z

I guess this might also be happening because FsLab silently loads the version from FAKE, but I can't seem to figure out how to avoid that.

tpetricek · 2015-10-17T17:22:47Z

Does FCS 1.4 require a different version of FSharp.Core? (which would make upgrading a nightmare...)

tpetricek · 2015-10-17T17:48:30Z

I have absolutely no idea what's going on here. But it seems that the version of FAKE I'm using has some effect here...

If you download FsLab journal template, then things will work.
But if you download it and change this line to require FAKE 4.5.5 rather than 4.5.4, then things break (on my machine at least).

Is this just me or can others reproduce this?

CumpsD · 2015-10-17T17:51:43Z

This combo works:

    FAKE (4.5.7)
    FSharp.Compiler.Service (0.0.90)
    FSharp.Core (4.0.0.1)
    FSharp.Formatting (2.11.0)
      FSharp.Compiler.Service (>= 0.0.90 <= 1.3)
      FSharpVSPowerTools.Core (1.9.0)
    FSharpVSPowerTools.Core (1.9.0)
      FSharp.Compiler.Service (>= 0.0.90)

On Oct 17, 2015 19:16, "Tomas Petricek" [email protected] wrote:

This also does not work:

FSharp.Compiler.Service (= 1.3.1.2)

FSharpVSPowerTools.Core (= 1.8.0)

FSharp.Formatting (= 2.10.0)

Is there any combination at the moment that actually works??

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

Krzysztof-Cieslak · 2015-10-17T18:09:24Z

Working with FAKE 4.5.4.

Not working with any higher- I've checked latest (4.7.1), 4.6.4, 4.6.0, 4.5.7, 4.5.6

matthid · 2015-10-17T20:56:38Z

Yes it's related to the FAKE update to FSharp.Core-4 and FSharp.Compiler-Service-1.4. However I'm not completely sure why it WORKS within a FAKE environment (FAKE.exe) but NOT outside.

The documentation generation script depends on FakeLib.dll which itself depends on the latest FSC.dll. On the other hand the script depends on FSharp.Formatting which depends on an older FSC.dll. Definitely a (high level) problem there.

By the way this seems to work as well:

nuget FSharp.Formatting == 2.11.1-alpha1 // Any recent version will work
nuget FSharpVSPowerTools.Core == 2.1.0
nuget FSharp.Compiler.Service == 1.4.2 // Any 1.4

So after updating to FSharp.Core 4 and PowerTools 2.1 it will probably start to work OK again. However understanding why it DOES work in a FAKE.exe even with a FSharpVSPowerTools.Core version which SHOULD NOT work still puzzles me (can somebody reproduce this with running the script with FAKE.exe instead of fsi.exe or is it just some weird thing happening on my machine?). I think in the future we should add some more tracing to figure out exactly which assemblies are loaded (but they are loaded lazily ...).

Krzysztof-Cieslak · 2015-10-17T21:18:28Z

My tests result are all based on FsLab template and run using FAKE script.

tpetricek · 2015-10-18T12:48:14Z

Thanks everyone for going through the additional test cases. Now I'm really puzzled what change in FAKE is doing this...

I tried printing the version of FCS loaded in current AppDomain in FAKE 4.5.4 and it still prints the 1.4 version of FCS (but then it works....)

matthid · 2015-10-18T13:53:29Z

If you download FsLab journal template, then things will work.

But if you download it and change this line to require FAKE 4.5.5 rather than 4.5.4, then things break (on my machine at least).

Can confirm but not explain this ...

Maybe FAKE.exe runs in a security context where it is allowed to access internal methods, that would at least explain how it can sometimes work at all... Maybe the context sometimes changes depending on how assemblies are build (the only difference in 4.5.4 and 4.5.5 is adding groups and paket update fsprojects/FAKE@4.5.4...4.5.5)

To close this issue we should release a version compatible with latest FAKE (ie update to powertools 2.1.0 and latest Fsharp.Compiler.Service)

The only safe option to prevent this error for now are (at least as far as I can understand this currently):

Tell people to either upgrade FSharp.Formatting
Downgrade FAKE to version 3

Maybe we should somehow detect a valid fake version and fail early if we are not compatible?

tpetricek · 2015-10-18T14:20:41Z

Yeah, we should definitely update F# Formatting to latest versions.. but I would still like to understand why this is happening.

Looks like there was no relevant change in FAKE, so perhaps this is something that has been caused by an update of FCS from version 1.4.0.1 to version 1.4.0.6. Perhaps there was some change there that affected how assemblies are loaded in FSI evaluator....?

tpetricek · 2015-10-18T14:24:56Z

Looks like FCS does not have a tag on GitHub for 1.4.0.1, but here are the changes between 1.4.0.2 and 1.4.0.6: fsharp/fsharp-compiler-docs@1.4.0.2...1.4.0.6

matthid · 2015-10-18T17:56:33Z

but I would still like to understand why this is happening.

definitely...

1.4.0.3 was the first version where the methods where made internal (https://github.com/fsharp/FSharp.Compiler.Service/blob/master/RELEASE_NOTES.md#1403--). This is what @dsyme was mentioning on his first post. So I think that's the solution to the mystery? It works until FAKE-4.5.4 because it uses FSharp.Compiler.Service < 1.4.0.3 and doesn't work on later versions.
Funny change for a patch level version number increase :).

However this bug also shows that locking our versions in the package doesn't really solve anything for us when running within FAKE. Maybe we should figure out a way to solve this eventually, when we are hit by this again (Spawning our own AppDomain?).

tpetricek · 2015-10-18T18:07:28Z

Ah, I see... so really, when running inside FAKE, we always end up running against the FAKE version of F# Compiler Service... Well that's a bummer.

I guess that's what @forki was trying to solve by internalizing F# Compiler Service, so that we can load our own version.

This is all a bit silly, but at least I get it now :)

matthid · 2015-10-18T18:07:32Z

Another idea would be to move FSharp.Formatting from the build into the main dependency group of FAKE, this would ensure that FAKE is updating FSharp.Compiler.Service only when we update it here.

@forki would you accept such a change in FAKE? That's not really in the spirit of paket groups and FSharp.Formatting is not a dependency of FAKE AND most important other projects can't really do the same (it is not the correct solution but a hack imho)

Edit: It's ironic that this couldn't happen before introducing paket groups :)

paket update (fixes #337)

tpetricek · 2015-10-18T19:41:46Z

Wait - I'm not sure I understand - how is this related to Paket groups? (I thought the issue is just that FAKE comes with FCS and now it happens to come with one that's not compatible with F# Formatting...)

forki · 2015-10-19T07:17:18Z

Yes, but by putting fsf into the main group FAKE's own dependency file
would work. Then paket would resolver a FCS that is compatible to fsf. And
we would ship that version with FAKE.
On Oct 18, 2015 21:41, "Tomas Petricek" [email protected] wrote:

Wait - I'm not sure I understand - how is this related to Paket groups? (I
thought the issue is just that FAKE comes with FCS and now it happens to
come with one that's not compatible with F# Formatting...)

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

forki · 2015-10-19T07:17:43Z

I'm actually ok with that and would accept pr
On Oct 19, 2015 09:17, "Steffen Forkmann" [email protected] wrote:

Yes, but by putting fsf into the main group FAKE's own dependency file
would work. Then paket would resolver a FCS that is compatible to fsf. And
we would ship that version with FAKE.
On Oct 18, 2015 21:41, "Tomas Petricek" [email protected] wrote:

Wait - I'm not sure I understand - how is this related to Paket groups?
(I thought the issue is just that FAKE comes with FCS and now it happens to
come with one that's not compatible with F# Formatting...)

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

matthid · 2015-10-19T16:01:23Z

I have one more idea: What about adding FAKE as a dependency of FSharp.Formatting? That should work as well and is a better solution imho (as we really do depend on FAKE in the projectscaffold use-case). Ideally we would not add the dependency to the library package and only to a "scripting" package. But it should not do any harm either (an additional download in the worst case). For FAKE it would lead to slower adoption rates for new versions (as everyone needs to wait for a FSF update).

This solution assumes that people have FSharp.Formatting and FAKE in the same paket group...

forki · 2015-10-19T16:03:30Z

This solution assumes that people have FSharp.Formatting and FAKE in the
same paket group.
that's pretty fair assumption.

2015-10-19 18:01 GMT+02:00 Matthias Dittrich [email protected]:

I have one more idea: What about adding FAKE as a dependency of
FSharp.Formatting? That should work as well and is a better solution imho
(as we really do depend on FAKE in the projectscaffold use-case). Ideally
we would not add the dependency to the library package and only to a
"scripting" package. But it should not do any harm either (an additional
download in the worst case). For FAKE it would lead to slower adoption
rates for new versions (as everyone needs to wait for a FSF update).

This solution assumes that people have FSharp.Formatting and FAKE in the
same paket group...

—
Reply to this email directly or view it on GitHub
#337 (comment)
.

tpetricek closed this as completed in 5d4b440 Sep 12, 2015

tpetricek reopened this Oct 13, 2015

CumpsD mentioned this issue Oct 13, 2015

Fix FSharp.Formatting and FSharp.Compiler.Service fsprojects/ProjectScaffold#212

Merged

matthid mentioned this issue Oct 18, 2015

paket update (fixes #337) #348

Merged

matthid closed this as completed in c9bae27 Oct 18, 2015

tpetricek added a commit that referenced this issue Oct 18, 2015

Merge pull request #348 from tpetricek/update_dependencies

270a5e5

paket update (fixes #337)

simra mentioned this issue Nov 8, 2015

VS2015 FSLab journal template dll reference error. fslaborg/zzarchive-FsLab#98

Closed

matthid mentioned this issue Nov 20, 2015

use FAKE for documentation generation. fsprojects/ProjectScaffold#217

Merged

This was referenced Jan 12, 2016

FCS + PowerTools breaking F# Formatting fsharp/fsharp-compiler-docs#510

Closed

Suggestion: Skip download of dependencies fsprojects/Paket#1381

Closed

Crash when upgrading to FSharp.Formatting 1.4.0.4 #337

Crash when upgrading to FSharp.Formatting 1.4.0.4 #337

Comments

eiriktsarpalis commented Sep 4, 2015

dsyme commented Sep 10, 2015

tpetricek commented Sep 10, 2015

dsyme commented Sep 10, 2015

tpetricek commented Sep 12, 2015

tpetricek commented Sep 12, 2015

tpetricek commented Sep 12, 2015

CumpsD commented Oct 13, 2015

forki commented Oct 13, 2015

CumpsD commented Oct 13, 2015

CumpsD commented Oct 13, 2015

forki commented Oct 13, 2015

CumpsD commented Oct 13, 2015

forki commented Oct 13, 2015

tpetricek commented Oct 13, 2015

CumpsD commented Oct 13, 2015

tpetricek commented Oct 13, 2015

CumpsD commented Oct 13, 2015

matthid commented Oct 13, 2015

CumpsD commented Oct 13, 2015

CumpsD commented Oct 13, 2015

tpetricek commented Oct 13, 2015

CumpsD commented Oct 13, 2015

tpetricek commented Oct 14, 2015

forki commented Oct 14, 2015

forki commented Oct 14, 2015

tpetricek commented Oct 14, 2015

forki commented Oct 14, 2015

forki commented Oct 15, 2015

tpetricek commented Oct 17, 2015

tpetricek commented Oct 17, 2015

tpetricek commented Oct 17, 2015

tpetricek commented Oct 17, 2015

tpetricek commented Oct 17, 2015

CumpsD commented Oct 17, 2015

Krzysztof-Cieslak commented Oct 17, 2015

matthid commented Oct 17, 2015

Krzysztof-Cieslak commented Oct 17, 2015

tpetricek commented Oct 18, 2015

matthid commented Oct 18, 2015

tpetricek commented Oct 18, 2015

tpetricek commented Oct 18, 2015

matthid commented Oct 18, 2015

tpetricek commented Oct 18, 2015

matthid commented Oct 18, 2015

tpetricek commented Oct 18, 2015

forki commented Oct 19, 2015

forki commented Oct 19, 2015

matthid commented Oct 19, 2015

forki commented Oct 19, 2015