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

Support netstandard #78

Closed
mrgleba opened this issue Aug 23, 2017 · 16 comments
Closed

Support netstandard #78

mrgleba opened this issue Aug 23, 2017 · 16 comments

Comments

@mrgleba
Copy link
Contributor

mrgleba commented Aug 23, 2017

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

@daz10000
Copy link

daz10000 commented Apr 3, 2018

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
Copy link

Any updates?

@jackfoxy
Copy link
Contributor

jackfoxy commented Jul 9, 2018

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

@mrgleba
Copy link
Contributor Author

mrgleba commented Jul 10, 2018

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
Copy link
Contributor

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
Copy link

daz10000 commented Jul 11, 2018

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
Copy link
Contributor

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
Copy link
Contributor

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

@dsyme
Copy link
Contributor

dsyme commented Jul 17, 2018

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
Copy link
Contributor

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

@manofstick
Copy link
Member

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
Copy link
Member

kkm000 commented Sep 13, 2018

@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
Copy link
Member

@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
Copy link
Member

kkm000 commented Sep 19, 2018

@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
Copy link

@kkm000 I think this can be closed.

@cartermp
Copy link
Contributor

cartermp commented Apr 9, 2020

The runtime now targets .NET Standard 2.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

9 participants