Skip to content
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

Wsdl type provider doesn't work on clean install of Windows 10 #637

Closed
rojepp opened this issue Sep 19, 2015 · 2 comments
Closed

Wsdl type provider doesn't work on clean install of Windows 10 #637

rojepp opened this issue Sep 19, 2015 · 2 comments

Comments

@rojepp
Copy link
Contributor

rojepp commented Sep 19, 2015

Following the tutorial at https://msdn.microsoft.com/en-us/library/hh156503.aspx, I'm in trouble early on:
screenshot 2015-09-19 22 55 52

The type provider 'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: The .NET SDK 4.0 or 4.5 tools could not be found ConsoleApplication2 c:\users\robert\documents\visual studio 2015\Projects\ConsoleApplication2\ConsoleApplication2\Program.fs 8

This is related to finding sdk locations in https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Data.TypeProviders/Util.fs#L105

I imagine the Sql TP has the same problems for the same reason (finding SqlMetal.exe), but I haven't tested it.

@piers7
Copy link

piers7 commented Oct 18, 2017

As far as I can see, the version of the type providers that ships with VS 2017.3 still doesn't have this fix in it. I had the same error, and I looked at the IL for the Wsdl Provider (in C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.3.0.0\Type Providers) it looks to me like the original 'two locations' strategy, not the fixed version from PR 638 that checks for the SDK in more locations. Maybe I'm just referencing the wrong dll, but this is the only one I could find (and the one that appears in VS 2017's Add Reference dialog, on my new laptop)

Assembly I'm looking in:
// Type: Microsoft.FSharp.Data.TypeProviders.Utility.Util
// Assembly: FSharp.Data.TypeProviders, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// MVID: 5011D889-858F-C49F-A745-038389D81150
// Assembly location: C:\Program Files (x86)\Reference Assemblies\Microsoft\FSharp.NETFramework\v4.0\4.3.0.0\Type Providers\FSharp.Data.TypeProviders.dll

I reference nuget FSharp.Data.TypeProviders, 5.0.0.2, the problem goes away, which makes me strongly suspect that this fix has never made it's way into an OOB release, and anyone struggling with this should probably reference the nuget instead.

@dsyme
Copy link
Contributor

dsyme commented Nov 6, 2017

I reference nuget FSharp.Data.TypeProviders, 5.0.0.2, the problem goes away

Yes, you should reference the nuget package from now on

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants