Referencing Fsharp.Data.dll from the script produces design time-related error

[dsevastianov]

TL;DR

When Fsharp.Data.dll is referenced from the script that doesn't use type providers, only for the sake of JsonValue and such, it nevertheless requires Fsharp.Data.DesignTime. It would be nice to have core Json-related types available independently of the Type Provider itself.

Details

I have a project with mixed fs and fsx files, scripts referencing code files. I actually use fsharp scripts in place of console app for simple code execution, so it is important to reference dlls from bin\Release location and not from packages dir.

I add reference for FSharp.Data to the project so it's getting copied into bin\Release and reference it from the script. In the scripts, I'm getting design time error requiring to reference DesignTime dll as well.

Now, If I add reference to the DesignTime dll to the project so it gets copied into bin\Release as well, I'm getting "API restriction: The assembly 'file:///{..}\packages\FSharp.Data.2.0.5\lib\net40\FSharp.Data.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain."

[ovatsus]

Those types are actually independent of the type providers, that happens because of the TypeProviderAssembly attribute (https://github.com/fsharp/FSharp.Data/blob/master/src/Runtime.fs#L6), the compiler could be more forgiving if you don't actually use any TP. This is annoying, I agree, but the only solution would be to have 3 assemblies instead of 2, which I'm not very keep on doing as it would complicate even more the PCL support...

[vsapronov]

@ovatsus Can we reconsider this question? Here are some benefits of doing the split into FSharp.Data base types and FSharp.Data type providers:

1. As mentioned above FSharp.Data.DesignTime.dll would not be required anymore in scenarios when type providers are not used.
2. It looks like support for type providers in net core is not done yet and there's no clear plan (with dates on it). The split could make at least some part of FSharp.Data to be useful on net core and therefore on Linux.

The lack of split brought us internal (to company) fork of FSharp.Data with all well-known downsides of such fork. We would like to reiterate this and try to minimize code fragmentation if possible. If we could agree on such split I'm ready to contribute my time and effort.

Disclosure: I work as a developer at Jet.com/Walmart. The problem I'm raising is very real in enterprise F# development world.

[tpetricek]

I see this has 16x 👍 so I suspect people would find this useful - I can see how someone might want to use just the JsonValue stuff or for example the HTML parser that we have.

@vsapronov I'd say that if you'd have time to work on this and can work with @ovatsus to make sure this does not make other things too much more complicated, then we should accept this.

(I guess this means having FSharp.Data.Runtime.dll and FSharp.Data.dll that are both compiled for multiple profiles and FSharp.Data.DesignTime.dll that is only one profile? But I guess the remapping that happens in type providers might need to be fixed to work for this scenario?)

PS: Also, I think merging back from a fork that you guys have would be very useful for the project.

[ovatsus]

FSharp.Data.DesignTime.dll should already not be required in scenarios when type providers are not used, without having the need to split the assembly. I remember that working long time ago, we probably broke it with the last changes to support the new PCLs, but should be fixable

[vsapronov]

@ovatsus I have checked more thoroughly latest state on things. Yes, it seems that reference to FSharp.Data.DesignTime.dll is not required anywhere. Even when using NuGet/paket reference to that dll is not added automatically. This allows us to use minimal FSharp.Data.dll. I will check a bit more and probably will ask to close this issue as completed.

[eulerfx]

Fwiw, the error message with latest version is:

The type provider 'bin/Release/FSharp.Data.dll' reported an error: Assembly attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'FSharp.Data.DesignTime' which cannot be loaded or doesn't exist. Could not load file or assembly 'bin\Release\FSharp.Data.DesignTime.dll' or one of its dependencies. The system cannot find the file specified.

It appears when referencing FSharp.Data.dll from a script file:

#r "bin/release/FSharp.Data.dll"

If FSharp.Data.DesignTime.dll is copied into the bin folder, then the error goes away.

[eulerfx]

What are the potential paths forward on this issue? Can something be done so that the existing package works in this scenario? Or will a separate package be required?

[ovatsus]

What is the actual problem here? the nuget package has both, why is there a need to make it work deleting the designtime dll from the folder structure? It won't be required at runtime, only at compile time. If that is really a requirement, then I think this should be a request on the compiler to not fail if the design time component is missing and just give a warning

[eulerfx]

Yeah this could be a (fsi?) compiler request.

To reproduce:

• Reference FSharp.Data package from an F# project and build it.
• Create a Script.fsx in that project and reference FSharp.Data via #r "bin/release/fsharp.data.dll"

This results in an error message which says its looking for FSharp.Data.DesignTime.dll and it won't allow the script to run.

If instead the #r directive is pointed to the packages directory for FSharp.Data then it works fine.

What is the preferred way to use FSharp.Data from an F# script? The example on the homepage indicates #r "FSharp.Data.Dll" but this assumes the dll is in the same directory.

[giuliohome]

Wow, is it still open and unresolved after 6 years? So what you write at the start of https://fsharp.github.io/FSharp.Data/library/Http.html is simply not working, is it?

C:\code>dotnet fsi

Microsoft (R) F# Interactive versione 10.9.1.0 for F# 4.7
Copyright (C) Microsoft Corporation. Tutti i diritti sono riservati.

Per informazioni, digitare #help;;

> #r @"bin\Debug\netcoreapp3.1\FSharp.Data.dll";;

  #r @"bin\Debug\netcoreapp3.1\FSharp.Data.dll";;
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

stdin(5,1): error FS3031: Errore segnalato dal provider di tipi 'C:\code\bin\Debug\netcoreapp3.1\FSharp.Data.dll': L'attributo di assembly 'TypeProviderAssemblyAttribute' fa riferimento a un assembly della finestra di progettazione 'FSharp.Data.DesignTime' che non è stato caricato o non esiste. Could not load file or assembly 'C:\code\bin\Debug\netcoreapp3.1\FSharp.Data.DesignTime.dll'. Impossibile trovare il file specificato.

>

Not even a workaround suggested??

[gusty]

@giuliohome I did open the suggestion as @ovatsus advised.

It is here, in case you want to read, comment and/or upvote: https://github.com/fsharp/fslang-suggestions/issues/678

... but yeah, it seems nobody cares.

[giuliohome]

@gusty added my +1 vote. Anyway of course I've had to go on , so I've already moved it from a tentative script to a compiled project (but guys, then don't dare to compare F# to Python, pls come on) and I'm also considering RestSharp instead of FSharp.Data since I'm building a web api client wiht oauth...

[giuliohome]

@gusty out of my curiosity, why is the scripting interpreter fsi failing while the compiled F# project runs fine? In either case that design dll file is missing... So it seems to me more a bug than a feature request.

[gusty]

That's a question for the F# team, but I think it's because scripting is considered design time.

[giuliohome]

Ok, correct, but in a Visual Studio project, at design time, so when I have intellisense before I compile, I don't see any warnings or red wigglers (if I remember well)...

[Slesa]

Sorry to bring this up again - but it not only happens in scripts, but also in projects. And I have absolutely no clue where get this FSharp.Data.DesignTime assembly from? I wanted to show the TPs to a colleague to convince him of trying out F# for the first time. It is a .NET 4.8 project.

[giuliohome]

@Slesa, I've tested FSharp.Data in a .NET Core 7 project, and it works perfectly. The issue discussed in this thread is solely related to scripting, and there are no problems with projects. The compatibility of FSharp.Data with .NET Framework 4.8 is also documented, as indicated here: https://stackoverflow.com/a/69498122.

[Slesa]

Thank you, but it does not work. "FSharp.Data.DesignTime cannot be loaded, could not load assembly FSharp.Core 4.7"

[giuliohome]

@Slesa share your repository with your project as a minimal repro example

[Slesa]

While putting a sln together, I found the only working solution for FSharp.data:

<packages>
  <package id="FSharp.Compiler.Tools" version="10.0.2" targetFramework="net45" />
  <package id="FSharp.Data" version="3.3.3" targetFramework="net48" />
  <package id="FSharp.Core" version="4.7.1" targetFramework="net48" />
</packages>

Thanks for your time