Support netstandard

[mrgleba]

Right now only net461 is targetted.
It would be nice to have a netstandard[something] build.

[daz10000]

Let me know if I can help with this in any way (testing / fixing). We are using FsLexYacc.Runtime in a netcore application and it runs ok with 461 but lots of warning messages and it would be great to have a clean netstandard api. This is one of the last dependencies we have for net461 right now.

[Robar666]

Any updates?

[jackfoxy]

@daz10000 have you gotten lexyacc to work with dotnet SDK projects?

[mrgleba]

It works with net core SDK.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <NoWarn>NU1701</NoWarn>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="AlgTypes.fs" />
    <FsYacc Include="AlgParser.fsp">
      <OtherFlags>--internal --module Internal.Parser</OtherFlags>
    </FsYacc>
    <Compile Include="AlgParser.fs" />
    <FsLex Include="AlgLexer.fsl" >
      <OtherFlags>--unicode</OtherFlags>
    </FsLex>
    <Compile Include="AlgLexer.fs" />
    <Compile Include="Alg.fs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="FsLexYacc" Version="7.0.6" />
  </ItemGroup>
</Project>

Adding

<NoWarn>NU1701</NoWarn>

disables the warning and everything compiles cleanly.

[jackfoxy]

Thanks, @mrgleba
It seems for me the missing piece was my reliance on Paket and a different style reference to the FsLexxYacc runtime.

Prior to dotnet SDK this worked for me:

    <Reference Include="FsLexYacc.Runtime">
      <HintPath>..\..\packages\FsLexYacc.Runtime\lib\portable-net45+netcore45+wpa81+wp8+MonoAndroid10+MonoTouch10\FsLexYacc.Runtime.dll</HintPath>
    </Reference>

Changing it to <PackageReference Include="FsLexYacc" Version="7.0.6" /> fixed it.

[daz10000]

It does work, it just spews warnings, but with the NOWARN tip above - thanks! my activation energy for fixing this just went down a lot. It does mean your whole project has warnings off though so a clean dotnet core version would be preferable.

[jackfoxy]

No, my old style reference totally did not work for me. The dotnet build just errored on the Parser fs and fsi and lexer fs missing. Using PackageReference I still had to use the NOWARN tip.

[jackfoxy]

What exactly needs to be fixed?
Other than perhaps updating the documentation?

[dsyme]

I think minimally FsLexYacc.Runtime needs to be a multi-targeting project generating net45 and netstandard2.0

Separately the tools could be made dotnet global commands I suppose

[jackfoxy]

apparently I had no problem using the current runtime in a netcoreapp2.1 app

[manofstick]

As per @jackfoxy's comment, the reason that <Reference> (as opposed to <PackageReference>) fails is, I believe, due to an ordering issue within msbuild.

When using <Reference>, if you run msbuild /verbosity:diagnostic you can see that the setting of the property ${CompileDependsOn) is in a different order in a .net standard project vs .net framework (for some reason). The CallFsLex;CallFsYacc; that is set in FsLexYacc.targets is splatted over in the case of .net standard. When the <PackageReference> is used, the ordering is handled properly.

(Personally we would prefer to use <Reference> for more control so I'm hoping this gets fixed at some stage? I'm know very little about msbuild, so I don't know if this is a problem with the package or with msbuild...)

[kkm000]

@manofstick, just FYI, http://msbuildlog.com/ is an amazing tool to diagnose problems like this.

Just wondering, you mention you prefer "classic" <Reference> over the "SDK-style" <PackageReference>. Why is that? In our workflow, where projects can be pulled as submodules into solutions at different directory depths, <PackageReference> was a godsend. Plus no longer a need to much with the tool path manually. But I am really wondering what do people out there perceive see as a flip side.

[manofstick]

@kkm000

Maybe a bit archaic, but we just have a network share with all our third party references on it, grown over about 2 decades.

With old style references this works well.

Suggestions?

[kkm000]

@manofstick, I am not sure I understand the context. <Reference>s added by the "classic" NuGet VS plug-in once upon package install are opposed here to <PackageReference> dependencies resolved by "SDK-style" NuGet build task and its MSBuld plumbing on build; the latter supersedes packages.conf. Other assembly references should still work. And there was no NuGet 20 years ago, so I am assuming your big common share is not related to NuGet directly. So I am shooting in the dark, in a sense. I may be misunderstanding the problem.

New style NuGet scripts are sloppy at times, I wish they could be better, and its build tasks are quite opaque and rigid. With the SDK projects there are also inner/outer builds, when the outer build phase essentially invokes the same project once per target framework. This also often requires subtle handling when dealing with codegen tools like fslex/fsyacc, which you might want to invoke only once per overall build, not once per target framework.

What if you hook up using BeforeTargets instead of augmenting the CompileDependsOn variable? These are added into the build graph by MSBuild itself internally, so they wont be affected by any scripting. The tricky point is to hook up to correct targets, to run codegen not too early, not too late, skip running it at project load time in VS (I think the current FsLexYacc package does run tools at load time in SDK-style projects), an so on. The binlog viewer is your best tool here as well.

[NatElkins]

@kkm000 I think this can be closed.

[cartermp]

The runtime now targets .NET Standard 2.0.