Closed mwpowellhtx closed 5 years ago
Rolling back from Microsoft.CodeAnalysis.CSharp 3.0.0
to 2.10.0
appears to resolve the issue. Or my assemblies at least build.
For what I am trying to accomplish actually, it is starting to be a block for me. Really need that netstandard2.0
dependency to be there.
The netstandard version we target isn't itself the first level goal. It's compatibility with particular versions of Roslyn. VS 2015 targeted netstandard1.3, if I recall correctly, and compatibility with that was the goal. As we now have VS 2019 released, dropping VS 2015 support makes perfect sense. Targeting the version of Roslyn that shipped in 15.9 is probably fine.
@amis92 how do you feel about targeting netstandard2.0 and the 15.9 version of Roslyn?
If it's doable, yes please, netstandard2.0
. That's assuming there is backwards compatibility through VS2017.
Since #114 is probably a little farther away, we can probably push out a smaller update that upgrades the dependencies :) I'll try to push it out hopefully quite quickly.
So, since the project right now is completely independent of Visual Studio version, I've upgraded Roslyn to v3.0 and targeted netstandard2.0, and the tool itself now targets netcoreapp2.1.
The only requirements are:
Thanks to CodeGeneration.Roslyn not integrating with MSBuild now, the tool runs as a .NET Core app completely independent of all the other parts (VS, MSBuild, platform etc). The price is that we always use our own Roslyn version which we need to update manually.
Hello,
What is the constraint that is hindering the
netstandard1.6
versusnetstandard2.0
target frameworks?I ask because the latest (experimental? or at least a couple of the dependency dependencies are in beta, it seems) references to
Microsoft.CodeAnalysis.CSharp
are incompatible withnetstandard1.6
.For now, I'll just walk back the reference dependency versions, but it might be a migration path issue moving forward?
Thanks!