Phillip Carter

Seems like a reasonable addition. This might have to be one of the last steps in the migration piece. To do it right though, you'll need to parse the file...

@Lohnegrim I believe removing it would probably be the best course of action. I'm not sure we can have this tool support things that older (often deprecated) VS tooling would...

In the long run we'll support converting C++/CLI projects, but since packagereferences aren't supported for them in VS yet (coming in 16.9 I believe), many of them would not be...

I'm not entirely sure, but it may be able to do that in theory. I'd recommend reaching out to https://github.com/dotnet/project-system/

@forki There is no replacement, as that was never a supported scenario in the first place. I'd encourage never installing that package.

Realistically there's probably a bug in either the type provider, the provider sdk, or F# compiler that needs to be resolved. Using an unsupported package containing a very old .NET...

I would highly recommend not using FCT. Chiefest of issues being that there will forever be a delta between what you compile with and what your IDE things you're doing.

Type Providers have not needed mono to compile for quite a long time. There's no reason to require .NET Framework of any flavor unless you specifically require an API that...

So I'm not inherently opposed to this, but I will note that the F# style guide currently states that these aren't okay, but rather the allman-style is: https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/formatting#formatting-record-declarations From a...

Yeah, you can't reference a global tool like a normal nuget package: So you'd need to release some kind of core library for folks to use if they want to...