Head in the Cloud

Most of the time, your solution will have more than one project and a test unit project for each of those. Azure DevOps only, as of this writing, only allows you to update a single code coverage summary. If you upload more than one, each overwrites the next and only the last one remains. To accomplish this, we can use the merge functionality in Coverlet . I use the MSBuild extension, because it is better suited for CI pipelines. In your test project XML, add the package... <PackageReference Include="coverlet.msbuild" Version="2.7.0">     <PrivateAssets>all</PrivateAssets>     <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets> </PackageReference> Then, in your dotnet test command or msbuild command, tell it to use Coverlet and to merge results. If you're using Azure DevOps, your test task looks this... (line wrapped for read ability in the article) - task: DotNetCoreCLI@2 displayName: Test i

I ran into a scenario where my solution had libraries targeting netStandard2.0 and/or net461. For the libraries targeting just net461, I created a “MSTest Unit Test Project (.Net Framework)” project–the “old” project system. The tests ran fine in Visual Studio, but in my CI build, I wanted to keep it simple and run all the tests with dotnet test. However, this tooling cannot see/run the old test project. So, as an experiment, I tried creating a test project in the new project system, and changing the target moniker from NetCoreApp to net461.  It worked! both dotnet test and Visual Studio can run the tests. It’s worth noting that the library is also the new project system. I haven’t tested if that matters. Test Project XML <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net461</TargetFramework> <IsPackable>false</IsPackable> </PropertyGroup> <ItemGroup> <PackageReference Include="Mic

Automate all the things! The same goes for security checks in our application. Continuous Security is the automation of these checks as part of the continuous delivery pipeline. The type of check determines where the check can, or should, go. Static testing (SaST), for example, should happen outside of, but be triggered by, CI. Dynamic Testing (DaST) happens outside of, but triggered by, deployment. Another scan we can, and should, perform is a security analysis of packages we’re pulling into our applications. This can happen during CI, and the build or pull request can be rejected if packages with known vulnerabilities are used. There are several tools emerging in this space, one of which is  Snyk.io . These tools compare your imported packages and versions to those listed in various CVE databases to determine if a package has a known vulnerability, and, if applicable, report the version you should upgrade to in order to patch the vulnerability. Some tools, like Snyk or even  G

Starting with version 5.1, NHibernate now supports .Net Core and .Netstandard as well as the full framework. Let’s take a quick look at how to set it up in an ASP.Net Core 2.x/3.x application. Configuration As of this writing, NHibernate doesn’t support the configuration system within Asp.Net Core based on Microsoft.Extensions.Configuration. The good news is, you don’t have to use a  hibernate.cfg.xml  file or the   section in app.config. You can add the properies manually, and pull the values from Asp.Net Core’s configuration, taking advantage of all the goodies that come with it. This opens up a world of configuration deployment possibilities. var config = new Configuration (); IDictionary < string , string > properties = new Dictionary < string , string > { { "connection.connection_string" , Configuration . GetConnectionString ( "Default" ) }, { "dialect" , "NHibernate.Dialect.SQLiteDialect" },