In my ASP.NET Core project, I am using an environment variable in the form of MyProject:MyVariableName and needed to create a Jenkins pipeline but I could not get it to recognize that format. It kept making the environment variable name just MyVariableName. Below is the code from the Jenkinsfile that I tried that was causing the issue. stage('Run All Test') { environment { MyProject:MyVariableName = "Some Value" } } Turns out that Jenkins does not recognize the : in environment variable names.
In our previous post, we split all of the entity configurations by table into their own configuration mapping file. The next step is to create a base class that all of the configuration mappings inherit from where we can put configurations that all entities should get.
An example of where we will use the global configuration is the soft deletes that we implement previously where we want to exclude all of the rows that have the IsDeleted flag set to true but we do not want to have to remember to add that code to all of the entities and we don’t want to have to remember to add it to every query.
With EF Core, you configure your entities (e.g. tables) using the OnModelCreating in your database context. It is easy to just put all of the configurations into that OnModelCreating method which for just a few entities works great. However, as the number of entities grows, OnModelCreating easily becomes unwieldy with thousands of lines of configuration code.
In this post, I am going to show you how you can move the configuration for each of your entities to it’s own file and just have to put a single line of code in the OnModelCreating for each entity. This will greatly simplify the management and maintenance of the entity configuration code.
When dealing with databases, there are times when you want a column to only allow certain values. When using EF Core, the easiest way to accomplish this goal is to use an enum as the type for the property.
In this post, we will add a new column to an entity that is of an enum type, set the default value, and create the migration script.
In several applications I work on, in addition to the soft deletes that we implemented in the previous post, we also have a requirement to implement audit tracking. Audit tracking is the tracking of who created the record, the date the record was created, who was the last person to update the record, and the last updated date of the record.
In this post, we will implement audit tracking so that the audit fields are automatically added onto our entities and EF Core automatically sets the values when save our entity.
In several applications I work on, we have a requirement that we are not allowed to delete any data out of the database physically. Instead, when we need to delete a record, we set an IsDeleted column to true and exclude the row from our queries.
In this post, we will be implementing soft deletes on an example project.
So far in our AutoMapper series all of the property names between the input and output objects have been the same. There are times though that the property names will not match and you will need to tell AutoMapper how to map the properties else the configuration will not be valid.
In this post, we will take a look at the AutoMapper configuration need to map between property names that do not match.
In our previous post, we used AutoMapper to convert from a entity to a view model. In our example code, it only works as expected in happy path mode where the configuration is valid and there is no way to know the configuration is not valid until we run the application.
In this post, we are going to look at how with just a few lines of code, we can write a unit test to validate our AutoMapper mapping profile.
Mapping code is boring. Testing mapping code is even more boring.
AutoMapper is a simple library built to map one object to another and takes out all of the fuss of mapping one object to another.
In this post, we will create a sample ASP.NET Core API project, install and wire up AutoMapper, and update the sample Weather Forecast Controller to return a view model that was converted from our concrete object to a view model object.
In the previous post in the series, we have implemented our health checks that return a json response and allow us to selectively run the health checks based on tags.
In this post, we are going to build on the previous post and update our endpoint mappings to use a generic endpoint builder so that we only have our filters and json response code in a single place.
In part 1 we create our basic ASP.NET Core health check and then in part 2 we changed from plain text “Healthy” or “Unhealthy” to a json response that let us know the stauts of each health check.
In our previous post, we have only have a single health check so it has been ok to have all health checks run when we hit our health check endpoint. However, if we had multiple health checks we are going to want to be able to run them by themselves as well as run the whole suite.
In this post, we will are going to add the ability to selectively run our health checks and create endpoints that will run either a set of health checks or all of the health checks.
In our previous post, we added a simple health check to our ASP.NET Core application. Although we only added a single health check, you can add multiple health checks and have multiple run as once. Regardless if you run a single or multiple health checks, the implementation out of the box, just returns a “Healthy” or “Unhealthy” string, which is not overall helpful to know which component actually failed.
In this post, we are going to update our health check response to return a json record that will let us know the status of each health check that is run as well as the overall health status of the application.
{
"status": "Healthy",
"duration": "00:00:00.0066738",
"info":
[
{
"key": "ExampleHealthCheckAsync",
"description": "Health Msg Here.",
"duration": "00:00:00.0010113",
"status": "Healthy",
"data": {}
}
]
}
If your ASP.NET Core application communicates with any 3rd party systems, it is beneficial to have health checks to determine if your connection to the 3rd party system is healthy, degraded, or unhealthy.
With ASP.NET Core, Microsoft references Microsoft.AspNetCore.Diagnostics.HealthChecks package implicitly for ASP.NET Core apps. This means that everything you need architecture wise is available and you just need to create your actual health check code.
In our previous post, we talked about how TeamCity automatically combines multiple dotCover outputs into a single code coverage report but what if we wanted to keep thoose reports seperate?
You might be thinking why would you want to do this? Don’t you want to see the overall test coverage?
The overall coverage is nice but when you have both unit tests and integration tests, or multiple test projects serving different purposes, there is a high potential that you are reporting lines of code being covered that were only called but not actually tested.
In this post, we are going to look at how in TeamCity you can run multiple test builds to generate both individual reports and still have a combined report.
In TeamCity, what if you need to combine the code coverage results say from unit test and integration test projectsthst run as seperate build steps?
Luckily, TeamCity does this work for you but it is not obvious that it will do it for.
To get TeamCity to combine the multiple the code coverage results into a single code coverage result, you just need to add the echo command to import the data into the build like we did in our previous post
In part 1 and part 2 of of this article series, we setup and optimized our code coverage using the free command line version of dotCover.
In this post, we are going to add our code coverage to our TeamCity builds to run our unit tests with code coverage as part of the automated builds, show us the code coverage metrics summary after the build, be able to view the code coverage report right in TeamCity and add failure metrics for if code coverage percent drops.
In part 1 of the ASPNET Code Coverage Using dotCover, we hooked up dotCover to our project to generate our code coverage report. It was pretty easy to hook it up but the number is not the most accurate as it includes every file that is part of the solution including our test project and all of the ASP.NET WebApi code.
When looking at code coverage, we only want to include files that make sense to test against so that our code coverage number is the most accurate. So that means we should exclude our unit tests project from the report since we are not going to run tests against our test projects. Same thing with the ASP.NET WebApi startup.cs, program.cs and Controllers as we would want to test those using integration tests and not unit tests.
Having automated tests is a good thing to have to help with your code quality but having those tests without any idea of how much of your code is actually being tested is a really bad thing.
To figure out how much of our code we are actually testing, we need to create a code coverage report. To generate our code coverage report, we going to use the JetBrains dotCover tool.
If you are using Git as your version control system, you need a .gitignore file to keep all of those user specific files out of Git like the bin/obj directories. You could manually create and configure the .gitignore file but why do it yourself when others have already done it for you. A quick search and you will run across the gitignore repo where you could download a premade file but what about if you had a tool to do this for you?
With the release of .NET Core 2.1 the .NET Core CLI includes a feature called Global Tools that provides a simple way to create and share cross-platform console tools. When you install a global tool, the CLI will download a special NuGet package that contains a console application and make your console tool available as a new command from the command line. Note: You will need to download .NET Core 2.