My articles about Visual Studio

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:

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.

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.

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 an 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:

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.

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.

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.