-
Notifications
You must be signed in to change notification settings - Fork 38
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
Any plans for .net core compatible nuget package? #99
Comments
I wanted to add a comment on to this - I was just looking at compiling stuff today with it (and vs2017). It looks like the CodeDOM stuff it relies on isn't easily available in .net core - is this true and would it mean a port to Roslyn or is the use only for their types? |
I get the following error when trying to build using "dotnet build" C:\Users\appveyor.nuget\packages\pegasus\4.0.0\build\Pegasus.targets(36,5): error MSB4062: The "CompilePegGrammar" task could not be loaded from the assembly C:\Users\appveyor.nuget\packages\pegasus\4.0.0\build\Pegasus.exe. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\projects\foundatio-parsers\src\Foundatio.Parsers.LuceneQueries\Foundatio.Parsers.LuceneQueries.csproj] |
I've started to look into this. I'd like to provide .NET 2.0, .NET 3.5, and .NET Core 2.0 compatible versions of the Pegasus.Common package, as well as making the generated code compile and run on all of these platforms as well. There will be performance trade-offs, so it would be nice if the compiler knew which version of the framework it is targeting in order to use optimal string overloads. |
OK, this is done for the Pegasus.Common library at least. The latest pre-release packages support .NET 3.5, .NET 4.0, .NET 4.5, .NET Standard 1.0, and .NET Standard 2.0 More frameworks can be added pretty painlessly by updating Pegasus.Common.csproj:
I still need to test whether or not this works at build time in a .NET Core application. |
Hi @otac0n , I've tried and failed with Pegasus 4.1.0-alpha0026:
It works with |
In addition to previous, Pegasus.Common.dll is not copied over to the bin folder by msbuild. After copying it manually, the program runs, otherwise it complains of Pegasus.Common assembly missing. This must be some glitch in the nuget package so it might be relevant to dotnet core once the build task issue is fixed. Thanks. |
I'm still working on this. I've updated my other projects that Pegasus depends on so that it can build using .NET Core. Not a strict prerequisite, but these projects allow me to work out the kinks around code generation in the new project system. Anyways, depending on when I can get the time, I'd like to get this finished in the next month or so. |
This should be supported now in the latest prerelease packages.
@jocutajar Would you mind trying it out to see if it works for you? |
@otac0n, magic indeed. I confirm that I can build and run a peg parser with 4.1.0-alpha0031 on dotnet core. Thanks a bunch! |
On VS 2017 Pro (15.8.1), Pegasus 4.1.0-alpha0031:
<Target Name="Grammar" BeforeTargets="Build" >
<CompilePegGrammar InputFiles="QueryParser.peg" OutputFiles="QueryParser.g.cs"></CompilePegGrammar>
</Target> This caused the error:
Changing the
|
Hi @StephenCleary , |
When I change the attribute to |
@StephenCleary I made some changes to the .targets file that I think will allow everything to work on all versions of .NET including .NET standard. This is available on versions >= 4.1.0-alpha0151 If you want to, you can now control the output path of the generated code using the |
I have built an example of using Pegasus on .NET Core at https://github.com/Konard/PegasusExample (the 4.1.0-alpha0152 version of NuGet package is used) |
@StephenCleary I have fixed your So insted of: <Target Name="Grammar" BeforeTargets="Build" >
<CompilePegGrammar InputFiles="QueryParser.peg" OutputFiles="QueryParser.g.cs"></CompilePegGrammar>
</Target> You can try this out: <Target Name="CompilePegGrammar" BeforeTargets="BeforeBuild" >
<CompilePegGrammar InputFiles="./QueryParser.peg" OutputFiles="./QueryParser.g.cs" ></CompilePegGrammar>
<ItemGroup>
<Compile Remove="QueryParser.g.cs" />
<Compile Include="QueryParser.g.cs" />
</ItemGroup>
</Target> This makes it do everything at once so Btw, if I'm not using
This example leads to an error: <Target Name="CompilePegGrammar" BeforeTargets="BeforeBuild" >
<CompilePegGrammar InputFiles="Test.peg" OutputFiles="Test.peg.g.cs" ></CompilePegGrammar>
<ItemGroup>
<Compile Remove="Test.peg.g.cs" />
<Compile Include="Test.peg.g.cs" />
</ItemGroup>
</Target> |
Can you try:
|
When I try using it that way on my project (https://github.com/FoundatioFx/Foundatio.Parsers) getting all kinds of errors:
|
So the #line pragmas in the generated file are just |
@otac0n |
@konrad are you targeting netstandard2.0? |
@ejsmith I cloned your repo and believe I fixed the issue in adf91d7 (4.1.0-alpha0154). I think it also fixes #106, so it's really appreciated that you shared your issue. It's strongly recommended that you don't check in the generated parser classes now, since I've been forced to include the full path to the C# file in the I'm considering including the option to output relative paths instead of full paths, but I'm not sure how well Visual Studio will behave in that case. |
I’ll give this a try in a few hours. |
I tried the latest and it didn't work for me. Although I don't see full paths in the #line pragmas. |
Hmm... I just committed that code and the build passed. So I'm not sure what is going on. I'm on Windows in the |
Well, it worked on OSX as well. I shut my vscode instance down, did a git clean, and did a rebuild from the command line and it worked on Windows too. Weird. But it works! |
Thanks for your help @otac0n. Any idea when 4.1 will be released? |
@ejsmith 4.1 version of the package was published two days ago. |
Thank you! |
Is porting this project to .net core in the cards?
The text was updated successfully, but these errors were encountered: