Failure to build dll when adding a dll with nuget in the Library outtype in .netcore3.1 - asp.net-core

I have a plugin application(.net web site link). In the solution, there is a console application and projects of more than one library type. The selected plugins are being loaded and the application starts a listening.
The problem is; If I add nugetten dll to a library type project, the compiled version of these dlls should be created when there is build in the folder I specified.
.csproj;
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<OutputType>Library</OutputType>
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
<AssemblyInfoFilePath>Properties\AssemblyInfo.cs</AssemblyInfoFilePath>
<UpdateAssemblyVersion>True</UpdateAssemblyVersion>
<UpdateAssemblyFileVersion>True</UpdateAssemblyFileVersion>
<UpdateAssemblyInfoVersion>True</UpdateAssemblyInfoVersion>
<AssemblyVersionSettings>None.None.Increment.DateStamp</AssemblyVersionSettings>
<AssemblyFileVersionSettings>None.None.Increment.DateStamp</AssemblyFileVersionSettings>
<AssemblyInfoVersionSettings>None.None.Increment.DateStamp</AssemblyInfoVersionSettings>
<PrimaryVersionType>AssemblyVersionAttribute</PrimaryVersionType>
<AssemblyVersion>2.0.0.0</AssemblyVersion>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<OutputPath>..\Nemesis.Agent\bin\Debug\Plugins\PrinterPlugin\</OutputPath>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="itext7" Version="7.1.13" />
<PackageReference Include="PdfiumViewer.Core" Version="1.0.4" />
<PackageReference Include="PuppeteerSharp" Version="2.0.4" />
</ItemGroup>
<ItemGroup>
...
</ItemGroup>
</Project>
packages;
folder
I used this code In PrintPdfDocument;
var pdfDocument = PdfiumViewer.PdfDocument.Load(new MemoryStream(bytes));
error during runtime;
I could not find the source of the error.I've tried other namespaces. The problem is solved if I manually move the compiled dll to the relevant folder. .net framework wasn't having this problem.

I overcame this problem by adding the following code to csproj.
<CopyLocalLockFileAssemblies>True<CopyLocalLockFileAssemblies>

Related

Error using C++/CLI dll in Azure function (zip deployed)

So I have:
a c++/cli wrapper withini a clr c++ dll
a c# net6 azure function which is referencing the c++/cli project
The issue:
It works perfectly when I'm testing it in local (with visual studio)
When it's published (zip) on Azure I can call functions that don't use the c++/cli dll,
but when I'm calling (via Test/Run button) a function that use my c++/cli lib
I have this error code 500 Internal Server Error and this error message:
Could not load file or assembly 'C:\home\site\wwwroot\bin\MyCliDll.dll'. Format of the executable (.exe) or library (.dll) is invalid.
I have try a lot of different publishing configuration but non of them worked.
at this point I don't have any idea of what to change i order to make it works, is it a compatibility problem between my c++ and Azure ?
In case, here both of my setup:
<!--Publishing Setup-->
<Project>
<PropertyGroup>
<UserName>XXXXX</UserName>
<WebPublishMethod>ZipDeploy</WebPublishMethod>
<PublishProvider>AzureWebSite</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>x64</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish>XXXXXX</SiteUrlToLaunchAfterPublish>
<LaunchSiteAfterPublish>false</LaunchSiteAfterPublish>
<ResourceId>XXXXXXXX</ResourceId>
<_SavePWD>true</_SavePWD>
<PublishUrl>XXXXXXXX</PublishUrl>
<TargetFramework>net6.0</TargetFramework>
<SelfContained>false</SelfContained>
<SkipExtraFilesOnServer>true</SkipExtraFilesOnServer>
</PropertyGroup>
</Project>
<!--csproj-->
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<OutputType>Library</OutputType>
<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Azure.Storage.Blobs" Version="12.11.0" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\MyCliDllProject\build\MyCliDll.vcxproj" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
Ok I feel a bit dumb I just needed to go to the portal Azure in Configuration->General Settings->Platform and set it to 64 bit...

How can I include different packages in different Configuration/Platform combinations?

I have a library that is designed to work with Sap Business One's SDK. The SDK for V10 is different to the one for V9.3, I also have x86/x64 and SQL/HANA builds, this gives me 8 permutations and therefore 8 packages.
The projects that consume these packages will also have 8 builds. I would like to set up the project file and targets so that a specific package is selected for a specific Configuration & Platform. I am trying to work this out, but it makes absolutely no sense.
Currently I have the following in my project file:
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x64' ">
<PackageReference Include="OchALCommon.v93SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93SQL|x86' ">
<PackageReference Include="OchALCommon.v93SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x64' ">
<PackageReference Include="OchALCommon.v93HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v93HANA|x86' ">
<PackageReference Include="OchALCommon.v93HANAx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x64' ">
<PackageReference Include="OchALCommon.v10SQLx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10SQL|x86' ">
<PackageReference Include="OchALCommon.v10SQLx86" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x64' ">
<PackageReference Include="OchALCommon.v10HANAx64" Version="1.0.*" />
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)|$(Platform)' == 'B1v10HANA|x86' ">
<PackageReference Include="OchALCommon.v10HANAx86" Version="1.0.*" />
</ItemGroup>
Visual studio indicates all 8 packages and a build process the dependencies of each one - this seems wrong. I also tried this code within a "Directory.Build.targets" file, which initially seemed to work, but then Visual Studio stopped reponding to changes in the targets file (even after a reboot).
We have always used this kind of referencing in the past with Assembly references,and it seems to work, I have no idea how to make PackageReference function. Does anybody know how best to package this library in my scenario?
In an ideal world, I'd want to somehow store my 64 bit and 32 bit build plus some appropriate targets in a single nuget package so that the consuming project gets the right bitness and the right sub project references. Currently I can't work out how to do this, nor get any other workable scenario going.
Again, does anybody know how to do anything like this?
Thanks.
Thus far I have been able to solve the issue by using separate files (.targets) for each ProjectReference, and then ensuring that only those files containing the reference information are included in the project by referencing specific .targets files.
I have then put .targets files into an umbrella nupkg to select which of the actual payloads I want to use. The entire arrangement looks as follows:
I published 8 payload files as follows:
MyLibrary.v93HANAx64
MyLibrary.v93HANAx86
MyLibrary.v93SQLx64
MyLibrary.v93SQLx86
MyLibrary.v10HANAx64
MyLibrary.v10HANAx86
MyLibrary.v10SQLx64
MyLibrary.v10SQLx86
Each payload file simply contains a standard lib/net40 folder with libraries as specified in the https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package page.
My consuming project has 4 Configurations:
B1v93HANA
B1v93SQL
B1v10HANA
B1v10SQL
I then have an umbrella project "MyLibrary.Targets" containing content as follows:
##build/net40/MyLibrary.Targets.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<Import Project="MyLibrary/$(Configuration).targets" />
</Project>
##build/net40/MyLibrary/B1v10HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v10SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v10SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93HANA.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93HANA$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
##build/net40/MyLibrary/B1v93SQL.targets
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<ItemGroup>
<PackageReference Include="MyLibrary.v93SQL$(Platform)" Version="1.0.*" />
</ItemGroup>
</Project>
I also have targets files in this folder, "Debug.targets" and "Release.targets" which use my preferred default library in those cases.
.nupec files for all of the packages are pretty standard as per the above linked Microsoft guide. A default nuspec file can be created with the 'nuget spec' command and can then be edited.
My functional package nuspec files have content in 'package/metadata/dependencies' which identify required packages:
<dependencies>
<group targetFramework=".NETFramework4.0">
<dependency id="CryptLib" version="*" />
<dependency id="SAPBusinessOneSDK.HANA" version="10.0.*" />
</group>
</dependencies>
My Selector package "MyLibrary.targets" does not have dependencies, but does have a files section 'package/files':
<files>
<file src="readme.txt" target="" />
<file src="build\**" target="build" />
</files>
Hopefully this saves somebody some time.

How to stop the localized Microsoft.CodeAnalysis.*.resources.dll files from getting published by ASP.NET Core?

When I publish an ASP.NET Core 3.0 project, I get a few localized folders where the 4 assemblies shown are in each of these folders. I am not sure why these folders and files get included. None of my packages reference a CodeAnalysis package.
I added <PreserveCompilationContext>false</PreserveCompilationContext> in the csproj file but it didn't help. Is there a way to exclude them?
Add this:
<SatelliteResourceLanguages>en</SatelliteResourceLanguages>
to the .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<SatelliteResourceLanguages>en</SatelliteResourceLanguages>
</PropertyGroup>
As suggested, you can use none to exclude all of them:
<SatelliteResourceLanguages>none</SatelliteResourceLanguages>
and taking consideration languages do you want like english and spanish:
<SatelliteResourceLanguages>en;es</SatelliteResourceLanguages>
Works with VS2019 and other versions
UPDATE 2021/2022:
Still working with Visual Studio 2022 and .NET 6
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<SatelliteResourceLanguages>en</SatelliteResourceLanguages>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
You get a lot of language folders containing CodeAnalysis.dll files in your published output if you have a project reference to Microsoft.VisualStudio.Web.CodeGeneration.Design, which is needed for scaffolding controllers. If that is true for your project, change the package reference in your .csproj file to include ExcludeAssets="all"
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.0.0" ExcludeAssets="All" />
For example, old *.csproj file
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UserSecretsId>aspnet-foo-4E53EF45-B3BE-4943-81BE-2449DC5AA2BC</UserSecretsId>
<BlazorLinkOnBuild>false</BlazorLinkOnBuild>
</PropertyGroup>
<ItemGroup>
<!-- ... -->
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design"
Version="3.0.0" />
</ItemGroup>
<ItemGroup>
<!-- ... -->
</ItemGroup>
</Project>
New file *.csproj should be
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.0</TargetFramework>
<UserSecretsId>aspnet-foo-4E53EF45-B3BE-4943-81BE-2449DC5AA2BC</UserSecretsId>
<BlazorLinkOnBuild>false</BlazorLinkOnBuild>
</PropertyGroup>
<ItemGroup>
<!-- ... -->
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design"
Version="3.0.0"
ExcludeAssets="All" />
</ItemGroup>
<ItemGroup>
<!-- ... -->
</ItemGroup>
</Project>
In my case, the source of these localized folders was from the package Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation. It has a dependency on Microsoft.CodeAnalysis.Razor. You can read more about the purpose of the package here: https://learn.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-3.1
You cannot just exclude an asset when trying to take advantage of the package. My work-around was to conditionally include the package reference whenever the project is in debug mode.
<ItemGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="3.1.1" />
</ItemGroup>
I then used an #if pre-processor directive to conditionally run the code that enables razor runtime compilation.
#if DEBUG
services.AddRazorPages().AddRazorRuntimeCompilation();
#else
services.AddRazorPages();
#endif
Please note: You may need to delete your bin folder to see the folders removed after a build. Also, make sure you are building under the correct solution configuration.
I was able to find a Github issue describing this exact scenario, but unfortunately it was never resolved. https://github.com/dotnet/extensions/issues/2247

Keep documentation xml file while running publish with -c Release

I'm trying to build a project that includes swashbuckle and for troubleshooting I want to include swagger into a release build.
I've narrowed it down to this now:
When I run
dotnet publish -o ./out
the xml file ProjectName.xml is generated in the out folder and when I run
dotnet publish -o ./out -c Release
the xml file is not generated.
The csproj file looks like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<OutputType>Exe</OutputType>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<OutputPath>bin\Debug\</OutputPath>
<DocumentationFile>obj\Debug\ProjectName.xml</DocumentationFile>
</PropertyGroup>
<ItemGroup>
<Folder Include="somefolder\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.4" />
...
<PackageReference Include="Swashbuckle.AspNetCore" Version="3.0.0" />
...
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.1.3" />
<PackageReference Include="Swashbuckle.AspNetCore.Annotations" Version="3.0.0" />
</ItemGroup>
</Project>
and I'm pretty certain I can narrow it down even a bit further given time but I'm fairly new with dotnet and I also guess someone sees the problem already.
I'm looking for either a way to get this working or an explanation for why this is too wrong to be doable.
PS: Running on linux so no Visual Studio. Otherwise this could have been a possible solution for what I know: Swashbuckle + XmlComments work locally, but fail swagger generation on server
Add this to your csproj file instead of setting OutputPath or DocumentationFile:
<PropertyGroup>
<GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>
Add in your .csproj :
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<OutputPath>bin\Release\</OutputPath>
<DocumentationFile>obj\Release\ProjectName.xml</DocumentationFile>
</PropertyGroup>
Or remove the condition :
<PropertyGroup>
<OutputPath>bin\$(Configuration)\</OutputPath>
<DocumentationFile>obj\$(Configuration)\ProjectName.xml</DocumentationFile>
</PropertyGroup>

Using FsLex/Yacc in Vs2013

I'm trying to resurrect an old f# parser project I had working in vs 2008 to work with vs 2013. It uses FsLexYacc.
I got it building ok by using a prebuild step as thus:
fslex --unicode "$(ProjectDir)XpathLexer.fsl"
fsyacc --module XpathParser "$(ProjectDir)XpathParser.fsy"
But this is less than ideal, as it always executes whether or not the inputs have changed.
I then tried just using the old MsBuild actions:
<FsYacc Include="XpathParser.fsy">
<FsLex Include="XpathLexer.fsl">
but these appeared to be completely ignored during the build process. Is that right? Have these build tasks been removed somehow?
I then found some stuff documented under vs C++ that I thought might work:
<CustomBuild Include="XpathParser.fsy">
<Message>Calling FsYacc</Message>
<Command>fsyacc --module XpathParser "$(ProjectDir)XpathParser.fsy"</Command>
<Outputs>$(ProjectDir)XpathParser.fs</Outputs>
</CustomBuild>
and
<PropertyGroup>
<CustomBuildBeforeTargets>CoreCompile</CustomBuildBeforeTargets>
</PropertyGroup>
(I inspected the Microsoft.Fsharp.Targets file to come up with the "CoreCompile" target.)
Alas, still no cigar.
Is anyone able to shine a light on whether it is indeed possible to properly integrate fslex/yacc into a vs 2013 solution, and if so, how?
I don't think the those tools are included by default with the F# compiler that is installed with Visual Studio and so the tasks don't exist. I did the following with a Visual Studio 2012 project, but I expect it would be similar in VS 2013. Here were the steps I had to follow:
Install FSharp.Powerpack from nuget. This has the fslex and fsyacc tools as well as build tasks and targets.
Unload the project and edit the .fsproj file.
Add an import statement for the FSharp.Powerpack.target file. This will add the CallFsLex and CallFsYacc build targets. I added this after the import for Microsoft.FSharp.targets:
<Import Project="$(ProjectDir)\..\packages\FSPowerPack.Community.3.0.0.0\Tools\FSharp.PowerPack.targets" />
Add these three properties to main PropertyGroup at the top of the file:
<FsYaccToolPath>..\packages\FSPowerPack.Community.3.0.0.0\Tools</FsYaccToolPath>
<FsLexToolPath>..\packages\FSPowerPack.Community.3.0.0.0\Tools</FsLexToolPath>
<FsLexUnicode>true</FsLexUnicode> This tells the build tasks where to find the necessary tools and sets the unicode option for fslex.
To use the targets we've imported, you need to define the FsLex and FsYacc item groups with the input files to use. You also need to add Compile items for the output .fs files. You end up with something like this in an ItemGroup section:
<Compile Include="Sql.fs" />
<FsYacc Include="SqlParser.fsp">
<Module>SqlParser</Module>
</FsYacc>
<Compile Include="SqlParser.fsi" />
<Compile Include="SqlParser.fs" />
<FsLex Include="SqlLexer.fsl" />
<Compile Include="SqlLexer.fs" />
You might be able to use the FsLex and FsYacc build tasks directly by referencing the FSharp.Powerpack.Build.Tasks.dll, but for me this was easier to get going.
This is what works for me (Windows 7 x64, Visual Studio 2013 Ultimate RTM):
Get and install "PowerPack for FSharp 3.0 + .NET 4.x + VS2012" from CodePlex (https://fsharppowerpack.codeplex.com/downloads/get/625449)
Create the following Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AssemblyFolders\FSharp.PowerPack-1.9.9.9 (for x64 versions of Windows, omit the Wow6432Node for 32bit versions) and set its (Default) value to the installation directory of the F# PowerPack (e.g. "C:\Program Files (x86)\FSharpPowerPack-4.0.0.0\bin"). [This is related to a long standing/regression bug in src/FSharp.PowerPack/CompilerLocationUtils.fs which basically breaks tool discovery.]
Import the PowerPack targets (AFTER importing the F# targets) in your *.fsproj file: <Import Project="$(MSBuildExtensionsPath32)\FSharp\1.0\FSharp.PowerPack.targets" />
Update your ItemGroup node to something like this (use FsYacc accordingly):
<ItemGroup>
<None Include="App.config" />
<FsLex Include="Lexer.fsl" />
<Compile Include="Lexer.fs">
<Visible>False</Visible>
</Compile>
<Compile Include="Program.fs" />
</ItemGroup>
Include a reference to FSharp.PowerPack.dll and build.
You should end up with a *.fsproj file similar to this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>8c565f99-d6bc-43a9-ace9-eadfe429c0f7</ProjectGuid>
<OutputType>Exe</OutputType>
<RootNamespace>FsYaccTest</RootNamespace>
<AssemblyName>FsYaccTest</AssemblyName>
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<TargetFSharpCoreVersion>4.3.1.0</TargetFSharpCoreVersion>
<Name>FsYaccTest</Name>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<!-- Snip -->
</PropertyGroup>
<ItemGroup>
<Reference Include="FSharp.PowerPack">
<HintPath>C:\Program Files (x86)\FSharpPowerPack-4.0.0.0\bin\FSharp.PowerPack.dll</HintPath>
</Reference>
<Reference Include="mscorlib" />
<Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
</Reference>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Numerics" />
</ItemGroup>
<PropertyGroup>
<MinimumVisualStudioVersion Condition="'$(MinimumVisualStudioVersion)' == ''">11</MinimumVisualStudioVersion>
</PropertyGroup>
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets')">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" />
<Import Project="$(MSBuildExtensionsPath32)\FSharp\1.0\FSharp.PowerPack.targets" />
<PropertyGroup>
<FsLexUnicode>true</FsLexUnicode>
</PropertyGroup>
<ItemGroup>
<None Include="App.config" />
<FsLex Include="Lexer.fsl" />
<Compile Include="Lexer.fs">
<Visible>False</Visible>
</Compile>
<Compile Include="Program.fs" />
</ItemGroup>
</Project>
Note: You can probably omit creating the Registry key if you provide a proper FsYaccToolPath as described in mike z's answer.
This looks like it works - at least, in my experience, if you use the separate FsLexYacc nuget package as detailed here, and then put the following in your fsproj file (extracted from the github example):
Next to all the other imports:
<Import Project="..\packages\FsLexYacc.6.0.4\bin\FsLexYacc.targets" />
etc, etc
and then for the source files:
<FsYacc Include="Parser.fsp">
<OtherFlags>--module SqlParser</OtherFlags>
</FsYacc>
<FsLex Include="Lexer.fsl">
<OtherFlags>--unicode</OtherFlags>
</FsLex>
No need to do anything apart from edit the fsproj file, and install the nuget packages.