Christos Monogios

“The view XXXX or its master was not found” error looks like that:

"The view 'XXXX' or its master was not found or no view engine supports the searched locations. 
The following locations were searched:
~/Areas/XXXX/Views/XXXX/XXXX.cshtml
~/Areas/XXXX/Views/XXXX/XXXX.vbhtml
~/Areas/XXXX/Views/Shared/XXXX.cshtml
~/Areas/XXXX/Views/Shared/XXXX.vbhtml
~/Views/XXXX/XXXX.cshtml
~/Views/XXXX/XXXX.vbhtml
~/Views/Shared/XXXX.cshtml
~/Views/Shared/XXXX.vbhtml"

and I recently had to deal with it, although I was 100% sure that my view was in the right place inside my MVC project.

Load Tests help us identify bottlenecks in our application and can answer with high precision how many users our infrastructure can support in a given time. In a previous article I gave you some tips for using the Load Tests from Visual Studio in a more efficient way.

Today I would like to show you how you can run the same load tests against different server environments, for example on your localhost machine and on the integration server, before deploying a change into the production.

Today while I was developing a .NET Core example for testing Dapper against my LocalDB tables, I had to define the connection string so that I can run queries in my code against the database. If I was to use Entity Framework, then the connection string would be scaffolded for me, but now I have to find it on my own.

Moq is probably the most known framework for mocking functionality which is then used in your unit-tests. In this article you can find some of my notes about Moq that I wanted to share with you.

Some time ago I wrote an article with an example of an Azure Function which I used in my applications. With the current article I want to present you another real-life example of using different Azure Services and combining them together in a Logic App.

A Logic App represents a workflow of steps that are defined to be done in a sequential or in a parallel manner.

Our scenario contains a company which owns an eshop. We are going to build a workflow for getting customer orders, pushing them into a queue for almost-real-time process (A queue is a good way to balance load of large number of requests in your servers), retrieving them back, storing them in a storage table and informing the user about her order with an email. The most important thing, we are going to develop all the steps inside the Azure Portal; the use of Visual Studio is optional.

After we finish with the creation of our Logic App, we are going to have the following workflow: