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

Can't get the most basic example in docs to compile #248

Open
pracplayopen opened this issue Oct 18, 2024 · 9 comments
Open

Can't get the most basic example in docs to compile #248

pracplayopen opened this issue Oct 18, 2024 · 9 comments

Comments

@pracplayopen
Copy link

pracplayopen commented Oct 18, 2024

Description

Can't get the most basic example in docs to compile

Repro steps

Please provide the steps required to reproduce the problem

  1. Add reference to SwaggerProvider (using 2.1.3)

  2. use this code straight from the docs:
    https://fsprojects.github.io/SwaggerProvider/#/

open SwaggerProvider

let [<Literal>] Schema = "https://petstore.swagger.io/v2/swagger.json"
type PetStore = OpenApiClientProvider<Schema>

Expected behavior

Would expect this to compile, but it does not.
(this is not my swagger url obviously, but it doesn't matter what url you use since it doesn't compile)

Actual behavior

Compiler gives error 'OpenApiClientProvider was not defined'

Known workarounds

Please provide a description of any known workarounds.

should also note that when browsing the assembly, don't see a class named: OpenApiClientProvider.
tried uninstalling and reinstalling the pkg, but same error.

is the documentation no longer correct? is there a working example somewhere else?

Affected Type Providers

  • [x ] OpenApiClientProvider

Related information

  • Operating system : ubuntu 21.2 jammy
  • .NET Runtime, CoreCLR or Mono Version : targetting dotnet 6.0

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.19 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.35 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.19 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

  • Performance information, links to performance testing scripts n/a
@sergey-tihon
Copy link
Member

Very strange, can you try it with net8?
image

Nuget package provides design/compile type assemblies only for net8 and nestandard2.0. It would be really sad if net7 could not load netstandard binaries.
image

p.s. net7 is no longer supported by MS, and net6 will reach End of Support on November 12, 2024. It make sense to update to net8 SDK

@Thorium
Copy link
Member

Thorium commented Oct 20, 2024

This is really messy from the current whole .NET infrastructure side:

  1. netstandard2.0 has to be there, otherwise nothing works (VS2022 still runs on .NET Framework)
  2. But would you need netstandard2.1 for general .NET (all after "Framework" support, for both libs and typeproviders\fsharp41 e.g. if you compile with dotnet.exe or can it actually use netstandard2.0 also?
  3. What is the advantage then having the same net8, net9, net10 etc versions separately? I guess the advantages will be: (a) some features like DateOnly class are in .NET8 but not in .NET Standard 2.1 and (b) if your reference library is separately using the more recent frameworks, then you need minimum of that to take advantage of those optimizations. So as just for example: Right now FSharp.Core is built on .NET Standard 2.1 also, and if there is anything that is not on .NET Standard 2.0 version (e.g. via conditional compilation) then it means SwaggerProvider on .NET 6 cannot use them even though .NET 6 is compatible with .NET Standard 2.0. Or is it so? What version of FSharp.Core is actually referred in client project in this scenario?

This all leads towards "ok let's build this for all the frameworks ever" which just bloats people's nuget-cache with duplicate code.

@sergey-tihon
Copy link
Member

@Thorium what is the solution? provide binaries for netstandard2.1?

@Thorium
Copy link
Member

Thorium commented Oct 21, 2024

Maybe. Which previous version had typeprovider dlls in net6.0?

@sergey-tihon
Copy link
Member

libs always (after migration from the full framework) was netstandard2.0

during migration from net6 to net8 we replaced ypeproviders\fsharp41\net6 by ypeproviders\fsharp41\net8

@Thorium
Copy link
Member

Thorium commented Oct 21, 2024

This conversation in this issue is based on hypothesis that the migration actually broke the .net6 which can be by @pracplayopen trying to use SwaggerProvider v.2.0.0 instead of current 2.1.3, as that was using .NET6.

As far as I understand:

  • The libs folder is loaded by compiled program at runtime. Because TypeProviders are libraries and not executables, the .netstandard2.0 should always work (however it might be missing some dependency features as mentioned above). These libs versions you see from Nuget.org "Frameworks"-tab.
  • The typeproviders\fsharp41 are loaded by IDE/compiler at design-time/compile time. So there we need to support different environments the different editors use (VS2022 .NET full, dotnet.exe something else, Ionide I think uses dotnet.exe via some kind of proxy, ...). I think it wouldn't hurt too much to build the design-time dll to both net6+net8: This will increase the nuget-package size, but shouldn't end-up to the compiled end-user program.

@pracplayopen
Copy link
Author

pracplayopen commented Oct 21, 2024

pretty sure netstandard isn't an implementation and has no single set of binaries/libraries.
at least some of the netstandards can be implemented by any of framework/mono/dotnet.
thought netstandards going away too. thought it was supposed to be replaced by net6.0?

have no issues building against the library as is, as long as i don't use the types which are missing.
this is the OpenApiClientProvider type in the assembly from nuget, guessing that type is using a language feature not available to most of the sdks.

could test it against 8.0, but w/such a basic thing not working easier to just take your word for it for now.
to actually use this against 8.0 believe would have to upgrade it everywhere, which sort of defeats the point of using a library to save me time. :)

so this isn't resolved but just not a good use of time right now unfortunately. perhaps will revisit later in quarter but thinking we might just go another route that doesn't require this feature at all.

thx for quick response and contextualized comments from all.

@Thorium
Copy link
Member

Thorium commented Oct 21, 2024

@pracplayopen Can you try the most basic sample with SwaggerProvider version 2.0.0 ? Just to be sure this is not e.g. some Ubuntu related problem?

@pracplayopen pracplayopen reopened this Nov 4, 2024
@pracplayopen
Copy link
Author

yes, will try again w/ v2.0

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

3 participants