Is FSharp.Data needed?

[TheAngryByrd]

Is FSharp.Data a real hard dependency? I only ask because new dotnet proj files fail to build with FSharp.Data dotnet/netcorecli-fsc#16

[lefthandedgoat]

I added a feature for json validation and I use FSharp.Data for that.

canopy won't work with .net core right now either because Selenium doesn't work with .net core

[TheAngryByrd]

Yeah, it won't work with .net core but with the new proj you can set the TargetFramework to net4x and get out a .net full exe and run it with .full/mono like normal. Only it won't compile because of the type provider issue list above with FSharp.Data. (dotnet/netcorecli-fsc#16 (comment))

[lefthandedgoat]

Hm. I haven't kept up with new proj file stuff.

Can you give me steps to repro? I have a VM I can install the latest whatever on.

If push comes to shove I can split this feature out into a sister package.

[TheAngryByrd]

Yeah no problem. Give me a few minutes.

Thanks 🐱

[TheAngryByrd]

https://github.com/TheAngryByrd/canopy-newprojstyle

Install .net/mono and .net core 1.x.
Install chrome and chrome driver

./run.sh or .\run.cmd

Should run a test against stackoverflow.

To recreate issue,

• goto paket.depedencies and change canopy version to 1.4.x.
• .paket\paket.exe install to get the new version
• run again but you should be greeted by a build 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 'FSharp.Data.DesignTime, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
warning FS3005: Referenced assembly 

[lefthandedgoat]

Ok thanks. I will look at after work.

…

On Fri, Jun 16, 2017 at 1:15 PM, Jimmy Byrd ***@***.***> wrote: https://github.com/TheAngryByrd/canopy-newprojstyle Install .net/mono and .net core 1.x. Install chrome and chrome driver ./run.sh or .\run.cmd Should run some a test against stackoverflow. To recreate issue, - goto paket.depedencies and change canopy version to 1.4.x. - .paket\paket.exe install to get the new version - run again but you should be greeted by a build 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 'FSharp.Data.DesignTime, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified. warning FS3005: Referenced assembly — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#371 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsQ6YRfFB1dCh-V4stWUXJ3vFkbIVMYks5sEsZVgaJpZM4N8tzp> .

[lefthandedgoat]

I removed the reference to FSharp.Data and split that into a sister package. You can download 1.50 and you should be good to go! Sorry about that.

[TheAngryByrd]

No.problem! Not your fault. Stupid new tooling and living on the bleeding edge...Thanks a ton!

[baronfel]

It's definitely possible to use Type Providers in projects that are using the new SDK. You just have to invoke MSBuild directly and not through the dotnet sdk. Currently the dotnet build command always invokes the netcore version of FSC, which doesn't support type providers, but when msbuild is invoked instead you'll build fine. I'm doing this on a work project that still targets 461 but uses the new SDK.

so your overall flow is dotnet restore, then msbuild /t:Build, then dotnet pack or whatever your existing deployment strategy is.

[TheAngryByrd]

@baronfel in my case I was using mono, do I need to be on 5.0 to be able to use msbuild then?

[baronfel]

yeah, it's a bit of a complicated matrix. If you want to do the new sdk/project files then you have to migrate to mono 5, because only msbuild 15 understands those files.