In Visual Studio 2022, API project created using .NET Core 6.0.6 runtime, we are using Microsoft.EntityFrameworkCore.SqlServer 6.0.3 nuget package. But recently found that there is a security vulnerability in the System.Drawing.Common 4.7.0 package.
We use TFS CI Build Pipeline to build and release our software.
Please let us know how to overcome this security risk (we are using Blackduck compliance scan) and apply the patch/ changes to be made in TFS CI build pipeline script and deploy the software, but still use .NET Core 6.0.6 runtime, as we do not want to upgrade the .NET Core version to 7.0.
P.S: We are aware that the System.Drawing.Common vulnerability is cleared in version 4.7.2, 4.7.3 and also in >= 5.0.3 versions.
But still the security risk is reported by the Blackduck compliance scan.
What we have tried:
We have manually added the System.Drawing.Common package version 4.7.3 to the project and noticed that the package Microsoft.EntityFrameworkCore.SqlServer 6.0.3 is now internally referring to the System.Drawing.Common version 4.7.3.
But still the security risk is reported by the Blackduck compliance scan.
Referred links:
https://www.nuget.org/packages/System.Drawing.Common/4.7.0#versions-body-tab
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-24112
Related
I keep getting this error when I try to run the pipelines for my azure backend functions:
[error]C:\Users\VssAdministrator.nuget\packages\microsoft.net.sdk.functions\1.0.27\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): Error : It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
It's a pretty old program, but yesterday was the first time that the build has failed and I don't know how to fix it. It happens both in the develop and main branch so I'm guessing it's a change from Azure.
As documented in this GitHub issue .NET Core 2.1 has been removed from all build agent images.
Possible impact
If your project depends on a pre-installed .Net 2.1 it can be broken.
You can try to use the setup dotnet task to explicitly install .NET Core 2.1.
- uses: actions/setup-dotnet#v1
with:
dotnet-version: '2.1.x'
Please be advised .NET Core 2.1 has been out of support since August 21, 2021 (see .NET and .NET Core Support Policy). An upgrade to a currently supported version like .NET Core 3.1 or higher should not be a lot of work and is well worth the effort.
We build our web app with Azure DevOps pipelines and deploy into Azure with an Azure DevOps release. I think today netcore got updated to netcore 3.1.4 on our build agent. But now our Azure DevOps deployment fails, because the netcore 3.1.4 runtime is not yet installed on our app service in Azure.
The error message we are getting:
Could not find 'aspnetcorev2_inprocess.dll'. Exception message:
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.4' was not found.
- The following frameworks were found:
2.2.8 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.0.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.1 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
3.1.3 at [D:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
This makes sense and can happen, but what is the best way to go about fixing this?
I could fix my build to a specific netcore version. But I don't like this, because we do want to keep updating to newer versions, but we don't want a version that is not available in Azure app service.
Am I correct in thinking that we would have to install our services self contained, because otherwise we could get into this issue more often when Azure DevOps is faster with installing patches than Azure?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
I just need some guidance in what is the best approach to fix this issue?
Or is there a way to force update Azure app service to the new netcore 3.1.4 security patch which would be ideal I think?
AFAIK, there is no such a way to force update Azure app service to the new netcore 3.1.4.
We could keep track on the latest releases on the https://aspnetcoreon.azurewebsites.net/, but we could not update it at this moment.
To resolve this issue, we recommend that you publish your app as self-contained produces an application, which includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed.
Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET Core libraries and target runtime. The app is isolated from other .NET Core apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET Core.
You could check this document .NET Core application publishing overview for some more details.
Hope this helps.
If you want version of netcore to be automatically updated as an updated version is available, building our service as self-container seems like a good option: no need to have anything installed on the machine running (ie the version on Azure DevOps and Azure Web App don't have to match).
The main downside of this approach is that the build is going to less deterministic: running your build twice with on the same commit might create different binaries depending on what is currently install on the build agent. if you want to know more, here is an interesting post arguing about why deterministic build is important.
To keep the build determinitic, you can use the Use .Net Core task at the beginning of the build (that will make sure that the desired version of the dotnet sdk is on the agent). You could also add a global.json in your repository to lock for both the build on your dev box and in Azure Dev Ops.
This is a common topic of discussion, and you can find a lot of blogs advocating one or another side.
There were big discussions started when Microsoft released LTS net core 3.1 and it took some time before Azure start supporting the 3.1 runtime as well.
You could find a lot of blogs strongly suggesting to deploy your web apps as self-contained (runtime is ~100MB in size) and cut loose the dependency towards Microsoft supporting the latest runtime. While others advocate that the applications should remain as light weight as possible and the runtime should be set in the pipeline. But that is still up on you. I, myself prefer to deploy self-contained apps after my bad experience with net-core 3.1.
There is no established best practice.
In the past , I've run into the same situation, you can fix this by manually setting the value from RunTime Stack drop down. If you manually update the build processes .yml file
RuntimeStack: 'DOTNETCORE|3.1'
I am working on a PCL project that is using Profile44 as TargetFrameworkProfile. When I try to install NodaTime 2.2.4 I get the following error message:
Could not install package 'NodaTime 2.2.4'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.6,Profile=Profile44', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
Do I have to downgrade to .Net 4.5 or what options do I have?
Noda Time 2.x only supports the Target Framework Monikers netstandard1.3 and net45. There's no direct PCL support, although some environments that traditionally used PCLs now support .NET Standard.
The 1.x series supports PCLs via Profile328, which has a NuGet target of "portable-net4+sl50+win8+wpa81+wp8". For environments that don't yet support .NET Standard, trying the 1.x series is the best option.
Note that I'm expecting Noda Time 3.0 to probably target netstandard2.0, although I'll still keep the older versions up to date with respect to time zone data.
Does Microsoft publish release notes for individual nuget packages?
I noticed a few nuget packages with a 'dot' release (which leads me to believe some bugs were resolved) but I can't find information about what exactly was fixed in these dot releases.
Here are a few examples, picked at random, of packages released by Microsoft:
System.Net.Http version 4.3.2
System.Reflection.Metadata version 1.4.2
System.Collections.Immutable version 1.3.1
Microsoft.Data.OData version 5.8.2
Microsoft ASP.NET Identity Core 2.2.1
The description for most of these packages says that release notes are available at https://go.microsoft.com/fwlink/?LinkID=799421 but that's a link to the release notes for .NET Core 1.1.0 Preview 1 released 10/24/2016, nothing specific to the packages.
An example of a Microsoft nuget package that publishes very clear release notes for each version is Windows Azure Storage.
According to this article some support for older versions of Azure are going away:
https://azure.microsoft.com/en-us/blog/microsoft-azure-storage-service-version-removal/
We have a vs2008 application that is uploading files to Azure. {Using Azure 1.2 (for VS2008) - Microsoft.WindowsAzure.StorageClient v1.0.0 - Runtime v2.0.50727}.
We can't have this break since we are using this in production.
I need to know if there is a clear way to know if this is going to stop working.
I would really like to know if there is a way to upgrade the vs2008 project to use a compatible version of the StorageClient without migrating the project to vs2015.
Your version of the library should still be supported after the service removal. You can confirm which version of the service you are hitting by running requests through Fiddler and checking the x-ms-version. As you can see in the most recent post regarding our service deprecation, we are only removing version 2009-07-17 and older as of August 1, 2016.