Type aliases throwing errors with Microsoft.NET.Sdk.Functions

[Szer]

Same with all aliased types like string -> System.String, double -> System.Double etc

repro:

create fsproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="*" />
  </ItemGroup>

  <ItemGroup>
    <Compile Include="main.fs" />
  </ItemGroup>

</Project>

create main.fs:

module Lib

open System.Net

ServicePointManager.DefaultConnectionLimit <- 20

This one compiles and build OK, but F#LS throwing compile errors

[Neftedollar]

As I know @Szer made some research and the problem is in the project cracking part.

[Szer]

@georgewfraser the problem is in cracking part indeed. After buildalyzer gets direct references and target (e.g. netstandard2.0) it builds up direct dependencies list. (netstandard target brings ~100 direct dependencies) And than we merge it with nuget.props where some package references might be dependen on the same netstandard libs with different version.

That way some dependencies will be duplicated (for example System.Collections.Generic for netstandard1.3 and netstandard2.0), moreover mscorlib and FSharp.Core also will be duplicated which cause the issue we discussing (System.Int32 != int)

Some thoutghs on workaround: dotnet build /flp:v=diag;logfile=build.log generates valid reference list for FSC, because it has resolve library conflict step inside it. We could easily start dotnet build process outside, parse and grab all lines (from stdout, or from file) which starting with -r: and voila, we don't need buildalyzer anymore and we have 100% valid -r list

Or we could try to use Paket API, and programmatically build lock file with all needed references, which is "less hacky" way, but I'm not sure about it.

[georgewfraser]

Calling dotnet build is perfectly acceptable in principle. If someone could write a simple proof-of-concept script showing how to do this, that would help get this going.

[Szer]

@georgewfraser FYI Don Syme made project cracker for F# projects

https://github.com/fsprojects/FSharp.Compiler.PortaCode/blob/master/src/ProjectCracker.fs

[johngalambos]

@georgewfraser I'm thinking about taking a shot at implementing project cracking using https://github.com/enricosada/dotnet-proj-info (also used in Don Syme's project cracker @Szer mentioned). If you think that's a dead end, let me know!

[johngalambos]

Just to follow up on my last comment, it looks like the dotnet-proj-info approach was already attempted and abandoned as discussed here: https://github.com/fsprojects/fsharp-language-server/issues/2. For what it's worth I had a go at using Don Syme's project cracker and got most of the tests passing: https://github.com/johngalambos/fsharp-language-server/tree/dotnet-projinfo

I won't take it any further for now as I'm not familiar with the history and may be in over my head. It does seem hopeful in terms of resolving this issue and #49, but there are likely performance problems etc.

[georgewfraser]

Turns out it was just a straightforward bug in ProjectCracker.fs. @Szer your example is now in the test set.

[georgewfraser]

The build is currently breaking on #49 but it's not related to the most recent change.