Just show me the code As always if you don’t care about the post I have upload the source code on my Github. SonarQube is one of the most well-known code review tools in the dotnet space. It is used mainly to detect bugs, vulnerabilities and code smells in your codebase and it can be integrated with any workflow to enable a continuous code inspection across multiple branches and pull requests.
Just show me the code As always if you don’t care about the post I have upload the source code on my Github. In today’s post I want to talk about how you can secure a .NET graphQL API using Azure Active Directory (AAD). If you want to build a graphQL API in .NET right now, the most well-known options available are the graphQL.NET implementation (https://graphql-dotnet.github.io/) and the HotChocolate one (https://chillicream.
Just show me the code As always if you don’t care about the post I have upload a few examples on my Github. Nowadays creating a new dotnet gRPC application is pretty straightforward. From the developer standpoint the experience of creating a gRPC app it’s quite similar to creating an API, furthermore, Visual Studio also offers Intellisense support for gRPC services and proto files. As I stated before developing a dotnet gRPC app right now is an easy feat, but when you try to deploy it in some cloud provider that’s when some wrinkles might appear.
This is a 2 part-series. Part 1: Key concepts that you should know when creating a .NET template. If you want to read it, click here Part 2: How to convert a few .NET apps into .NET templates, package them together in a single NuGet pack and use them as templates within Visual Studio. Just show me the code As always if you don’t care about the post I have upload the source code on my Github.
This is a 2 part-series. Part 1: Key concepts that you should know when creating a .NET template. Part 2: How to convert a few .NET apps into .NET templates, package them together in a single NuGet pack and use them as templates within Visual Studio. If you want to read it, click here When you install the .NET SDK you receive a handful of built-in templates for creating projects like console apps, web apis, class libraries, unit test projects, etc.
Show me the code If you don’t care about the post I have upload the code on my Github A few months ago the first stable version of the OpenTelemetry client for dotnet was released and since then I have wanted to write a little bit about it. OpenTelemetry is a set of APIs, SDKs, tooling and integrations that are designed for the creation and management of telemetry data such as traces, metrics, and logs.
Roslyn Analyzers are extensions that analyze source code and report violations. Some analyzers are built-into VS (like the IDE analyzers that report style issues) and some are third party ones which can be installed (like StyleCopyAnalyzers, FxCopAnalyzers, etc.). Analyzers can be configurated using file(s) to allow end users to control the behavior of each analyzer and severity of reported diagnostics. This may be via an editorconfig or a ruleset file or even completely custom format specific to the third party analyzer package.
A pretty common scenario in complex .NET applications is having them splitted in multiple csharp projects inside a single solution, even with the proliferation of microservices is pretty common seeing the client and the business logic decoupled in multiple projects inside a single solution. And that behaviour is even more common if you’re using some kind of software architecture like “Domain Driven Design”, “Hexagonal Architecture” or “Clean Architecture”. A common problem that usually appears when the number of projects begins to pile up inside a single solution is mantaining consistency between nuget versions, and quite some times you end up with every project using a different version of the same package.
Nowadays no one on his right mind is going to create a WCF from scratch. It really makes no sense to do it. It’s a deprecated technology, it does not work with .NET Core, only works on Windows OS and personally I found the configuration confusing as hell, every time I need to modify an existing one I have to spend a good amount of time trying to figure out what everything means.
In these past few years Microsoft has kept a steady flow of new .NET Core versions: .NET Core 1.0, 1.1, 2.0, 2.1, 2.2 and so on and so forth. If you have hundreds of applications in your company, it’s almost impossible to keep them updated to the most recent version of the framework, so most probably you’re going to end up having multiple versions running at the same time. When trying to choose which versions are you going to support in your company a factor to consider is that only a few of those versions are long-time support (LTS).