Failed to resolve assembly: 'FSharp.Core, Version=4.4.1.0 (Incorrect path references for assemblies?)

[o1lo01ol1o]

I'm posting in this repo since it is the easiest from which to replicate the problem, but it looks like more than a few of the MBrace assemblies are referenced statically from somewhere (as opposed to via paket). For example running the 1-hello-world.fsx on a clean pull on windows 10, VS 2017 up to line 38 works but creating the task in the subsequent lines throws:

Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'FSharp.Core, Version=4.4.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
   at Mono.Cecil.DefaultAssemblyResolver.Resolve(AssemblyNameReference name)
   at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
   at Mono.Cecil.TypeReference.Resolve()
   at Mono.Cecil.Mixin.CheckedResolve(TypeReference self)
   at Mono.Cecil.SignatureWriter.WriteCustomAttributeEnumValue(TypeReference enum_type, Object value)
   at Mono.Cecil.SignatureWriter.WriteCustomAttributeValue(TypeReference type, Object value)
   at Mono.Cecil.SignatureWriter.WriteCustomAttributeElement(TypeReference type, CustomAttributeArgument argument)
   at Mono.Cecil.SignatureWriter.WriteCustomAttributeConstructorArguments(CustomAttribute attribute)
   at Mono.Cecil.MetadataBuilder.GetCustomAttributeSignature(CustomAttribute attribute)
   at Mono.Cecil.MetadataBuilder.AddCustomAttributes(ICustomAttributeProvider owner)
   at Mono.Cecil.MetadataBuilder.AddType(TypeDefinition type)
   at Mono.Cecil.MetadataBuilder.AddTypeDefs()
   at Mono.Cecil.MetadataBuilder.BuildTypes()
   at Mono.Cecil.MetadataBuilder.BuildModule()
   at Mono.Cecil.ModuleWriter.BuildMetadata(ModuleDefinition module, MetadataBuilder metadata)
   at Mono.Cecil.ModuleWriter.WriteModuleTo(ModuleDefinition module, Stream stream, WriterParameters parameters)
   at Mono.Cecil.ModuleDefinition.Write(Stream stream, WriterParameters parameters)
   at Mono.Cecil.ModuleDefinition.Write(String fileName, WriterParameters parameters)
   at Nessos.Vagabond.SliceCompiler.compileDynamicAssemblySlice(AssemblyCompilerState state, Assembly dynamicAssembly) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\SliceCompiler\AssemblyCompiler.fs:line 80
   at Nessos.Vagabond.SliceCompiler.compileAssembly(AssemblyCompilerState state, Assembly assembly) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\SliceCompiler\AssemblyCompiler.fs:line 124
   at Nessos.Vagabond.SliceCompiler.compileAssemblies@134-1.Invoke(Assembly assembly) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\SliceCompiler\AssemblyCompiler.fs:line 137
   at Nessos.Vagabond.Utils.MailboxProcessor`1.PostAndReply[Msg,R](FSharpMailboxProcessor`1 m, FSharpFunc`2 msgB) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\Utils.fs:line 302
   at Nessos.Vagabond.VagabondManager.compile(Assembly[] assemblies) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\Vagabond.fs:line 34
   at Nessos.Vagabond.VagabondManager.ComputeObjectDependencies(Object graph, FSharpOption`1 permitCompilation, FSharpOption`1 includeNativeDependencies) in C:\Users\eirik\Development\nessos\Vagabond\src\Vagabond\Vagabond.fs:line 111
   at MBrace.Runtime.Components.StoreAssemblyManager.ComputeDependencies[T](T graph) in C:\Users\eirik\Development\mbrace\MBrace.Core\src\MBrace.Runtime\Components\StoreAssemblyManager.fs:line 294
   at MBrace.Runtime.Components.StoreAssemblyManager.MBrace-Runtime-IAssemblyManager-ComputeDependencies(Object graph) in C:\Users\eirik\Development\mbrace\MBrace.Core\src\MBrace.Runtime\Components\StoreAssemblyManager.fs:line 308
   at <StartupCode$MBrace-Runtime>.$MBraceClient.CreateProcessAsync@65.Invoke(Unit unitVar) in C:\Users\eirik\Development\mbrace\MBrace.Core\src\MBrace.Runtime\Runtime\MBraceClient.fs:line 66
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@839.Invoke(AsyncParams`1 args)
   at MBrace.Core.Internals.AsyncExtensions.Async.RunSync[T](FSharpAsync`1 workflow, FSharpOption`1 cancellationToken) in C:\Users\eirik\Development\mbrace\MBrace.Core\src\MBrace.Core\Utils\AsyncExtensions.fs:line 101
   at <StartupCode$FSI_0014>.$FSI_0014.main@() in C:\Users\data_owner\Source\Repos\MBrace.StarterKit\HandsOnTutorial.FSharp\1-hello-world.fsx:line 38
Stopped due to error

You'll also notice that the path C:\Users\eirik\Development\mbrace\ is referenced a few times.

Maybe a branch was pushed that shouldn't have been?

[o1lo01ol1o]

This appears to be a build problem with VS2017; 2015 appears to be able to build and run the examples. Is there any notion of when vs2017 might be supported?

[eiriktsarpalis]

AFAIK nobody is currently actively working on maintaining this project. I think though that is merely a binding redirect issue. It could be fixed by changing the application configuration of your cluster nodes.

[o1lo01ol1o]

AFAIK nobody is currently actively working on maintaining this project.

This project only being the StarterKit, yes?

I ran into some other issues with a thespian local setup using f# 4.4.1.0 and VS 2017 so I came here to try to isolate the problem (Though maybe I didn't configure the cluster correctly in that project). I'll take another look at the error in the MBrace.Core script on vs2017 if I get a second.

[isaacabraham]

Let me know how you get on - we might rationalise some of this and move to the ARM template deployment, which will make things a lot simpler.

[isaacabraham]

@eiriktsarpalis how did we get around this when we moved from F#3.1 to 4.0?

[isaacabraham]

AFAIK nobody is currently actively working on maintaining this project.

Anthony and myself are still maintaining this.

[dsyme]

I'm watching from a distance and plan to get back to being more involved :)

[o1lo01ol1o]

@eiriktsarpalis @isaacabraham I couldn't find an obvious way to specify redirects on the worker process besides editing the local Thespien.worker.config in my local packages directory. This unsurprisingly caused the workers to crash on init.

I also cloned MBrace.Core and bumped the FSharp.Core versions on Thespian and Thespian.Worker projects and added a binding redirect on the latter's App.config. The worker processes complained about being unable to locate FSharp.Core 4.3.xx and 4.4.1.0 and crashed.

I'm happy to try something else if either of you have a better idea than my errant noodling.

[isaacabraham]

@o1lo01ol1o I'll make some time over the next few days to look into this. I'm assuming that the problem is that FSI in VS2017 uses FSharp.Core 4.1, which doesn't exist on the cluster nodes. The solution will probably be a combination of binding redirects and / or ensuring that FSharp.Core 4.1 is on the cluster (even if this is an explicit action).

I don't think you can explicitly reference FSharp.Core 4.1 from nuget within an F# script?

[dsyme]

@isaacabraham IIRC this is a tricky issue. The version of FSharp.Core on the worker nodes needs to match the version of FSharp.Core in the client FSI.EXE

This really means we need different FSharp.Core binding for worker nodes for VS2015 and VS2017. IIRC @eiriktsarpalis and I couldn't find a way to make this work seamlessly when we hit the same problem for VS2013 and VS2015.

Upgrading the worker nodes to always use the latest, highest FSharp.Core 4.4.1.0 was certainly an improvement, but then I think there was a risk of unsoundness for down version FSI.EXE clients.

I'll prepare a PR to do a systematic upgrade of all FSharp.Core packages in MBrace workers to 4.4.1.0 but we should check things from VS2015, or deprecate use of the latest version from VS2015 before making it the default version used by the starter pack

[isaacabraham]

That sounds like a plan re: having a "last known good" version for VS2015. I'd like to get the ARM support in for VS2015 at some point though to the starter kit.

[eiriktsarpalis]

@o1lo01ol1o did you try copying FSharp.Core 4.4.1.0 to the tools folder of the thespian package and update the binding redirects for the executable there?

[o1lo01ol1o]

@eiriktsarpalis I copied a FSharp.Core 4.4.1.0 to tools and updated the worker's accompanying xml with a binding redirect to 4.4.1.0 but there was no change when I ran the hello world example.

[MaxWilson]

Is this issue still being worked on? I am trying to learn MBrace and since MBrace Azure isn't working right now, Thespian is my only option, and I immediately hit this issue. I'm going to try running the script in VS 2015 as a workaround.

[laygr]

Again the bleeding edge technology. I'll see if I can run the Thespian scripts in Visual Studio for Mac. Update: Well, it worked in Visual Studio Code for Mac. Visual Studio for Mac is installing, but I guess it will also work. I'll trust MBrace and use it for my Master's thesis 🤞.