When working with Docker in Visual Studio, the default behavior of the IDE is to place the Dockerfile at the project level. However, if your solution has multiple projects and you want to achieve easier integration of the Dockerfile into your Azure pipelines, then you might want to move the file to the solution level. Let us see how to achieve this task.

All .NET programmers had dealt at least once on their career with a null reference exception on a code line they wrote. Most of the times a parameter of a method is null, the code is not aware of it and the parameter is being used inside the method, for example we are accessing a property of an object. Because the value of the object is null we are getting an exception on the runtime.

Visual Studio provides a way to inform / warn us about possible null references. Let us see how we can enable this feature on our C# project.

When debugging your .NET application with Visual Studio, you will come along Framework- or Application-Exceptions. In specific cases you see the line where the Exception was thrown (line 132 in the following screenshot) but you cannot see the content (message, stacktrace, etc.) of the Exception. To find this information simple type the following in the watch list area of Visual Studio:

Recently while I was trying to test a demo application with .NET Core I came around the following error message when I was starting the application using F5:

A Visual Studio Item Template allows us to generate new files with code, so that we avoid having to manually create them. This automatization is very practical when we need to create similar classes more than one time. A template is being offered as option in the “Add new item” dialog of Visual Studio:

In order to download and use a remote repository, which is stored in Azure DevOps, do the following two steps and you are good to go.

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.

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:

Writing JavaScript code without any type analysis superset like TypeScript or Flow is still a thing and in my opinion absolutely valid and welcome decision. Without types there are some implications while coding in JavaScript. Visual Studio does a great job for providing Intellisense and F12 functionality for the files which reside in the same project. We can improve the quality of our code even more.

If you are writing vanilla JavaScript in a large web application, it is almost certain that you are dealing with multiple JavaScript files which are scattered in multiple Visual Studio projects, stored in different solutions. Visual Studio does not provide any IntelliSense features for referenced code which sits outside of the current project.

One solution to this problem is to manually search for the specific file and find out which arguments does your function need or which functions are contained in a JavaScript object. Since this can be a tedious action, Visual Studio gives us the option to activate IntelliSense in our JavaScript files by creating a file named _references.js. TypeScript users are already experiencing the benefits of code completion by using the d.ts definition files.

The use of _references.js is not a new feature. It exists for many years now, however, with this article I want to give you the current stand of the feature, as of 2018. I want to find out if the file still does what is supposed in Visual Studio 2015 and 2017.

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.

The last few days I have been experimenting with the different types of App Services that the Azure platform provides. One very interesting combination of app services is a ASP.NET MVC client (Azure Web app) or a WebAPI (Azure API app) which acts as the middleware between a JavaScript client and an internal “business” WebAPI (Azure API app). The architecture looks like this:

Non-relational databases are becoming more and more popular as a solution for storing your data. Cloud solutions like Microsoft Azure also get more popular with every day.

Currently Azure supports two types of “NoSQL” databases in the Azure portal. The one is DocumentDB (the NoSQL option in the main menu of the portal) and the other is the Table Storage (from the Storage accounts option in main menu). Do not confuse this Table with the tables of a relational database, they are not the same! A detailed analysis of the differences and similarities of the two technologies is beyond the purpose of this article, but we can summarize them to the following points:

With the Azure cloud solution from Microsoft we can create a new web application with Visual Studio, deploy it as a Azure Web App and “go live” in only few minutes.

I recently was faced with the “The subscription is not registered for the resource type ‘components’ in the location ‘Central US’” error when I was trying to publish my new web application to a Website (or a Web App) in Azure. Either starting from scratch with a web project and doing the mapping or by using the Publish option of an already created project, I was getting the same error. Visual Studio tried to publish the application to Windows Azure with no success.

If you want to store your source code in a repository that uses Git, you often have to create a .gitignore file which contains a black list of files that should not be committed to the repository. If now you are using Visual Studio for your projects the need for such a file is even bigger since this IDE creates a number of files (.exe, build, bin folders, etc.) that are only needed on your local machine.

With the release of Visual Studio for Mac we need to create a .gitignore file for our Visual Studio projects by using our Mac.

When dealing with large web applications you will definitely have to apply some load to the infrastructure before going or even during being online. A Load test is a predefined set of URL requests that are submitted to your application from multiple virtual users. The number of the users or the amount of time a Load tests runs, can be defined from you.

By testing your application with Load tests you can be sure about the maximum workload or number of requests that your infrastructure can support and handle simultaneously. Having this information you can decide if you have to buy (on premise case) or rent (cloud case) new hardware.

With this article I would like to give some tips and tricks for features of the Load tests in Microsoft Visual Studio.

The BadImageFormatException was unhandled – An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) exception is being thrown when you try to load a .dll of your application which was compiled with 32 bits (X86) or 64 bits (X64) and the process that runs this file runs in a different bit-environment than the file.

If you see this exception when you run your C# unit tests in Visual Studio, then the reason for this error is that the test environment of Visual Studio has a different bit setting than the compiled code which is under test. To fix that you have to do the following change in your Visual Studio test settings:

When you work with Team Foundation Server (TFS) and Visual Studio and you do web development, chances are that you will come across the EPERM error when npm tries to change a file in your application. The complete error message is Error: EPERM: operation not permitted, rename and then the absolute path to the problematic file follows.

When you install the Web Essentials plugin to your Visual Studio 2013 installation it is very probable that the next time you open a TypeScript project in Visual Studio the program will freeze and you cannot do any further action inside Visual Studio.

Often you want to include a file into one of your Visual Studio projects, but you do not want to check it in TFS. Such files can be for example .css files generated from sass or less files or JavaScript files created automatically after TypeScript files are compiled.

Visual Studio provides a way to perform this task. Unfortunately it is not as easy as it sounds…

The following list contains my favorite keyboard-shortcuts in Visual Studio:

• ctrl + K + C (Press Control, K and C): Comments out the selected lines of code.

• ctrl + K + U (Press Control, K and U): Uncomments the selected commented lines of code.