ExhaustiveMatching
ExhaustiveMatching copied to clipboard
Dependency on the non-existent Microsoft.CodeAnalysis 3.3.0 package?
Whenever I install the ExhaustiveMatching NuGet package to a .NET Framework 4.7.2 project I get compiler/MSBuild warnings that Microsoft.CodeAnalysis
version 3.3.0 was not found - unfortunately that version doesn't exist on NuGet, it jumps from 3.3.0-beta3-final
to 3.3.1
( https://www.nuget.org/packages/microsoft.codeanalysis )
I can reproduce this consistently at my end.
I haven't been able to reproduce this yet. I first tried changing my examples project (which references ExhaustiveMatching.Analyzer v0.4.0) to multi-target different frameworks including 4.7.1 using netstandard2.0;netcoreapp2.0;netcoreapp3.0;netcoreapp3.1;net461;net472;net48
. That change is now on the master branch. Then I tried creating a .NET framework 4.7.2 class library project and referencing and using the ExhaustiveMatching.Analyzer v0.4.0. Then I tried the same from a .NET framework 4.7.2 console project.
You can try the new v0.5.0 version. I removed a package reference, but I doubt it will fix this.
I'd like to fix this. Please provide a sample project that reproduces the bug.
@WalkerCodeRanger I ran into this today as well. Let me take a stab at putting together a minimal repro now.
Hey @WalkerCodeRanger
Please see the attached repro. Simply install .NET Core SDK 2.2.105 and run dotnet build
inside the directory containing the solution to see the following output:
➜ ExhaustiveBugRepro dotnet build
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
Restoring packages for /Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/PortableLibrary.csproj...
Generating MSBuild file /Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/obj/PortableLibrary.csproj.nuget.g.props.
Generating MSBuild file /Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/obj/PortableLibrary.csproj.nuget.g.targets.
Restore completed in 136 ms for /Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/PortableLibrary.csproj.
CSC : warning CS8032: An instance of analyzer ExhaustiveMatching.Analyzer.ExhaustiveMatchAnalyzer cannot be created from /Users/anthonyiacono/.nuget/packages/exhaustivematching.analyzer/0.5.0/analyzers/netstandard2.0/cs/ExhaustiveMatching.Analyzer.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.. [/Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/PortableLibrary.csproj]
PortableLibrary -> /Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/bin/Debug/netstandard2.0/PortableLibrary.dll
Build succeeded.
CSC : warning CS8032: An instance of analyzer ExhaustiveMatching.Analyzer.ExhaustiveMatchAnalyzer cannot be created from /Users/anthonyiacono/.nuget/packages/exhaustivematching.analyzer/0.5.0/analyzers/netstandard2.0/cs/ExhaustiveMatching.Analyzer.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.. [/Users/anthonyiacono/Desktop/boopdoop/ExhaustiveBugRepro/PortableLibrary/PortableLibrary.csproj]
1 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.88
@WalkerCodeRanger Just a small update. This also happens on .NET Core 2.2.402. It stops happening when I use 3.1.302
in my global.json. I would upgrade the project from .NET Core 2.2 to 3.1 but I think it would be a pretty huge effort currently.
Thanks for the reproduction. I can see the warning now. Interestingly, it doesn't get reported through Visual Studio, only the command line.
When you are getting that warning, it means that the ExhaustiveMatchAnalyzer
isn't being run and you aren't getting the exhaustiveness checking. If you, for example, leave out typeof(Dog)
from the Closed
attribute of Animal
you won't get an error.
Referencing Microsoft.Net.Compilers
package 3.3.1 appears to fix the issue. That is the package that actually contains Microsoft.CodeAnalysis.dll
. Note that the warning message refers to the assembly version as 3.3.0.0, but that doesn't always match the package version. Referencing Microsoft.Net.Compilers
may have other consequences that you may or may not be able to live with. I believe it effectively changes which version of the compiler is being used to compile your code.
My initial research indicates this is a complex issue. It will take a while to figure out the correct way to handle this going forward, but hopefully installing Microsoft.Net.Compilers
3.3.1 will be an acceptable workaround for now.
@WalkerCodeRanger Thanks for looking into this! I'm trying to push our team to move to the newer packages (ie: .NET Core 3.1 etc) so hopefully we are able to just avoid workarounds. I guess I have a very naive suggestion (which probably won't work but worth a shot): Would it change anything if ExhaustiveMatching just upgraded the version of Microsoft.CodeAnalysis that it used? Or does it require the older version for maximum compatibility?
@APIWT Annoyingly, it's a limitation of the version of Visual Studio and not the version of the .NET Framwork/.NET Core/.NET Standard.
https://docs.microsoft.com/en-us/visualstudio/code-quality/install-fxcop-analyzers?view=vs-2019
- Visual Studio 2019: use latest
- Visual Studio 2017: use 2.9.9, 2.6.4, 2.3.0-beta1, or 2.0.0-beta2 depending on your VS 2017 patch level.
- Visual Studio 2015: use 1.1.0 or 1.0.1 depending on your VS 2015 patch level.
@Jehoel That makes sense. I appreciate the explanation!
I've decided on a plan for how to handle analyzer version compatibility and documented it in the Versioning and Compatibility section of the readme.
Once this is actually implemented I will close this issue.