lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [lucenenet] NightOwl888 commented on issue #286: Build warning since v4.8.0-beta00008
Date Mon, 18 May 2020 08:56:32 GMT

NightOwl888 commented on issue #286:
URL: https://github.com/apache/lucenenet/issues/286#issuecomment-630043779


   We were able to remove a bit of runtime Reflection code by making the functionality into
a [Roslyn Analyzer Code Fix](https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/tutorials/how-to-write-csharp-analyzer-code-fix).
   
   A [single assembly](https://github.com/apache/lucenenet/tree/master/src/dotnet/Lucene.Net.CodeAnalysis)
was used for both the C# and VB analyzers, therefore that assembly has dependencies on both
   
   - [Microsoft.CodeAnalysis.CSharp.Workspaces](https://www.nuget.org/packages/Microsoft.CodeAnalysis.CSharp.Workspaces)
   - [Microsoft.CodeAnalysis.VisualBasic.Workspaces](https://www.nuget.org/packages/Microsoft.CodeAnalysis.VisualBasic.Workspaces)
   
   This appears to be the problem, but what isn't clear is why it is a problem as it is supposed
to be possible to put multiple language support into the same analyzer.
   
   A clue can be found in [the documentation](https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/october/code-analysis-build-and-deploy-libraries-with-integrated-roslyn-code-analysis-to-nuget#building-a-nuget-package-that-includes-apis-and-analyzers)
in that it is not clear on what to do in the case where you are supporting 2 languages only
without having a language-agnostic library (as in our case).
   
   > analyzers folder: This folder contains analyzer .dll files organized into particular
subfolders. **Agnostic analyzer libraries (that is, targeting all languages) reside in a subfolder
called dotnet. Analyzers targeting C# reside in a subfolder called dotnet\cs, whereas analyzers
targeting Visual Basic reside in a folder called dotnet\vb.** It’s worth mentioning that
dotnet represents the NuGet profile for .NET Core, and supports projects types such as Universal
Windows apps and ASP.NET 5 projects.
   
   Since the answer was **not** to put the same compiled DLL into both the `dotnet\cs` and
`dotnet\vb` folders, the only options that seem to remain are:
   
   1. Put the assembly into the `dotnet` folder
   2. Add conditional compilation and/or multiple projects to the assembly so only one language
is supported per assembly (with only the `PackageReference` dependencies that apply to that
language)
   
   So, this is a bug. 
   
   If someone were to be so kind as to solve this puzzle for us and submit a PR we would appreciate
it. Note that the deployment code that packs the analyzer into the Lucene.Net NuGet package
is located [here](https://github.com/apache/lucenenet/blob/00680bad64adf0842cebe9aa5d9855544b7512b0/src/Lucene.Net/Lucene.Net.csproj#L37-L46).


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



Mime
View raw message