My Blog

When writing SQL queries to test them against your CosmosDB collections, you might encounter the following error message:

Identifier XXX could not be resolved.

Here, XXX is the name of a property inside your collection. For example, consider the following query:

Every application out there needs to read some configuration written from the programmers in order to perform critical tasks and function correctly. Examples of configuration can be the connection string to your SQL database or a boolean flag which decides if a feature will be available to your customers or not.

.NET Core gives us a way to store our configuration in a json file and access its properties programmatically.

This way of coding gives us the advantage of not having to redeploy our application, every time we update a value in our configuration (in our case the json file). We simply have to recycle the application pool that hosts our application and we are set.

While I was developing a .NET Core web application and wanted to automate the build process in VSTS, I got the following error, when I was triggering the build:

Error: Assets file ...\project.assets.json not found. Run a NuGet package restore to generate this file. Process 'msbuild.exe' exited with code 1.

The issue here is that needed .NET Core files are missing, when we start build our application. I solved this problem by defined an extra initial step in my build process.

Consider you have to implement the following requirement:

• We have a MVC .NET web application and a view with a HTML table and multiple columns. We want to mark some of these columns as searchable, so that we can search their values when we use the search field.

• We host our data in a relational database, we get the structure of the DB table as it is. We use Entity Framework and we need to “map” the DB columns to their equivalent UI columns, so that the search works correctly.

Here a simple mockup of our UI:

Unit testing existing code can sometimes be challenging, especially when dealing with classes that contain too much functionality. In such cases, the Single Responsibility principle was not in focus.Refactoring the code can be an issue, so you will have to unit-test the class as it is. Additionally, we do not want to “mock” the interface of a class, which would mock all its methods, but the class itself.