Comments (9)
Actually it's only a warning - I had TreatWarningsAsErrors
enabled.
from lucenenet.
Getting the same warning when building. Is another package required?
from lucenenet.
We were able to remove a bit of runtime Reflection code by making the functionality into a Roslyn Analyzer Code Fix.
A single assembly was used for both the C# and VB analyzers, therefore that assembly has dependencies on both
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 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:
- Put the assembly into the
dotnet
folder - 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.
from lucenenet.
I was able to work around this by excluding the analyzers from Lucene.Net
:
<PackageReference Include="Lucene.Net" Version="4.8.0-beta00008" NoWarn="NU5104;AD0001">
<ExcludeAssets>analyzers</ExcludeAssets>
</PackageReference>
You'll need to make sure that you kill any existing background compiler processes though after making that change otherwise the analyzer will remain loaded.
from lucenenet.
I started looking into this and couldn't reproduce it. Then I realized I was using 4.8.0-beta00009 instead of 4.8.0-beta00008 and sure enough, 4.8.0-beta00008 is presenting the problem. Since we didn't change anything regarding the analyzers between those 2 versions, I am at a loss to explain why the problem existed in the first place or why it suddenly disappeared.
Doing a fresh build from source also doesn't present the problem.
I am closing this issue for now, but feel free to reopen it if you see this problem appear in a future release.
from lucenenet.
For info this issue resurfaced on 4.8.0-beta00010
for me.
Downgraded to 4.8.0-beta00009
worked fine, downgraded to 4.8.0-beta00008
same error.
Resolved by upgrading the dotnet core sdk (I was one dot release behind)
MacOS
from lucenenet.
Strange. My guess is a bug in certain SDKs. I confirmed that 4.8.0-beta00010
and 4.8.0-beta00011
didn't present the problem before starting the release vote.
Just out of curiosity, does upgrading the SDK "fix" 4.8.0-beta00008
? I am seeing the problem in that version, but not in any of the others. I am using SDK version 3.1.301
to build locally and on the CI environment. I also checked both .NET Framework 4.7.2 and .NET Core 3.1 and the behavior seemed consistent on both targets.
from lucenenet.
Our CI built 4.8.0-beta00011
fine as well.
Think I figured it out.
NuGet version weirdness / background dotnet / OmniSharp processes keeping the wrong dll version in memory (what @iwillspeak refers to essentially, about the analyzer staying loaded in memory)
With SDK 3.1.302
Went to build 4.8.0-beta00011
and it failed.
Dropping back to every other version, since 4.8.0-beta00008
and it succeeded
Dropped back to 3.1.106
and everything started failing except 4.8.0-beta00010
Cleared out the NuGet
cache of all my Lucene.Net
packages and went back to SDK 3.1.302
and 4.8.0-beta00011
and it builds ok.
Drop back to version 4.8.0-beta00010
and it builds.
Then build 4.8.0-beta00011
and it fails.
Delete the 4.8.0-beta00010
from the NuGet cache and version 4.8.0-beta00011
builds fine.
Do the above process again with a killall dotnet
between version upgrades and it built the new version fine.
from lucenenet.
I'm getting the warning on 4.8.0-beta00010
with SDK v3.1.302
. Cleared the NuGet cache, restarted (Windows Server). There are no other versions restored and visible in the NuGet cache so indeed this is the only version being used.
from lucenenet.
Related Issues (20)
- for some reasons lucene create duplicate data while searching HOT 2
- Random property used by the tests needs to return new instance of "Randomness generator" per thread
- Task: Investigate failing QueryParser Flexible tests (TestNumericQueryParser.cs)
- It seems that escaped query characters are not treated as escaped when calling queryParser.Parse()
- Add .NET Core support for Lucene.Net.Analysis.OpenNLP HOT 2
- Add NuGet Caching to Azure Pipelines Build
- Add NuGet Caching to GitHub Actions
- Question: How can I add a filter for Flag enums correctly in a search query HOT 2
- EdgeNGramFilter: .NET seems to be missing PreserveOriginal HOT 1
- Lucene.NET Does Not find the word "on"? HOT 3
- I have an issue in the x86 version of application HOT 1
- Semantic Search support HOT 2
- Wildcards does not work with query string containing Hyphen HOT 1
- Prism is now commercial software HOT 9
- ci: Ensure SonarCloud is not triggered on website or documentation updates HOT 3
- If there is not enough funds, should lucenenet consider: opening up to receive funding from the community or industry ? HOT 2
- ci: Upgrade SonarCloud to Java 17
- Support for Ordering of Indexing with SeqNo HOT 4
- Random Query Parser Error HOT 1
- The type initializer for "Lucene.Net.Diagnostics.Debugging" threw an exception HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lucenenet.