Resolving FSharp.Compiler.Service clashes

[tpetricek]

One issue that we keep getting with FAKE + FSharp.Formatting is that FAKE comes with its own bundled version of F.C.S. which is used for running the build scripts. This means that if a build script references its own (different) version of F.C.S. that is not compatible with the one bundled with FAKE, things will break (when running the build script, we will always get the F.C.S. from FAKE.)

This affects build scripts using FSharp.Formatting and anyone else who would depend on F.C.S. (e.g. Suave apps that use the reload script, though this API does not change as frequently).

I think there are three options:

1. Just make sure that your build script uses the same (or compatible) FCS as the one bundled with FAKE. This is what we're doing currently and it sucks.

2. Do some magic in FAKE so that the scripts are executed in a separate AppDomain where no FCS is loaded. I thought about this, but I think it's hard. We would probably have to change FCS and even there, I'm not sure how to load the compiled interaction into a separate AppDomain without FCS dependency.

3. So, I had another thought. What if we just renamed the bundled DLL from FSharp.Compiler.Service.dll to, say, FAKE.FSharp.Compiler.Service.dll? This way, the DLL loaded by FAKE would not clash with any other versions that the scripts might want to load. I did a prototype for this and it seems to work, but I'm not sure if this can cause any issues...

/cc @dsyme @matthid @rneatherway
Do you think there is an easy way to do (2), which would probably be ideal? If no, do you think that (3) is a sensible solution?

[forki]

I tried to ILRepack FCS into FAKE, but did not succeed.

[matthid]

That would probably work if there is no reason within FCS to prevent this...

At the core I think it's a FAKE/Paket issue as well, and it's a issue for ALL dependencies FAKE, isn't it?
The problem is that Paket cannot find a proper resolution because it doesn't know what FAKE is bundling...
I didn't found the perfect fix for it jet, but fsprojects/Paket#1381 is an attempt....

[forki]

yeah but this would still keep issues with "normal" nuget.

[matthid]

Not if we define them in the nuspec as real dependencies and have an additional feature to make paket skip the download. Then the only issue on normal nuget are additional downloads....

[matthid]

It's really just a general idea not a concrete solution...

[matthid]

To get back to this issue:

(1) I would prefer this but obviously not how we do it currently (we don't do it at all ;) )
(2) I'm not sure this is feasable/practical
(3) I think if this works properly we might as well just do it and get over it ...

[matthid]

I think (3) could be a workaround for fsharp/fsharp-compiler-docs#466 as well

[tpetricek]

Solution (3) is now in, closing this!

[forki]

Will release tomorrow.
On Jan 22, 2016 10:08 PM, "Tomas Petricek" [email protected] wrote:

Solution (3) is now in, closing this!

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

[forki]

Thanks for everything!
On Jan 22, 2016 10:09 PM, "Steffen Forkmann" [email protected] wrote:

Will release tomorrow.
On Jan 22, 2016 10:08 PM, "Tomas Petricek" [email protected]
wrote:

Solution (3) is now in, closing this!

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