Solution consists of 2 dll libraries, 1 console app and 1 web app. Only the last project, the web one, uses Microsoft.Net.Compilers NuGet package. Package has been updated to version 2.3.0 now, what means C# 7.1 and VB 15.3.
source: Roslyn NuGet packages
As 3 other projects do not have Microsoft.Net.Compilers NuGet package installed, what Roslyn compiler and C# version do they use?
I use VS.Net 2017 15.2 with .NET Framework 4.7, so I would guess it shall C#7.0, but still Microsoft.Net.Compilers in version 2.2 should be installed there, but is not.
The Microsoft.Net.Compilers package overrides (by setting properties in your project file) the default version of Roslyn included with MSBuild / Visual Studio.
Regular class libraries that don't reference it are compiled using the Roslyn build included with your version of Visual Studio & MSBuild.
Related
I'm working on a Roslyn C# analyzer, and need to use the RecordDeclarationSyntax type from newer versions of the Microsoft.CodeAnalysis.CSharp nuget package from 3.3.1 to 4.2.0. Unfortunately, it seems that if I upgrade the package alone, I get the following compile error:
error NU1605: Detected package downgrade: Microsoft.CodeAnalysis.Analyzers from 3.3.3 to 2.9.8. Reference the package directly from the project to select a different version.
This makes sense, since the Microsoft.CodeAnalysis.Analyzers version should have the version corresponding with the Microsoft.CodeAnalysis.CSharp release.
If I upgrade both packages (Microsoft.CodeAnalysis.CSharp to 4.2.0 and Microsoft.CodeAnalysis.Analyzers to 3.3.3), the solution compiles, but the analyzer fails to run.
Is there any way that I can use the latest Microsoft.CodeAnalysis.CSharp APIs within an analyzer?
Be mindful when updating the version of the Roslyn packages, because it's a tooling breaking change: greater versions of Roslyn require greater versions of the .NET SDK / Visual Studio (which ships with a .NET SDK in-box) as a consumer.
Have a look at the compatibility of the Roslyn NuGet packages.
If you publish your .NET Analyzers publicly (e.g. via NuGet.org), I suggest targeting the lowest version of Roslyn necessary (where the respective major version of the .NET SDK is still supported) for the widest range of compatibility:
When you just need the C# 9.0 RecordDeclarationSyntax, then prefer targeting Microsoft.CodeAnalysis.CSharp 3.8.0, which requires the .NET SDK 5.0.100 / Visual Studio 2019 v16.8.0.
When you also require the C# 10 ClassOrStructKeyword on record, then prefer targeting Microsoft.CodeAnalysis.CSharp 4.0.1, which requires the .NET 6 SDK 6.0.100 / Visual Studio 2022 v17.0.0.
If you publish and consume your .NET Analyzers within a controlled environment (e.g. within your organization), then I guess targeting the latest version of Roslyn is fair, with the requirement of keeping the .NET SDK / Visual Studio also up to date.
In case someone else has this issue, it took a little bit of digging around, but I ended up needing to update Visual Studio to the latest version, and the .NET SDK to the latest LTS.
I am working on a Visual Studio solution with two projects which I will call Red.dll and Blue.dll for the purpose of this question. Note that Red.dll depends on Blue.dll. These are both compiled in .NET Standard 2.0 with the output type of "Class Library".
I added the dll of each project to a common NuGet package called "Red" using NuGet Package Explorer. It has the following structure:
lib
- netstandard2.0
- Red.dll
- Red.xml
- Blue.dll
- Blue.xml
Here is the problem: When I attempt to install this NuGet package to a .NET Core application, I receive the following error:
Error NU1101: Unable to find package Blue.dll. No packages exist with this id in source(s): Desktop, Microsoft Visual Studio Offline Packages, nuget.org
Blue.dll is not a NuGet package. I don't know why it thinks it is.
Blue.dll is located directly beside Red.dll.
There are no external dependencies other than Newtonsoft.Json which is irrelevant.
And to reiterate, Blue.dll is NOT a NuGet package dependency. I realize if you use the "Pack" feature in Visual Studio it will create a dependency, but I created this NuGet package manually to avoid that.
But most importantly: This all works perfectly in .NET Framework! The NuGet package successfully installed, both dlls are referenced, the code builds without any errors, and the XML documentation is accessible.
Why does this work in .NET Framework but not .Net Core?
I haven't found anything else online about this particular problem.
I added WhiteSource Bolt to my Azure DevOps pipeline and noticed that it was reporting CVE-2017-0247, CVE-2017-0248, CVE-2017-0249 vulnerabilities after I upgraded the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package from version 2.0.0 to 2.0.1
The issue is being caused by an old version of System.Net.Http (4.6.24705.1) being included in the bin\roslyn folder.
To keep it simple I have created a new empty web project which just has the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package. I started using version 2.0.0 of the package. When building using this package the roslyn folder has version 2.8.2.62916 of the C# compiler which doesn't have the dependency on System.Net.Http. When using this version all files in this folder have a date modified of 24/05/2018
I then updated the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package to version 2.0.1. After building the solution the roslyn folder had version 2.9.0.63208 of the C# compuler which has a dependency on System.Net.Http. The files in the roslyn folder have a variety of dates from 2018, 2017 and 2016.
Whitesource is detecting the old version of System.Net.Http and flagging it up since it is effected by the above mentioned CVEs.
I have uploaded my code to https://github.com/rubenmamo/CVE-2017-0248-Test
Unfortunately I don't really understand how roslyn is used in Asp.Net projects and am not sure whether it is safe to use the 2.0.1 version of the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package. It looks odd that Microsoft would have released a package in September 2017 with such an issue without fixing it.
I'm not sure I'm missing something :|
Visual Studio 2017 (15.x) supports C# 7, but what about Visual Studio 2015 (14.x)?
How can I use C# 7 with it?
You can replace the compiler shipped with Visual Studio for a C# 7-enabled version by installing the Nuget package Microsoft.Net.Compilers:
Referencing this package will cause the project to be built using the
specific version of the C# and Visual Basic compilers contained in the
package, as opposed to any system installed version.
There is no indication that I can see on the package page as to whether this is officially supported in Visual Studio 2015. My not-thorough tests so far indicate that it works but not painlessly - C# 7 code compiles, but is underlined with the red squiggly line which indicates a syntax error:
Note that you will also need to install the Nuget package System.ValueTuple to use the new C# 7 value tuples features.
In my case, installing just Microsoft.Net.Compilers didn't work. Instead, I had to do the following:
Install Microsoft.CodeDom.Providers.DotNetCompilerPlatform for the project (Tools => NuGet Package Manager => Manage Nuget Packages for Solution...) and install Microsoft.CodeDom.Providers.DotNetCompilerPlatform.Install the latest Microsoft.Net.Compilers for the project
Install any other NuGet package for the latest C# feature you want to use. In my case, my goal was to use Tuples, so I installed System.ValueTuple and worked fine.
But still note that C# codes which are not known by Visual Studio 2015 default compiler will still have red squiggles underneath.
I would like to install protobuf-net using NutGet and Visual Studio 2012.
However, if I try to install it, I got the following error message from NuGet :
'protobuf-net' already has a dependency defined for
'NETStandard.Library'.
I have tried to install NETStandard.Library but there is an error :
The 'NETStandard.Library 1.6.0' package requires NuGet client version
'2.12' or above, but the current NuGet version is '2.8.60318.667'.
I also tried to update NuGet (by uninstalling it then re-install), but it seems with Visual Studio 2012 it is stuck to 2.8 version.
I don't have Visual Studio 2012 to test, but I wonder if this is due to the way Nuget now works with the .Net Core dependencies. It should work if you install an older version of protobuf-net. You can see that the older version doesn't mention .NETStandard as a dependency. To do this, from the package manager console, type this:
Install-Package protobuf-net -Version 2.0.0.668
I found that this protobuf-portable-net works on .NET 4.5 for VS 2013 and has the same version number as above: 2.0.0.668. It's the same author and might be a better approach than intentionally installing an old version of a newer package.