New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to enable type providers with new-style .NET SDK project files, dotnet build, .NET Standard and .NET Core programming #3303

Closed
dsyme opened this Issue Jul 4, 2017 · 78 comments

Comments

Projects
None yet
@dsyme
Contributor

dsyme commented Jul 4, 2017

This issue documents how to enable the use of type providers when using a .NET SDK 2.0 "new style" project file.

This also allows the use of cross-targeting type providers as part of .NET Core 2.0 app programming or .NET Standard 2.0 library programming.

If you don't follow one of the workarounds below you may get a silent failure or RunFsc.cmd failed from the F# compiler when executing dotnet build or "StackOverflowException", if your project references a type provider.

What you need to do

  1. Install an F# Compiler that runs on .NET Framework or Mono, see Linux, Windows, OSX. It is likely you already have one installed.

  2. Add the file fsc.props to the root of your project and import it into each of your project files that reference a type provider using something along the lines of: <Import Project="fsc.props" />,

The F# compiler will then run using .NET Framework and/or Mono.

Alternative Workaround

On Windows:

  • Install Visual Studio 2017 15.3 or later
  • Use "msbuild.exe" from a Visual Studio 2017 command line prompt to build the project instead of "dotnet build"

On Linux/OSX/Xamarin/Mono:

  • Install Mono 5.0 or later
  • Use "msbuild" to build the project instead of "dotnet build"

Explanation: when you compile your project using msbuild.exe the F# support in the .NET SDK will assume .NET Framework execution of the F# compiler is required. This workaround is also compatible with using an fsc.props file as mentioned above.

Examples where the problem occurs

Example 1 (building a .NET 4.6.1 application that uses FSharp.Data)

dotnet new console -o -lang F# --target-framework-override net461 app3
cd app3
dotnet add package FSharp.Data
dotnet restore
dotnet build

Example 2 (building a .NET Core 2.0 application that uses FSharp.Data)

dotnet new console -o -lang F# app4
cd app4
dotnet add package FSharp.Data
dotnet restore
dotnet build

Expected behaviour is compilation success, or at least nice error point to workaround. Actual behavior is a silent compilation failure, and dotnet build /v:d shows l Process is terminating due to StackOverflowException. Done executing task "Fsc" -- FAILED.

Explanation

As explained in this issue, type providers are not yet supported when the F# compiler runs using .NET Core. By default, the .NET SDK tooling runs the F# compiler using .NET Core.

The workaround is to have the .NET SDK tooling use an F# Compiler running on the .NET Framework or Mono, regardless of which version of .NET you're targeting. By doing this, the type provider is hosted and executed using the .NET Framework. This technique applies even if you are doing .NET Core programming (for cross-targeting type providers), or building a .NET Standard 2.0 library. The F# Compiler cross-generates code for the correct target regardless of how it executes.

Although this workaround may seem "wrong" if targeting .NET Core, it has advantages:

  • the use of .NET Framework/Mono is only at compile-time
  • the technique stress-tests the cross-targeting capabilities of the type provider
  • the technique unblocks TP authors to test and adjust TPs to be cross-targeting

In the future, the plan of record is to allow .NET Standard 2.0 type providers to be used when the F# compiler is running on .NET Core. This is an interim workaround for those who wish to unblock the testing and use of type providers for .NET SDK project files and .NET Core/.NET Standard 2.0 programming.

@dsyme dsyme changed the title from StackOverflow when F# compiler in .NET SDK references FSHarp.Data.TypeProviders to StackOverflow when F# compiler in .NET SDK references FSharp.Data.TypeProviders or FSharp.Data Jul 4, 2017

@dsyme dsyme changed the title from StackOverflow when F# compiler in .NET SDK references FSharp.Data.TypeProviders or FSharp.Data to StackOverflow when F# compiler in .NET SDK 2.0 preview 2 references FSharp.Data.TypeProviders or FSharp.Data Jul 4, 2017

@dsyme dsyme changed the title from StackOverflow when F# compiler in .NET SDK 2.0 preview 2 references FSharp.Data.TypeProviders or FSharp.Data to StackOverflow when F# compiler in .NET SDK 2.0-style project file references a type provider - must use "msbuild"/"xbuild" NOT "dotnet" to build Jul 4, 2017

@dsyme dsyme changed the title from StackOverflow when F# compiler in .NET SDK 2.0-style project file references a type provider - must use "msbuild"/"xbuild" NOT "dotnet" to build to When using .NET SDK 2.0-style project file and you reference a type provider you must use "msbuild"/"xbuild" NOT "dotnet" to build Jul 4, 2017

@dsyme dsyme changed the title from When using .NET SDK 2.0-style project file and you reference a type provider you must use "msbuild"/"xbuild" NOT "dotnet" to build to When using .NET SDK 2.0-style project file and you reference a type provider you must use "msbuild" NOT "dotnet" to build Jul 4, 2017

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 4, 2017

Contributor

Note, I think we can have a better setting for FscToolPath which works on both Windows and Mono, though it needs a conditional to determine the right location

Contributor

dsyme commented Jul 4, 2017

Note, I think we can have a better setting for FscToolPath which works on both Windows and Mono, though it needs a conditional to determine the right location

@dsyme dsyme changed the title from When using .NET SDK 2.0-style project file and you reference a type provider you must use "msbuild" NOT "dotnet" to build to If a .NET SDK 2.0-style project file references a type provider you must use "msbuild" NOT "dotnet" to build Jul 4, 2017

@dsyme dsyme changed the title from If a .NET SDK 2.0-style project file references a type provider you must use "msbuild" NOT "dotnet" to build to If a .NET SDK 2.0-style project file references a type provider you must use "msbuild" NOT "dotnet build" to build Jul 4, 2017

@larjo

This comment has been minimized.

Show comment
Hide comment
@larjo

larjo Jul 4, 2017

Thanks @dsyme!

The FscToolPath/FscToolExe workaround seems to work just fine even with SDK 1.0.4.

larjo commented Jul 4, 2017

Thanks @dsyme!

The FscToolPath/FscToolExe workaround seems to work just fine even with SDK 1.0.4.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 4, 2017

Contributor

@cartermp @KevinRansom As I've now documented in the issue description, it is possible to use the above technique to enable type providers for .NET Core programming, as long as the type providers have been written as a cross targeting type provider. The main cross-targeting type provider is FSharp.Data.

Here are the steps I used to verify that this can be used with .NET Core 2.0 programming:

  • dotnet new console -o -lang F# tpapp2
  • cd tpapp2
  • dotnet add package FSharp.Data
  • dotnet restore
  • edit the .fs to contain
open System
open FSharp.Data

type NugetStats = HtmlProvider<"https://www.nuget.org/packages/FSharp.Data">

let rawStats = NugetStats().Tables.``Version History``

rawStats.Rows |> Seq.iter (printfn "row = %A")
  • edit the tpapp2.fsproj to contain
    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  • dotnet build
  • dotnet run

output:

row = ("F# Data 2.3.3 (this version)", 22954M, 10/04/2017 00:00:00)
...
row = ("FSharp.Data 1.0.2", 234M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.1", 187M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.0", 469M, 13/12/2012 00:00:00)

🎉🎉🎉🎉 we have used type providers for .NET Core programming for the first time :)

Notes:

  • When using VSCode/Ionide you also get full intellisense:

  • The above technique also works for .NET Standard 2.0 programming (dotnet new lib -lang F# tplib1). However at the time of writing you need an F# compiler that includes this fix, e.g. use Visual Studio 2017 preview 3, or use an F# compiler built from source. I tested with <FscToolPath>C:\GitHub\dsyme\visualfsharp\release\net40\bin</FscToolPath>

  • You get some warnings because FSharp.Data for .NET 4.x is being used. However it should be possible to produce a fully compliant .NET Standard 2.0 version of FSharp.Data, that is TBD, and until then the .NET Framework version is not that likely to cause major problems since the surface area of FSharp.Dataa is relatively low

image

Contributor

dsyme commented Jul 4, 2017

@cartermp @KevinRansom As I've now documented in the issue description, it is possible to use the above technique to enable type providers for .NET Core programming, as long as the type providers have been written as a cross targeting type provider. The main cross-targeting type provider is FSharp.Data.

Here are the steps I used to verify that this can be used with .NET Core 2.0 programming:

  • dotnet new console -o -lang F# tpapp2
  • cd tpapp2
  • dotnet add package FSharp.Data
  • dotnet restore
  • edit the .fs to contain
open System
open FSharp.Data

type NugetStats = HtmlProvider<"https://www.nuget.org/packages/FSharp.Data">

let rawStats = NugetStats().Tables.``Version History``

rawStats.Rows |> Seq.iter (printfn "row = %A")
  • edit the tpapp2.fsproj to contain
    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  • dotnet build
  • dotnet run

output:

row = ("F# Data 2.3.3 (this version)", 22954M, 10/04/2017 00:00:00)
...
row = ("FSharp.Data 1.0.2", 234M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.1", 187M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.0", 469M, 13/12/2012 00:00:00)

🎉🎉🎉🎉 we have used type providers for .NET Core programming for the first time :)

Notes:

  • When using VSCode/Ionide you also get full intellisense:

  • The above technique also works for .NET Standard 2.0 programming (dotnet new lib -lang F# tplib1). However at the time of writing you need an F# compiler that includes this fix, e.g. use Visual Studio 2017 preview 3, or use an F# compiler built from source. I tested with <FscToolPath>C:\GitHub\dsyme\visualfsharp\release\net40\bin</FscToolPath>

  • You get some warnings because FSharp.Data for .NET 4.x is being used. However it should be possible to produce a fully compliant .NET Standard 2.0 version of FSharp.Data, that is TBD, and until then the .NET Framework version is not that likely to cause major problems since the surface area of FSharp.Dataa is relatively low

image

@dsyme dsyme referenced this issue Jul 4, 2017

Closed

.NET Core Support #943

@dsyme dsyme changed the title from If a .NET SDK 2.0-style project file references a type provider you must use "msbuild" NOT "dotnet build" to build to How to enable type providers with new-style .NET SDK project files Jul 4, 2017

@dsyme dsyme changed the title from How to enable type providers with new-style .NET SDK project files to How to enable type providers with new-style .NET SDK project files (and in some cases .NET Core programming) Jul 5, 2017

@dsyme dsyme changed the title from How to enable type providers with new-style .NET SDK project files (and in some cases .NET Core programming) to How to enable type providers with new-style .NET SDK project files (and in some cases .NET Core programming too) Jul 5, 2017

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Jul 7, 2017

@dsyme you are the freaking man! If I'm ever at a conference you're speaking at dinner one night is on me...

So I journeyed into the matrix to get my application running inside a Docker container on Linux despite it's heavy JSON Type Provider usage due to your workaround and I'm happy to report it works like a champion!

Pros:
This workaround is elegant, nice, and awesome
Runs in Docker on Linux!!!!!
Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core
I can still write all my build scripts for the build servers to be dotnet cli compliant

Cons:
There were 3 things that came up and I've attached a screenshot for all of them to see if I'm doing something wrong..

  1. FSC was complaining about netstandard2.0 but it works when I put in netcoreapp2.0
    fsc_netstandard_error

  2. NuGet shows no packages installed for F#
    nuget_shows_nopkgs

  3. My Intellisense is broken but I'm pretty certain this probably has something to do with item 2
    vs_errors_netcore2

The only other con was dotnet build, run, restore, publish all throw errors when I include the docker-compose.dcproj file in the .sln file. I have read that is because the SDK hasn't been open sourced which is a requirement to be included in the tool chain. This is not a concern as I can simply script the commands to all run against the top level project file rather than the solution.

I have a feeling my cons are entirely a PEBCAK and I've thought up workarounds in the event they are not. I'm still way happier about actually being able to build out my services against dockerswarm on Linux and still being able to use the Type Providers.

Regards,
Brian

buvinghausen commented Jul 7, 2017

@dsyme you are the freaking man! If I'm ever at a conference you're speaking at dinner one night is on me...

So I journeyed into the matrix to get my application running inside a Docker container on Linux despite it's heavy JSON Type Provider usage due to your workaround and I'm happy to report it works like a champion!

Pros:
This workaround is elegant, nice, and awesome
Runs in Docker on Linux!!!!!
Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core
I can still write all my build scripts for the build servers to be dotnet cli compliant

Cons:
There were 3 things that came up and I've attached a screenshot for all of them to see if I'm doing something wrong..

  1. FSC was complaining about netstandard2.0 but it works when I put in netcoreapp2.0
    fsc_netstandard_error

  2. NuGet shows no packages installed for F#
    nuget_shows_nopkgs

  3. My Intellisense is broken but I'm pretty certain this probably has something to do with item 2
    vs_errors_netcore2

The only other con was dotnet build, run, restore, publish all throw errors when I include the docker-compose.dcproj file in the .sln file. I have read that is because the SDK hasn't been open sourced which is a requirement to be included in the tool chain. This is not a concern as I can simply script the commands to all run against the top level project file rather than the solution.

I have a feeling my cons are entirely a PEBCAK and I've thought up workarounds in the event they are not. I'm still way happier about actually being able to build out my services against dockerswarm on Linux and still being able to use the Type Providers.

Regards,
Brian

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Jul 7, 2017

The PEBCAK is that I couldn't read.... vscode/ionide I will leave the items up here just in case we want the VS team to see they are very close.

buvinghausen commented Jul 7, 2017

The PEBCAK is that I couldn't read.... vscode/ionide I will leave the items up here just in case we want the VS team to see they are very close.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jul 7, 2017

Contributor

Not sure about (2), but (3) is due to an issue in the language service. #3260 is tracking that issue, and @KevinRansom is currently working on it. This is wonderful to hear, though, @buvinghausen! Happy to hear that it's working for you in Docker/Linux.

Contributor

cartermp commented Jul 7, 2017

Not sure about (2), but (3) is due to an issue in the language service. #3260 is tracking that issue, and @KevinRansom is currently working on it. This is wonderful to hear, though, @buvinghausen! Happy to hear that it's working for you in Docker/Linux.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jul 7, 2017

Contributor

Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core

Atm will work also on non windows, using mono. two big ways:

  1. use mono on dev on non win. same workaround

  2. use docker multi stage setup

    • build a mono docker image for build, build there => get output
    • run run the build output in another container with just .net core

pro of 2 is that with multi stage, the image size contains only netcore (use official dotnet core docker image) and is slimmer

maybe i should gist the dockerfile i use for that. is a good setup, also for ci who are docker based (we use jenkins).

Contributor

enricosada commented Jul 7, 2017

Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core

Atm will work also on non windows, using mono. two big ways:

  1. use mono on dev on non win. same workaround

  2. use docker multi stage setup

    • build a mono docker image for build, build there => get output
    • run run the build output in another container with just .net core

pro of 2 is that with multi stage, the image size contains only netcore (use official dotnet core docker image) and is slimmer

maybe i should gist the dockerfile i use for that. is a good setup, also for ci who are docker based (we use jenkins).

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jul 7, 2017

Contributor

@dsyme as a note, dotnet new lib -lang F# works the same of classlib, and is less wierd 😄

Contributor

enricosada commented Jul 7, 2017

@dsyme as a note, dotnet new lib -lang F# works the same of classlib, and is less wierd 😄

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Jul 7, 2017

@cartermp thanks for the clarification I'm actually working on getting VS Code launch & debug into the Docker container like I can from VS 2017 then I may just cut the cord on VS full I've been looking for an excuse to do that as I have been using VS Code exclusively for TypeScript development.

@enricosada Those are some excellent points but for now I'm totally happy with simply making my CI server run on Windows and letting the FE developers run everything in Node but talking to our integration services on the back end. That should give me enough runway to let all the frameworks and tooling catch up such that I can then tell them they have to install .NET Core & OmniSharp and learn the dotnet cli. As an aside I think today is the day that I'm going to see how feasible it is to run the React Redux template in Docker. I know when you create the project they have the docker option disabled. Should be fun.

I really appreciate all the work you guys are putting into this platform I cannot stress that enough it really is amazing to think what the future holds.

buvinghausen commented Jul 7, 2017

@cartermp thanks for the clarification I'm actually working on getting VS Code launch & debug into the Docker container like I can from VS 2017 then I may just cut the cord on VS full I've been looking for an excuse to do that as I have been using VS Code exclusively for TypeScript development.

@enricosada Those are some excellent points but for now I'm totally happy with simply making my CI server run on Windows and letting the FE developers run everything in Node but talking to our integration services on the back end. That should give me enough runway to let all the frameworks and tooling catch up such that I can then tell them they have to install .NET Core & OmniSharp and learn the dotnet cli. As an aside I think today is the day that I'm going to see how feasible it is to run the React Redux template in Docker. I know when you create the project they have the docker option disabled. Should be fun.

I really appreciate all the work you guys are putting into this platform I cannot stress that enough it really is amazing to think what the future holds.

@orient-man

This comment has been minimized.

Show comment
Hide comment
@orient-man

orient-man Jul 18, 2017

Thx for the workaround but I encountered another issue:

error FS3033: The type provider 'FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: The .NET SDK 4.0 or 4.5 tools could not be found

Source code tells the truth: SDK paths are fixed. On my relatively new machine (or on VSTS agent) there're no such registry keys. I added new ones (which existed on my machine):

@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools"
@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools"

and now it works. Are you interested in pull request for that change?

orient-man commented Jul 18, 2017

Thx for the workaround but I encountered another issue:

error FS3033: The type provider 'FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: The .NET SDK 4.0 or 4.5 tools could not be found

Source code tells the truth: SDK paths are fixed. On my relatively new machine (or on VSTS agent) there're no such registry keys. I added new ones (which existed on my machine):

@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools"
@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools"

and now it works. Are you interested in pull request for that change?

@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Jul 19, 2017

My solution currently to finding the proper fsc.exe on macOS/Linux is to use a small helper script under my ./tools dir called fsharpc.exe

#!/bin/sh
fsharpc "$@"

or if you want more control over your fsc.exe version by using nuget/paket

#!/bin/sh
mono $(git rev-parse --show-toplevel)/packages/build/FSharp.Compiler.Tools/tools/fsc.exe --exename:$(basename "$0") "$@"

Then my project file

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
  <PropertyGroup Condition="$(OS)=='Unix'">
    <FscToolPath>../../tools</FscToolPath>
    <FscToolExe>fsharpc.exe</FscToolExe>
  </PropertyGroup>

All it does it delegate to fsharpc, another shell script usually installed my mono and put on the path. For some reason the tooling is looking for an .exe at the end and won't execute the script without it. I saw it once somewhere but I can't remember where it was doing the check.

This seems to work with:

$ mono -V
Mono JIT compiler version 4.8.1 (mono-4.8.0-branch/22a39d7 Fri Apr  7 12:00:08 EDT 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.6.0svn-mono-master/8b1520c)
	GC:            sgen
$ dotnet --info
.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

Libs I've tested so far:
FSharp.Data
FSharp.Configuration
FSharp.Management

Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs

  <Target Name="Copy MDBs"
          Condition="$(OS)=='Unix'"
          AfterTargets="Build">
         <Copy SourceFiles="$(IntermediateOutputPath)/$(AssemblyName).exe.mdb" DestinationFolder="$(OutputPath)" ContinueOnError="true" />
  </Target>

TheAngryByrd commented Jul 19, 2017

My solution currently to finding the proper fsc.exe on macOS/Linux is to use a small helper script under my ./tools dir called fsharpc.exe

#!/bin/sh
fsharpc "$@"

or if you want more control over your fsc.exe version by using nuget/paket

#!/bin/sh
mono $(git rev-parse --show-toplevel)/packages/build/FSharp.Compiler.Tools/tools/fsc.exe --exename:$(basename "$0") "$@"

Then my project file

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
  <PropertyGroup Condition="$(OS)=='Unix'">
    <FscToolPath>../../tools</FscToolPath>
    <FscToolExe>fsharpc.exe</FscToolExe>
  </PropertyGroup>

All it does it delegate to fsharpc, another shell script usually installed my mono and put on the path. For some reason the tooling is looking for an .exe at the end and won't execute the script without it. I saw it once somewhere but I can't remember where it was doing the check.

This seems to work with:

$ mono -V
Mono JIT compiler version 4.8.1 (mono-4.8.0-branch/22a39d7 Fri Apr  7 12:00:08 EDT 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.6.0svn-mono-master/8b1520c)
	GC:            sgen
$ dotnet --info
.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

Libs I've tested so far:
FSharp.Data
FSharp.Configuration
FSharp.Management

Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs

  <Target Name="Copy MDBs"
          Condition="$(OS)=='Unix'"
          AfterTargets="Build">
         <Copy SourceFiles="$(IntermediateOutputPath)/$(AssemblyName).exe.mdb" DestinationFolder="$(OutputPath)" ContinueOnError="true" />
  </Target>
@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 19, 2017

Contributor

@TheAngryByrd Thanks for that info

Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs...

@KevinRansom It seems this should be part of standard F# targets?

Contributor

dsyme commented Jul 19, 2017

@TheAngryByrd Thanks for that info

Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs...

@KevinRansom It seems this should be part of standard F# targets?

@rfrerebe

This comment has been minimized.

Show comment
Hide comment
@rfrerebe

rfrerebe Jul 20, 2017

Repo with instructions to enable the workaround : https://github.com/rfrerebe/TypeProviderDotNetCorePreview2

rfrerebe commented Jul 20, 2017

Repo with instructions to enable the workaround : https://github.com/rfrerebe/TypeProviderDotNetCorePreview2

@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Jul 21, 2017

One thing I've also noticed is I don't get incremental build support using that macos/linux workaround. Is there something else I need to set or is it just not supported?

i.e. normal .net core builds

Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.

TheAngryByrd commented Jul 21, 2017

One thing I've also noticed is I don't get incremental build support using that macos/linux workaround. Is there something else I need to set or is it just not supported?

i.e. normal .net core builds

Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Jul 24, 2017

Seems like the fsc.exe shipped with mono 4.8 is still 4.4.0.0

monodis --assembly  /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe 
Assembly Table
Name:          fsc
Hash Algoritm: 0x00008004
Version:       4.4.0.0
Flags:         0x00008001
PublicKey:     BlobPtr (0x000000ea)

Even though it reports it's the compiler for 4.1

mono /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe
F# Compiler for F# 4.1

Either using mono 5.0.1's version or downloading the latest FSharp.Compiler.Tools from nuget doesn't have the project rebuild every single time.

TheAngryByrd commented Jul 24, 2017

Seems like the fsc.exe shipped with mono 4.8 is still 4.4.0.0

monodis --assembly  /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe 
Assembly Table
Name:          fsc
Hash Algoritm: 0x00008004
Version:       4.4.0.0
Flags:         0x00008001
PublicKey:     BlobPtr (0x000000ea)

Even though it reports it's the compiler for 4.1

mono /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe
F# Compiler for F# 4.1

Either using mono 5.0.1's version or downloading the latest FSharp.Compiler.Tools from nuget doesn't have the project rebuild every single time.

@ryukinix

This comment has been minimized.

Show comment
Hide comment
@ryukinix

ryukinix Aug 9, 2017

I need to do something specific to running on SDK 1.0.4 and targetting netcoreapp1.1? Trying target to net462 give me a issue on dotnet run:

❯ dotnet run
/opt/dotnet/sdk/1.0.4/Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.2" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/home/lerax/Desktop/dchart/backend/backend.fsproj]

The build failed. Please fix the build errors and run again.

I should able to compile and running with mono, but is not working when I try running with .NET Core. My setup is .NET Core SDK 1.0.4 and .NET Core runtime 1.1.2 on Linux.

ryukinix commented Aug 9, 2017

I need to do something specific to running on SDK 1.0.4 and targetting netcoreapp1.1? Trying target to net462 give me a issue on dotnet run:

❯ dotnet run
/opt/dotnet/sdk/1.0.4/Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.2" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/home/lerax/Desktop/dchart/backend/backend.fsproj]

The build failed. Please fix the build errors and run again.

I should able to compile and running with mono, but is not working when I try running with .NET Core. My setup is .NET Core SDK 1.0.4 and .NET Core runtime 1.1.2 on Linux.

@jindraivanek

This comment has been minimized.

Show comment
Hide comment
@jindraivanek

jindraivanek Aug 10, 2017

Alternatively, fsc can be obtained from FSharp.Compiler.Tools nuget. With Paket:

paket.dependencies:
nuget FSharp.Compiler.Tools

.fsproj:

  <PropertyGroup>
    <FscToolPath>../packages/FSharp.Compiler.Tools/tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>```

Tested on Windows 7, but it should work cross-platform (?)

jindraivanek commented Aug 10, 2017

Alternatively, fsc can be obtained from FSharp.Compiler.Tools nuget. With Paket:

paket.dependencies:
nuget FSharp.Compiler.Tools

.fsproj:

  <PropertyGroup>
    <FscToolPath>../packages/FSharp.Compiler.Tools/tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>```

Tested on Windows 7, but it should work cross-platform (?)
@ryukinix

This comment has been minimized.

Show comment
Hide comment
@ryukinix

ryukinix Aug 10, 2017

@jindraivanek you are targetting to which framework? (I just want know)

ryukinix commented Aug 10, 2017

@jindraivanek you are targetting to which framework? (I just want know)

@dsyme dsyme changed the title from How to enable type providers with new-style .NET SDK project files, ``dotnet build``, .NET Standard and .NET Core programming to How to enable type providers with new-style .NET SDK project files, dotnet build, .NET Standard and .NET Core programming Feb 23, 2018

@alfonsogarciacaro

This comment has been minimized.

Show comment
Hide comment
@alfonsogarciacaro

alfonsogarciacaro Mar 1, 2018

Contributor

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

Contributor

alfonsogarciacaro commented Mar 1, 2018

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Mar 2, 2018

Contributor

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

Could you create a repro ZIP please? AFAIK this should work, but we need more details on the TP package layout, and whether FCS is running on .NET Core or .NET Framework.

Contributor

dsyme commented Mar 2, 2018

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

Could you create a repro ZIP please? AFAIK this should work, but we need more details on the TP package layout, and whether FCS is running on .NET Core or .NET Framework.

@alfonsogarciacaro

This comment has been minimized.

Show comment
Hide comment
@alfonsogarciacaro

alfonsogarciacaro Mar 3, 2018

Contributor

@dsyme I've created a test repo and listed the steps to reproduce in the README. FCS 20.0.1 didn't recognize the erased member when parsing the project, but the good news is... FCS 21.0.1 does! 🎉

Contributor

alfonsogarciacaro commented Mar 3, 2018

@dsyme I've created a test repo and listed the steps to reproduce in the README. FCS 20.0.1 didn't recognize the erased member when parsing the project, but the good news is... FCS 21.0.1 does! 🎉

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Mar 12, 2018

Contributor

@alfonsogarciacaro That's great, thanks

Contributor

dsyme commented Mar 12, 2018

@alfonsogarciacaro That's great, thanks

@Thorium

This comment has been minimized.

Show comment
Hide comment
@Thorium

Thorium Mar 26, 2018

Contributor

Are FscToolPath and FscToolExe properties still needed?
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
seems to have changed. There would be this:
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0</FscToolPath>
Is it compatible?
Do I have to update all the project files and all the documentations?

Contributor

Thorium commented Mar 26, 2018

Are FscToolPath and FscToolExe properties still needed?
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
seems to have changed. There would be this:
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0</FscToolPath>
Is it compatible?
Do I have to update all the project files and all the documentations?

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Mar 26, 2018

Contributor
Contributor

KevinRansom commented Mar 26, 2018

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Apr 6, 2018

@dsyme I'm happy to report that @tpetricek released the 3.0 beta two days ago which supports .netstandard2 out of the box. We have already upgraded our applications to use the 3.0 beta and removed the fsc.props and everything is still going green. I think you can safely close this topic and say go get it here NuGet FSharp.Data

buvinghausen commented Apr 6, 2018

@dsyme I'm happy to report that @tpetricek released the 3.0 beta two days ago which supports .netstandard2 out of the box. We have already upgraded our applications to use the 3.0 beta and removed the fsc.props and everything is still going green. I think you can safely close this topic and say go get it here NuGet FSharp.Data

@tpetricek

This comment has been minimized.

Show comment
Hide comment
@tpetricek

tpetricek Apr 6, 2018

Contributor

I don't deserve any credit here :-) all the fantastic work on F# Data has been done by @ovatsus and @dsyme !

Contributor

tpetricek commented Apr 6, 2018

I don't deserve any credit here :-) all the fantastic work on F# Data has been done by @ovatsus and @dsyme !

@ovatsus

This comment has been minimized.

Show comment
Hide comment
@ovatsus

ovatsus Apr 6, 2018

Actually it was @dsyme and @baronfel, I just basically clicked the merge button :)

ovatsus commented Apr 6, 2018

Actually it was @dsyme and @baronfel, I just basically clicked the merge button :)

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Apr 6, 2018

Well cheers to all! Fantastic work

buvinghausen commented Apr 6, 2018

Well cheers to all! Fantastic work

@NullVoxPopuli

This comment has been minimized.

Show comment
Hide comment
@NullVoxPopuli

NullVoxPopuli Apr 13, 2018

I have the Fsharp.Data 3.0 beta and I still have this issue: :-\

Here is my travis log for the failed build: https://travis-ci.org/NullVoxPopuli/CryptoExchangeClient/builds/366058602 (just trying to get linux support working, the master branch works on windows)

I searched the paket.lock, and all occurrences of FSharp.Data are the latest beta.

Locally, I get this:

$ ./run test
# scripted-alias for:
# (cd tests/Test.CryptoExchangeClient && dotnet test Test.CryptoExchangeClient.fsproj)

Build started, please wait...
/usr/share/dotnet/sdk/2.0.0/FSharp/Microsoft.FSharp.Targets(224,9): error MSB6006: "RunFsc.sh" exited with code 134. 
[/home/me/Development/NullVoxPopuli/CryptoExchangeClient/src/CryptoExchangeClient.fsproj]

On Travis I get this:

Build started, please wait...
/usr/share/dotnet/sdk/2.0.0/FSharp/Microsoft.FSharp.Targets(224,9): error MSB6006: "RunFsc.sh" exited with code 134.
 [/home/travis/build/NullVoxPopuli/CryptoExchangeClient/src/CryptoExchangeClient.fsproj]

NullVoxPopuli commented Apr 13, 2018

I have the Fsharp.Data 3.0 beta and I still have this issue: :-\

Here is my travis log for the failed build: https://travis-ci.org/NullVoxPopuli/CryptoExchangeClient/builds/366058602 (just trying to get linux support working, the master branch works on windows)

I searched the paket.lock, and all occurrences of FSharp.Data are the latest beta.

Locally, I get this:

$ ./run test
# scripted-alias for:
# (cd tests/Test.CryptoExchangeClient && dotnet test Test.CryptoExchangeClient.fsproj)

Build started, please wait...
/usr/share/dotnet/sdk/2.0.0/FSharp/Microsoft.FSharp.Targets(224,9): error MSB6006: "RunFsc.sh" exited with code 134. 
[/home/me/Development/NullVoxPopuli/CryptoExchangeClient/src/CryptoExchangeClient.fsproj]

On Travis I get this:

Build started, please wait...
/usr/share/dotnet/sdk/2.0.0/FSharp/Microsoft.FSharp.Targets(224,9): error MSB6006: "RunFsc.sh" exited with code 134.
 [/home/travis/build/NullVoxPopuli/CryptoExchangeClient/src/CryptoExchangeClient.fsproj]

sergey-tihon added a commit to sergey-tihon/FSharp.Configuration that referenced this issue Apr 22, 2018

@psfinaki

This comment has been minimized.

Show comment
Hide comment
@psfinaki

psfinaki Apr 25, 2018

Thank you very much! Get it to work in my stuff. Great job :)

psfinaki commented Apr 25, 2018

Thank you very much! Get it to work in my stuff. Great job :)

@nojaf

This comment has been minimized.

Show comment
Hide comment
@nojaf

nojaf Jun 5, 2018

Is the Fsc.prop fix still required when using dotnet SDK 2.1.300 but using netcoreapp2.0 packages?

nojaf commented Jun 5, 2018

Is the Fsc.prop fix still required when using dotnet SDK 2.1.300 but using netcoreapp2.0 packages?

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jun 5, 2018

Contributor

Is the Fsc.prop fix still required when using dotnet SDK 2.1.300 but using netcoreapp2.0 packages?

No, it shouldn't be needed

Contributor

dsyme commented Jun 5, 2018

Is the Fsc.prop fix still required when using dotnet SDK 2.1.300 but using netcoreapp2.0 packages?

No, it shouldn't be needed

@buvinghausen

This comment has been minimized.

Show comment
Hide comment
@buvinghausen

buvinghausen Jun 5, 2018

We've been using FSharp.Data 3.0 beta with every SDK 2.1.300 release from preview1, preview2, rc1, and rtm all without issue it's been awesome. That's with devs using both OSX and WIndows along with our build server & deployment servers all running in Docker on Linux. We're using it for both XML & JSON provider scenarios extensively.

buvinghausen commented Jun 5, 2018

We've been using FSharp.Data 3.0 beta with every SDK 2.1.300 release from preview1, preview2, rc1, and rtm all without issue it's been awesome. That's with devs using both OSX and WIndows along with our build server & deployment servers all running in Docker on Linux. We're using it for both XML & JSON provider scenarios extensively.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jul 29, 2018

Contributor

Closing this, as Type Providers are now supported as .NET Standard components

Contributor

cartermp commented Jul 29, 2018

Closing this, as Type Providers are now supported as .NET Standard components

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 1, 2018

@cartermp I think you claimed victory too early
fsprojects/FSharp.TypeProviders.SDK#244
Hopefully it will get fixed soon.

dmitry-a-morozov commented Aug 1, 2018

@cartermp I think you claimed victory too early
fsprojects/FSharp.TypeProviders.SDK#244
Hopefully it will get fixed soon.

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Aug 1, 2018

Contributor

@dmitry-a-morozov

Here is an example of using the dotnet sdk to create and consume a Type Provider nuget package.

https://github.com/Microsoft/visualfsharp/tree/master/tests/EndToEndBuildTests/BasicProvider

Let me know if this helps.
Kevin

Contributor

KevinRansom commented Aug 1, 2018

@dmitry-a-morozov

Here is an example of using the dotnet sdk to create and consume a Type Provider nuget package.

https://github.com/Microsoft/visualfsharp/tree/master/tests/EndToEndBuildTests/BasicProvider

Let me know if this helps.
Kevin

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 1, 2018

@KevinRansom This is no helpful because it's essentially same as https://github.com/fsprojects/FSharp.TypeProviders.SDK/tree/master/examples and doesn't have any external dependencies.
I need an example with TPDTC dependency on external assembly (ideally a nuget package).

dmitry-a-morozov commented Aug 1, 2018

@KevinRansom This is no helpful because it's essentially same as https://github.com/fsprojects/FSharp.TypeProviders.SDK/tree/master/examples and doesn't have any external dependencies.
I need an example with TPDTC dependency on external assembly (ideally a nuget package).

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Aug 1, 2018

Contributor

@dmitry-a-morozov

So your goal is for the DesignTime guy to resolve types from a separate nuget package. I don't believe that is a supported scenario. If I remember correctly, the design requires the tools to be fully specified, I.e. all of their dep[endencies reachable from the tools directory or tp directory of the nuget package.

I am working on a compilertools switch which should allow tool dependencies like type providers and their dependencies to be specified. I am not sure whether that will address this though.

Kevin

Contributor

KevinRansom commented Aug 1, 2018

@dmitry-a-morozov

So your goal is for the DesignTime guy to resolve types from a separate nuget package. I don't believe that is a supported scenario. If I remember correctly, the design requires the tools to be fully specified, I.e. all of their dep[endencies reachable from the tools directory or tp directory of the nuget package.

I am working on a compilertools switch which should allow tool dependencies like type providers and their dependencies to be specified. I am not sure whether that will address this though.

Kevin

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 1, 2018

@KevinRansom Not exactly. My design time component has dependencies like Npgsql
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/master/src/DesignTime/DesignTime.fsproj#L36
But by using <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in build file I copy all required binaries to the same folder as TPDTC.
Current version of F# compiler has breaking change. It doesn't know to load assemblies co-located with TPDTC. I applied workaround suggested by @dsyme
https://twitter.com/dsyme/status/1024420744250515456

But I'm stuck with

error FS1108: The type 'Void' is required here and is unavailable. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.

I described it all in
fsprojects/FSharp.TypeProviders.SDK#244

dmitry-a-morozov commented Aug 1, 2018

@KevinRansom Not exactly. My design time component has dependencies like Npgsql
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/master/src/DesignTime/DesignTime.fsproj#L36
But by using <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in build file I copy all required binaries to the same folder as TPDTC.
Current version of F# compiler has breaking change. It doesn't know to load assemblies co-located with TPDTC. I applied workaround suggested by @dsyme
https://twitter.com/dsyme/status/1024420744250515456

But I'm stuck with

error FS1108: The type 'Void' is required here and is unavailable. You must add a reference to assembly 'System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.

I described it all in
fsprojects/FSharp.TypeProviders.SDK#244

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Aug 1, 2018

Contributor
Contributor

KevinRansom commented Aug 1, 2018

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 1, 2018

Latest commit de10d57 has workaround commented out
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/de10d5749dbdf3d8dfb9292bcaaa245f8da9629b/tests/Tests.fsproj#L10

So it compiles from VS but fails from command line.
I actually wanted to take it step father and place TPDTC in
...\typeproviders\fsharp41\netstandard2.0\FSharp.Data.Npgsql.DesignTime.dll relative to runtime component but legacy location (design time co-located to run-time) doesn't work either.

Follow instructions to run tests.

Honestly I think it's better to extend BasicProvider example to have dependency because it will useful for community as example of managing dependencies. But I'll leave it to your judgement.

dmitry-a-morozov commented Aug 1, 2018

Latest commit de10d57 has workaround commented out
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/de10d5749dbdf3d8dfb9292bcaaa245f8da9629b/tests/Tests.fsproj#L10

So it compiles from VS but fails from command line.
I actually wanted to take it step father and place TPDTC in
...\typeproviders\fsharp41\netstandard2.0\FSharp.Data.Npgsql.DesignTime.dll relative to runtime component but legacy location (design time co-located to run-time) doesn't work either.

Follow instructions to run tests.

Honestly I think it's better to extend BasicProvider example to have dependency because it will useful for community as example of managing dependencies. But I'll leave it to your judgement.

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 1, 2018

@KevinRansom I made some changes to unit test suite so it should run on your machine.
Use this commit
demetrixbio/FSharp.Data.Npgsql@b44df12

Thanks

dmitry-a-morozov commented Aug 1, 2018

@KevinRansom I made some changes to unit test suite so it should run on your machine.
Use this commit
demetrixbio/FSharp.Data.Npgsql@b44df12

Thanks

@boeremak

This comment has been minimized.

Show comment
Hide comment
@boeremak

boeremak Aug 7, 2018

@buvinghausen Thanks for the tip on FSharp.Data beta, it also fixed my issue.

Still a brave new world this Dotnet core. :)

boeremak commented Aug 7, 2018

@buvinghausen Thanks for the tip on FSharp.Data beta, it also fixed my issue.

Still a brave new world this Dotnet core. :)

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 17, 2018

@KevinRansom
Congrats on 15.8 VS release ! Great work.
Do you have any updates on discussion above and fsprojects/FSharp.TypeProviders.SDK#244?

Thanks

//cc @dsyme @cartermp

dmitry-a-morozov commented Aug 17, 2018

@KevinRansom
Congrats on 15.8 VS release ! Great work.
Do you have any updates on discussion above and fsprojects/FSharp.TypeProviders.SDK#244?

Thanks

//cc @dsyme @cartermp

@KevinRansom

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Aug 17, 2018

Contributor

@dmitry-a-morozov It's on my list of things to resolve. I'm afraid I have no details about when :-(

Contributor

KevinRansom commented Aug 17, 2018

@dmitry-a-morozov It's on my list of things to resolve. I'm afraid I have no details about when :-(

@dmitry-a-morozov

This comment has been minimized.

Show comment
Hide comment
@dmitry-a-morozov

dmitry-a-morozov Aug 17, 2018

@KevinRansom I understand. Keep me posted.

dmitry-a-morozov commented Aug 17, 2018

@KevinRansom I understand. Keep me posted.

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