Techtips

With release of .NET and .NET Core one significant change you may have noticed is the new version support lifecycle. .NET Framework LTS (long-time support) versions are normally supported for 5+ years by Microsoft but support lifecycle for .NET and .NET Core LTS versions has decreased to 3 years. The main reasons for the shorter support lifecycle are the overall faster technology evolvement, but also more active framework development which requires frequent releases both from the functional and security perspective. ...

There is one scary property in .NET which, if misused or forgotten, can make your security champions tremble at night…🙀🙀🙀 As scary as it sounds, the risk of forgetting or misusing the property is pretty serious and I've seen it multiple times sneaking into the source code as part of the pull request. And I keep seeing it still. Therefore this tech tip gets to see the world.☀️ The property I'm talking about is ServicePointManager.ServerCertificateValidationCallback that is part of a System.Net library. This property can be used for custom certificate validation in case you're using a non-trusted certificate authority. One of the scenarios when you can end up using this property is when you're developing and testing new functionality and you're using a self-signed TLS certificate on the server instead of production-level certificates. If this property is not set and you're using a non-trusted certificate, you may get errors like: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ...

In some cases you may have an Microsoft Entra ID tenant that doesn’t have an active subscription connected to it but you would nevertheless want to log in to it from a command line for instance, with Azure CLI. You may want to perform actions like creating a Microsoft Entra ID Application for example. In this case you need to be cautious about the login command you’re running so that you don’t waste a lot of time on debugging an error you could have avoided in the first place (like someone did 😁)! ...

Following up on the recent blog post series about Continuous Delivery to AKS with Azure DevOps Environments: 🐱 Part 1 🐱 Part 2 I would like to share a simple but really useful way to re-use the same Azure DevOps Environment in multiple deployment stages across multiple pipelines. Normally if you want to deploy multiple applications to the same AKS cluster, you would specify a target Azure DevOps Environment by writing it's name in environment property of deployment stage of every application: ...

Use case for pipeline templates In the world of complex enterprise applications and distributed systems you may have a need to perform many more actions and validations as part of a build pipeline than before: build an application, execute multiple types of tests like unit tests and API tests, perform security validations like SCA, SAST, container image scanning and scanning of third-party dependencies, perform application packaging and deployment, etc. That's when it's worth considering to implement a multi-staged pipeline where you can run several jobs in parallel and control application flow with stages. Each stage may then have it's own set of checks and validations. You may even have multiple applications which have similar build tasks as part of the build pipeline - for instance, if you have multiple .NET Web API applications, it's very likely that build pipelines for those will be similar to some extent. ...