Unit Tests, Integration Tests, and End-to-End Tests: What’s the Difference?

• Unit tests focus on testing individual units or components of your application in isolation. This type of test verifies whether the unit/component works correctly and adheres to its business logic.
• Integration tests aim to test multiple units or components together, ensuring that they interact properly. Integration tests can uncover issues related to data flow, communication between components, and external dependencies like databases.
• End-to-end (E2E) tests simulate a complete user scenario by testing the entire application from start to finish. E2E tests can help identify issues related to multiple components, external APIs, and user interfaces.

public class InMemoryDbAppFactory : WebApplicationFactory<Program>
{
    private readonly string _environment;

    public InMemoryDbAppFactory()
    {
        _environment = "IntegrationTests";
    }

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        Environment.SetEnvironmentVariable("ASPNETCORE_ENVIRONMENT", _environment);
        builder.UseEnvironment(_environment);
        builder.UseSetting("https_port", "8080");

        builder.ConfigureTestServices(services =>
        {
            services.RemoveAll<ITestRepository>();
            services.TryAddTransient<ITestRepository, TestRepositoryTest>();

            // Anonymous authentication
            services
                .AddAuthentication("Test")
                .AddScheme<AuthenticationSchemeOptions, TestAuthenticationHandler>("Test", options => { });
        });
    }
}

public static partial class ServiceCollectionExtensions
{
    public static IServiceCollection AddDbContexts(
        this IServiceCollection services,
        IConfiguration configuration,
        IWebHostEnvironment environment
    )
    {
        if (environment.IsEnvironment("IntegrationTests"))
        {
            var connDb = new SqliteConnection("DataSource=db;mode=memory;cache=shared");
            connDb.Open();
            services.AddDbContext<dbContext>(options => options.UseSqlite(connDb));
        }
        else
        {
            services.AddDbContext<dbContext>(
                options => options.UseSqlServer(configuration.GetConnectionString("ConnectionString")).UseExceptionProcessor(),
                ServiceLifetime.Scoped
            );
        }

        return services;
    }
}

[Collection("MemoryDbIntegrationTests")]
public class ApiTests : IClassFixture<InMemoryDbAppFactory>
{
    private readonly InMemoryDbAppFactory _factory;
    private readonly HttpClient _client;

    public ApiTests(InMemoryDbAppFactory factory)
    {
        _factory = factory;
        _client = factory.CreateClient();

        // Ensures a clean database before each test
        factory.ResetDb();
    }

    [Fact]
    public async Task GetList_Should_Return_List()
    {
        // Arrange

        // Act
        var response = await _client.GetAsync("/api/list");
        var content = await response.Content.ReadFromJsonAsync<IEnumerable<Dto>>();

        // Assert
        response.EnsureSuccessStatusCode(); // Status Code 200-299
        content.Should().NotBeNull();
        content.Should().HaveCount(2);
    }
}

Using an in-memory database for integration tests has both advantages and disadvantages:

Advantages:

• Faster test execution: In-memory databases provide quicker test execution times since the data is stored in memory instead of on disk. This can significantly improve your overall testing performance and help you find issues faster.
• Easy to set up and tear down: In-memory databases are easy to create, modify, and delete without the need for external dependencies or configuration changes. This makes it easier to write, run, and maintain your tests.
• Consistent test data: In-memory databases allow you to create a known set of data for your tests, ensuring that each test starts with the same initial conditions. This can help reduce the likelihood of inconsistent test results and make it easier to identify issues related to data flow or dependencies between tests.

Disadvantages:

• Limited scalability: In-memory databases have limited capacity and may not be suitable for testing large datasets or complex scenarios that require high levels of concurrency.
• Lack of realism: In-memory databases may not accurately represent the behavior or performance of a production database, especially when dealing with complex queries or data modification operations. This can make it difficult to identify issues related to database schema, indexing, and query optimization.
• Limited support for advanced features: using SQLite as our in memory database we don’t have support for multiple schemas and some advanced query features.
• Seed data: the need to create seed data can be tedious and time consuming.

When deciding whether to use an in-memory database, mock data, or a real web server in memory for your integration tests, consider the specific requirements of your project and weigh the advantages and disadvantages of each approach. In many cases, using a combination of testing types and approaches can help you ensure the stability, reliability, and performance of your .NET WebAPI application.

The post Integration Tests in .NET WebApi appeared first on Blog IT.

Introduction

An Azure SQL Server failover group is a group of databases that can be automatically or manually failed over from a primary server to a secondary server in a different Azure region in case of a disaster in the primary server. Failover groups provide high availability and disaster recovery for Azure SQL Server databases.

The process described in this post is composed by two main steps:

• Provisioning the database
• Adding the database to the failover group

Provisioning the database

The first step is to create the database. This step is composed by the following actions:

• Get the tenant information
• Create the database

Tenant information class:

Code to create database programatically:

Adding the database to the failover group

The second step adds the newly created database to the failover group. This step is composed by the following actions:

• Get the failover group where we want to add the database
• Re-add the existing databases to the failover group – necessary since when we get the failover group the list of databases of the group is empty and, without this step, the failover group would only have the new database
• Add the new database to the failover group

Other Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you want to learn how to develop SPFx solutions, click here.

If you want to learn how you can rename a modern SharePoint site, click here.

If you want to learn how to save time time scheduling your meetings, click here.

If you want to learn how to enable Microsoft Teams Attendance List Download, click here.

If you want to learn how to create a dynamic org-wide team in Microsoft Teams with all active employees, click here.

If you want to modernize your SharePoint classic root site to a modern SharePoint site, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If you prefer to use the traditional method to update your farm and want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated, click here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from Ignite and some more recent announcements, including Microsoft Search, What’s New to Build a Modern Intranet with SharePoint in Office 365, Deeper Integration between Microsoft Teams and SharePoint and the latest news on SharePoint development, click here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy Coding!

The post Provision a database programmatically in Azure SQL database with a failover group appeared first on Blog IT.

This post compares different strategies to dockerize a .NET 6 application and how to create a < 100mb docker image to host a .NET 6 asp.net web application. Using the docker multi stage builds feature and a self-contained .NET with some build options the final docker image can be reduced from 760mb to 83mb, almost 10x smaller!

All the images used were taken from the official Microsoft .NET docker repository.

1. .NET 6 SDK image

Let’s start with a simple Dockerfile based on the official .NET 6 SDK build image.

FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app

COPY . ./

RUN dotnet publish "WebApi.csproj" -c Release -o /app/publish

ENTRYPOINT ["dotnet", "/app/publish/WebApi.dll"]

$ docker build -t api-aspnet .
$ docker images api-aspnet
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
api-aspnet   latest    700870327c08   1 weeks ago   761MB

We are using a docker single stage build using the base .net sdk image. After building the image we can see that the final image size is 761mb. Let’s try to check where the space is being used. For that we can use the docker history to see the layers created for this image.

$ docker history api-aspnet
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
700870327c08   1 weeks ago    ENTRYPOINT ["dotnet" "/app/publish/WebApi.dl…   0B        buildkit.dockerfile.v0
<missing>      1 weeks ago    RUN /bin/sh -c dotnet publish "WebApi.csproj…   4.18MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    RUN /bin/sh -c dotnet build -c Release # bui…   12.2MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    COPY . ./ # buildkit                            721kB     buildkit.dockerfile.v0
<missing>      1 weeks ago    RUN /bin/sh -c dotnet restore # buildkit        28.2MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    COPY WebApi.csproj ./ # buildkit                327B      buildkit.dockerfile.v0
<missing>      1 weeks ago    WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      2 months ago   /bin/sh -c powershell_version=7.2.1     && c…   40.6MB
<missing>      2 months ago   /bin/sh -c curl -fSL --output dotnet.tar.gz …   392MB
<missing>      2 months ago   /bin/sh -c apt-get update     && apt-get ins…   74.8MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNETCORE_URLS= DOTN…   0B
<missing>      2 months ago   /bin/sh -c #(nop) COPY dir:a54b266469a09b122…   20.3MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNET_VERSION=6.0.1 …   0B
<missing>      2 months ago   /bin/sh -c ln -s /usr/share/dotnet/dotnet /u…   24B
<missing>      2 months ago   /bin/sh -c #(nop) COPY dir:6c537cc098876a5f6…   70.6MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV DOTNET_VERSION=6.0.1     0B
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNETCORE_URLS=http:…   0B
<missing>      2 months ago   /bin/sh -c apt-get update     && apt-get ins…   37MB
<missing>      2 months ago   /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>      2 months ago   /bin/sh -c #(nop) ADD file:09675d11695f65c55…   80.4MB

The .NET SDK + runtime takes most of the space, around 60%. So let’s try to shrink it.

2. .NET 6 SDK image + docker multi stage build

The previous section showed us that the .NET SDK + runtime takes most of the space of the final image. This is because we are using the same docker base image to build and to run the app so the final image has all the things needed to compile and run the app. Using a docker multi stage build we can cut the .NET SDK from the final image and use it only to build our app and include only the .NET runtime in the final image to run the application.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /app

COPY . ./

RUN dotnet publish "WebApi.csproj" -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime

WORKDIR /app
COPY --from=build /app/publish .

ENTRYPOINT ["dotnet", "WebApi.dll"]

Here we define 2 images: the build image used to compile the app which includes all the things needed to build our .NET 6 application and the final one, the runtime  which only includes the .NET runtime to run our app. The first one to use for development (which contained everything needed to build your application), and a slimmed-down one to use for production, which only contained your compiled code and what is needed to run it. With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image.

$ docker build -t api-aspnet-multistage .
$ docker images api-aspnet-multistage
REPOSITORY              TAG       IMAGE ID       CREATED       SIZE
api-aspnet-multistage   latest    1021a94feca4   1 weeks ago   212MB

Bang, we reduced our image to 212mb, this is because the complete SDK was removed from the final image.
Let’s see again the layers and the space being used for each one:

USER@DESKTOP-BJUBV5T MINGW64 ~/Documents/sonae/identitymanager-credenciaiscontinente (fix/invalid-account-association-check)
$ docker history api-aspnet-multistage
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
1021a94feca4   1 weeks ago    ENTRYPOINT ["dotnet" "WebApi.dll"]              0B        buildkit.dockerfile.v0
<missing>      1 weeks ago    COPY /app/publish . # buildkit                  4.18MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      2 months ago   /bin/sh -c #(nop) COPY dir:a54b266469a09b122…   20.3MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNET_VERSION=6.0.1 …   0B
<missing>      2 months ago   /bin/sh -c ln -s /usr/share/dotnet/dotnet /u…   24B
<missing>      2 months ago   /bin/sh -c #(nop) COPY dir:6c537cc098876a5f6…   70.6MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV DOTNET_VERSION=6.0.1     0B
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNETCORE_URLS=http:…   0B
<missing>      2 months ago   /bin/sh -c apt-get update     && apt-get ins…   37MB
<missing>      2 months ago   /bin/sh -c #(nop)  CMD ["bash"]                 0B
<missing>      2 months ago   /bin/sh -c #(nop) ADD file:09675d11695f65c55…   80.4MB

Let´s try to reduce the bigger part, the base image.

3. Multi stage build with Alpine linux Microsoft official image

We can change our base image to use the Alpine Linux instead of the default one Debian bullsyeye which is the base image of the most of the official Microsoft .NET docker images.

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
WORKDIR /app

COPY . ./
RUN dotnet publish "WebApi.csproj" -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine

WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "WebApi.dll"]

docker build -t api-multi-alpine .
docker images api-multi-alpine
REPOSITORY         TAG       IMAGE ID       CREATED       SIZE
api-multi-alpine   latest    0c7f1c3b0bfa   1 weeks ago   104MB

$ docker history api-multi-alpine
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
0c7f1c3b0bfa   1 weeks ago    ENTRYPOINT ["dotnet" "WebApi.dll"]              0B        buildkit.dockerfile.v0
<missing>      1 weeks ago    COPY /app/publish . # buildkit                  4.12MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      2 months ago   /bin/sh -c wget -O aspnetcore.tar.gz https:/…   20.3MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV ASPNET_VERSION=6.0.1 …   0B
<missing>      2 months ago   /bin/sh -c wget -O dotnet.tar.gz https://dot…   69.8MB
<missing>      2 months ago   /bin/sh -c #(nop)  ENV DOTNET_VERSION=6.0.1     0B
<missing>      3 months ago   /bin/sh -c #(nop)  ENV ASPNETCORE_URLS=http:…   0B
<missing>      3 months ago   /bin/sh -c apk add --no-cache         ca-cer…   4.35MB
<missing>      3 months ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      3 months ago   /bin/sh -c #(nop) ADD file:762c899ec0505d1a3…   5.61MB

Using the alpine instead of the debian base image we were able to reduce our base image size to 10% of our final image.
Now the .NET runtime is the part that is using most of the space of our image so let’s try to reduce this part.

4. Raw alpine with a trim-self-contained and trimmed .NET build

Instead of using the official Microsoft Alpine image which comes with the full .NET runtime we can use the vanilla Alpine base image and build our App using the .NET self-contained build PublishSingleFile option.
Publishing our app as self-contained produces an application that includes the .NET runtime and libraries in a single binary, so we don’t have to use the .NET runtime installed on our base system.

We can also use the PublishTrimmed option while building and publishing our app. With this options the final binary includes only a subset of the .NET framework assemblies, the assemblies that are referenced by our app. The other ones are removed from the final procuded binary file. However, there is a risk that the build-time analysis of the application can cause failures at run time, due to not being able to reliably analyze various problematic code patterns (largely centered on reflection use). To mitigate these problems, warnings are produced whenever the trimmer cannot fully analyze a code pattern. For information on what the trim warnings mean and how to resolve them, see Introduction to trim warnings.

Also, with a self-contained build we also need to specify the target platform which the final binary will be compiled. In this case we are using the alpine-x64 because our base image is the Alpine Linux.

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
WORKDIR /app

COPY . ./

RUN dotnet publish "WebApi.csproj" -c Release -o /app/publish \
    --runtime alpine-x64 \
    --self-contained true \
    /p:PublishTrimmed=true \
    /p:TrimMode=Link \
    /p:PublishSingleFile=true

FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine

WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["./WebApi"]

docker build -t api-multi-alpine-raw .
docker images api-multi-alpine-raw

$ docker history api-multi-alpine-raw
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
ac78719fc09a   1 weeks ago    ENTRYPOINT ["./WebApi"]                         0B        buildkit.dockerfile.v0
<missing>      1 weeks ago    COPY /app/publish . # buildkit                  42.2MB    buildkit.dockerfile.v0
<missing>      1 weeks ago    WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      1 weeks ago    RUN /bin/sh -c apk add --no-cache libstdc++ …   35.5MB    buildkit.dockerfile.v0
<missing>      3 months ago   /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      3 months ago   /bin/sh -c #(nop) ADD file:8f5bc5ce64ef781ad…   5.59MB

The final image was reduced to 83mb because it only includes the Alpine base image and a single binary that includes our WebApp compiled code and the assemblies that are referenced by our app!

References

https://docs.docker.com/develop/develop-images/multistage-build/
https://docs.microsoft.com/en-us/dotnet/core/deploying/
https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming/trim-self-contained

https://hub.docker.com/_/microsoft-dotnet

The post Smaller .NET 6 docker images appeared first on Blog IT.

Every value seems correct, but the error is definitely pointing us here. Here’s a simplified version of the offending line:

Console.Writeline(AConfig.ASubConfig);

And the corresponding appsettings:

{
    "AConfig" : {
        "ASubConfig" : []
    }
}

“But an empty array is not the same as a null value! And even if it was, it’s a value inside the “ASubConfig” property! There’s no way for this to be null!” was what I thought. And I thought wrong.

How the file is actually parsed

Actually, there’s a way for it to be null. Or at least, the JSON Provider which is gonna look at ours JSONs thinks so. Since .NET’s config system is ready to take in different providers, it was built with the common points of said providers in mind… And hierarchies aren’t one of those points.

What happens is that the JSON Provider’s parser is going to look at our JSON file and it’s going to map all those informations to a dictionary, in which every value is mapped with a key which corresponds to the path to that value in the file.

The “gotcha” here is in the way the arrays are processed: Each index of each array is processed as a part of the path. Meaning, that the following appsettings:

{
    "AnArray" : ["AThing", "AnotherThing", "AThirdThing"]
}

Will originate a dictionary with the following entries:

• AnArray:0 = “AThing”
• AnArray:1 = “AnotherThing”
• AnArray:2 = “AThirdThing”

Why do empty arrays cause an issue?

What happens if the array is empty? Well, by convention, an empty array wont originate any entries in our dictionary… So, to the .NET binder which is gonna look at our dictionary, that array doesn’t exist at all.

Even moreso, as there is no value inside that array which we can map to some path, every object on top of it in the hierarchy won’t have any value we can map either, meaning those objects won’t exist themselves (assuming they don’t have any other properties with not null values).

In practice, our dictionary will be empty, our .NET binder won’t be able to map anything, and the number of “WTH”s per second will spike before lunch time.

TLDR: .NET’s config system treats any object in appsettings.json that does not have any value associated with it’s properties as if it didn’t exist, and the same happens if that value is an empty array.

If anyone wants to read more on this, here’s a link for the github issue where I found most of this information:

https://github.com/dotnet/extensions/issues/1341

Happy coding everyone!

The post TWIL: The weird way .NET’s config system parses JSONs appeared first on Blog IT.

Let’s say we have the following table Documents:

CREATE TABLE [dbo].[Documents](
    [Id] [integer] PRIMARY KEY,
    [UserId] [integer] NOT NULL,
    [Title] [nvarchar](50) NOT NULL,
    [Body] [nvarchar](250) NOT NULL,
    [CreatedOn] [datetime] NOT NULL
)

and that we want to get the two most recent documents for each user. For instance, if we have the following records:

the query should return

To do this query using EF Core and LINQ we can try to group the Documents by UserId and then sort each group by the CreatedOn column to pick the first two documents for each user.

We can start by trying to group all documents for each user

 var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)

and then for each group we try to sort its elements by the CreatedOn column

    var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)
        .SelectMany(userDocs => userDocs.OrderByDescending(doc => doc.CreatedOn).Take(2))
        .ToArrayAsync();

If we try to execute this query using a previous version of EF Core 6 we get the following error:

    .OrderByDescending(doc => doc.CreatedOn)' could not be translated. Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly by inserting a call to 'AsEnumerable', 'AsAsyncEnumerable', 'ToList', or 'ToListAsync'. See https://go.microsoft.com/fwlink/?linkid=2101038 for more information.'

This is because the previous versions of EF don’t know how to translate the GroupBy inner expressions to sql. After following their suggestion I ended up with this query

    var usersDocs = await ctx
        .Documents
        .Select(doc => doc.UserId)
        .Distinct()
        .SelectMany(userId => 
            ctx
            .Documents
            .Where(doc => doc.UserId == userId)
            .OrderByDescending(doc => doc.CreatedOn)
            .Take(2)
        )
        .ToArrayAsync();

However this query has two main issues. It does a distinct over the UserId column, loads all the user ids to application memory and then it does a query for each user resulting in a n+1 query problem.

One way to solve these issues is to forget LINQ and rewrite the query using raw sql with a partition by UserId and the ROW_NUMBER() window funtion, doing a CTE .

Now, with the EF Core 6 we can use the first version of the query, since the EF Core team has added the support for translating some GroupBy inner expressions and it can translate this LINQ query to a single sql query.

    var usersDocs = await ctx
        .Documents
        .GroupBy(doc => doc.UserId)
        .SelectMany(userDocs => userDocs.OrderByDescending(doc => doc.CreatedOn).Take(2))
        .ToArrayAsync();

You can read more about these features and other improvements added to GroupBy queries here and check the related github issues 12088 13805 

Happy coding!

The post .NET EF Core 6 support for groupby top(n) queries appeared first on Blog IT.

For each possible implementation, we will do an overview of the flow that the exception does to understand the context of each implementation.

First, let’s do an overview of what is, normally, a basic flow in any Project.

The basic flow of an API Project

The previous Figure shows the basic flow of events inside the IDM project. The API receives an HTTP Request in a certain endpoint. The endpoints of the API are mapped in the controller layer, so when the API receives the HTTP request the controller is the first to interact with that request and sends that request to the respective service that will orchestrate all the necessities of that request. Those necessities could be, for example, retrieve some information from the Database, and that is done in the repository layer. The repository layer is where we map all the interactions with external services(DataBases, API, etc). This is a basic overview of what could be a basic API project.

The Exception Handling Problem

Taking into account the previous overview of the project, we want to make the process of handling exceptions the more clearest and efficient possible in terms of computational needs, but also in terms of code structure. To achieve this purpose we will describe three different ways of handling the exceptions.

Also, in this project, we have 2 different types of exceptions. They are:

• DomainException – This is the type of exception that is thrown when the error that happens is something that the API already expects;
• Exception – This could actually be any type of exception different from DomainException. This occurs when an unexpected error occurs in the API;

Reference to Middleware

In this case, we will use the ExceptionHandler middleware layer. The middleware layer is specific to .NET Core and we will not focus on that here. Take into account that we will use ExceptionHandler in the middleware pipeline to catch all the exceptions that are not treated.

Here is the reference to ASP.NET Core Middleware.

First Approach: Try-Catch on Controller Layer

This approach consists of catching and treating the DomainExceptions that are thrown by any of the layers (Controller, Service, or Repository) of the APIProject in the Controller layers. Take into account that all the unexpected exceptions are always treated in the ExceptionHandler of the Middleware.

Second Approach: Try-Catch in all Layers

This approach consists of all layers of the API Project being capable of catching exceptions and sending again the exception to the upper layers. The Controller layer is where the Domain Exceptions will be treated.

Take into account that in this case, the unexpected exceptions are caught by the layer that throws her and also by the rest of the upper layers. However, it is treated in the ExceptionHandler of the Middleware.

Third Approach: Encapsulate Exception in Response Object

This approach consists, as the name says, in encapsulating the exception in the Response Object. Instead of throwing the exception, we will send the Response object with a Failed message with an instance of the exception in the Response Object as a variable. This means that the system will not need to operate the throws of exceptions for the expected errors. They will be passed in the response object.

Take into account that only the unexpected exceptions are thrown to Middleware – ExceptionHandler to be treated.

Normal Response Object

public class OperationResult
{
        public OperationResult();

        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
}

New Response Object for this approach

public class OperationResult
{
        public OperationResult();
           
        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
        public Exception ExceptionHolder { get; set;} 
}

Fourth Approach: Catch all exceptions in Middleware – Exception Handler

The approach consists of throwing the exceptions whenever they happen and then let them be caught and treated by the middleware – ExceptionHandler. In this approach, we would create a different type of response for each type of exception for the ExceptionHandler send as Response.

This would centralize all the exception handling in one place.

Comparison of Exception Handling approaches

The post How to Handle known Exceptions? appeared first on Blog IT.

Both use https and I want the main site, which uses the primary domain, to only be accessible through it’s www version. For the second site, since it’s a sub-domain, I only want it to only be available in https.

Let’s say the domain is mydomain.com and the subdomain is mysub.mydomain.com. The only URLs I want to be available are:

• https://www.mydomain.com
• https://mysub.mydomain.com

Typically I would make the non-www to www redirection through the DNS provider, but for this website it was not possible.

The following is the configuration I used in my Web.config:

<rewrite>
    <rules>
        <rule name="Redirect from non www mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTP_HOST}" pattern="^mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://www.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
        <rule name="Redirect from non https mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTPS}" pattern="^OFF$" />
                <add input="{HTTP_HOST}" pattern="^www.mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://www.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
        <rule name="Redirect from non https mysub.mydomain.com" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTPS}" pattern="^OFF$" />
                <add input="{HTTP_HOST}" pattern="^mysub.mydomain.com$" />
            </conditions>
            <action type="Redirect" url="https://mysub.mydomain.com/{R:0}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Hope this helps!

The post Redirecting 2 domains from http to https and non-www to www appeared first on Blog IT.

The solution was to copy Raven.Studio.zip to the root directory of the web api.

The post Raven.Studio.zip Index.html not available appeared first on Blog IT.

a) You need to create a new ASP.NET Core Web Application with Visual Studio 2017
b) Choose .NET Core; ASP.NET Core 2.1; API
c) Right click the new project -> Manage NuGet packages
d) You have to add a new package source. Settings. New package source.

Name: MyGet
Source: https://www.myget.org/F/ravendb/api/v3/index.json

e) Choose the new source. Add:

RavenDB.Embedded – 4.1.1-nightly-20180904-0430
RavenDB.Client – 4.1.1-nightly-20180904-0430

f) Create a DocumentStoreHolder class

internal class DocumentStoreHolder
{
    private static Lazy<IDocumentStore> store = new Lazy<IDocumentStore>(CreateStore);

    public static IDocumentStore Store => store.Value;

    private static IDocumentStore CreateStore()
    {
        var serverOptions = new ServerOptions()
        {
            ServerUrl = "http://127.0.0.1:60956/",
        };
        EmbeddedServer.Instance.StartServer(serverOptions);

        return EmbeddedServer.Instance.GetDocumentStore("MyRavenDBStore");
    }
}

g) And that’s it 🙂

The post RavenDB embedded with ASP NET Core web API appeared first on Blog IT.

• This enables you to have an Angular application alongside your Umbraco website, on a specified route.
• The Angular App can be protected by the Authentication of your website, if you have it. And you can make use of surface controllers for authenticated requests.
• The routing of your app will work as intended, for example, if your Angular app is at /app and you make a request to /app/products, the request will be routed to the angular app products’ page.

What this is not

• A complete front end for a Umbraco website with dynamic routes.
• This doesn’t have dynamic routes, you have to specify them on your code.

Let’s get started!

First, start by creating a controller to handle the Angular App request.

using System.Web.Mvc;

public class AngularAppController : BaseController
{
    public ActionResult AngularAppView()
    {
        return View();
    }
}

Then, you have to decide the route where your Angular app will render. On this example it will be /angularapp.

On your ApplicationStarted method, put this code:

RouteTable.Routes.MapRoute(
  "AngularApp",
  "angularapp/{*.}",
  new { controller = "AngularApp", action = "AngularAppView" });

The {*.} syntax is what makes your angular app routes load and not return the 404 page.

If you don’t have an ApplicationStarted method, find out how you to create it here: https://our.umbraco.org/documentation/reference/events/application-startup

Under your Views folder, create a folder with the same name as the controller you set in MapRoute. In this case it will be “AngularApp”.
Inside it, create a view with the same name as the action set you set in MapRoute.

Inside the view put the contents of the index.html of your angular app.
Then you will need to move your angular app files somewhere like you /Assets folder, and edit their paths on the view.

Almost done!

Now you need to edit the routes of your Angular app.
Simply add the route you chose as a prefix to the routes.

From something like this:

const routes: Routes = [
  { path: '', redirectTo: '/dashboard', pathMatch: 'full' },
  { path: '/dashboard', component: DashboardComponent },
  { path: '/detail/:id', component: HeroDetailComponent },
  { path: '/heroes', component: HeroesComponent }
];

To this:

const routes: Routes = [
  { path: 'angularapp', redirectTo: 'angularapp/dashboard', pathMatch: 'full' },
  { path: 'angularapp/dashboard', component: DashboardComponent },
  { path: 'angularapp/detail/:id', component: HeroDetailComponent },
  { path: 'angularapp/heroes', component: HeroesComponent }
];

Thanks for reading!
Mário

The post Adding an Angular app to your Umbraco Website appeared first on Blog IT.