Friday, September 22, 2017

VSWhere.exe–The Visual Studio Locator

As someone who has built a lot if CI and CD pipelines, one of the struggles I always got when new Visual Studio versions were released was how to make my build server use the correct version of MSBuild when multiple Visual Studio versions were installed.

It got a lot better over the years, but even recently I was sitting together with a customer to investigate how we could make the build server understand that the Visual Studio 2017 Build tools should be used.

One of the (badly documented) tricks you could use was scanning the registry for specific registry keys. Luckily Microsoft released recently a new tool that makes finding your Visual Studio instances a lot easier: vswhere.exe

From the documentation:

vswhere is designed to be a redistributable, single-file executable that can be used in build or deployment scripts to find where Visual Studio - or other products in the Visual Studio family - is located. For example, if you know the relative path to MSBuild, you can find the root of the Visual Studio install and combine the paths to find what you need.

You can emit different formats for information based on what your scripts can consume, including plain text, JSON, and XML. Pull requests may be accepted for other common formats as well.

vswhere is included with the installer as of Visual Studio 2017 version 15.2 and later, and can be found at the following location: %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe. The binary may be copied from that location as needed, installed using Chocolatey, or the latest version may be downloaded from the releases page. More information about how to get vswhere is on the wiki.

This tool is also used internally in the VSBuild build task in TFS to discover recent Visual Studio versions(2017 and newer).

A quick sample:

  • Open a command prompt
  • Browse to %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\ or the location where you downloaded vswhere.exe.
  • Let’s try vswhere –latest


Thursday, September 21, 2017

.NET Standard: Using the InternalsVisibleToAttribute

In .NET Standard projects, there is an AssemblyInfo class built-in, so you no longer need a separate AssemblyInfo.cs file in your project Properties.

But what if you want to use the InternalsVisibleToAttribute? This was one of the attributes I used a lot to expose the internals of my Assembly to my test projects.

Turns out that it doesn’t matter really where you put this attribute. It is applied at the assembly level, so you can include in any source code file you like. Using the AssemblyInfo file was just a convenience.

So what I did, was creating an empty .cs file and add the following code:

Wednesday, September 20, 2017

.NET Standard: Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute

In a ‘classic’ .NET project, you have an AssemblyInfo.cs file.


This file contains all kind of information about your assembly

After upgrading a classic .NET project to .NET Standard, I started to get errors about some of the properties inside the AssemblyInfo.cs file:


A .NET Standard project already has the AssemblyInfo information built-in. So after upgrading you end up with 2 AssemblyInfo specifications, leading to the errors above.

The solution is to remove the original AssemblyInfo.cs file in the Properties folder.

Remark: If you want to change the assembly information, you now have to use the Package tab inside your Project Properties.


Tuesday, September 19, 2017

RabbitMQ–Configure access to Management portal

As mentioned in a previous post, it is probably a good idea to enable the RabbitMQ Management plugin to help you track what’s going inside your service broker.

Now if you try to access the Management plugin using the default guest account(which you should probably remove), outside the server itself, you get a ‘Login failed’ error.


Let’s fix this:

  • Logon to the server
  • Browse to the management portal using the localhost address: http://localhost:15762
  • Logon using the guest account


  • Click on the Admin tab and scroll to the Add a user section
    • Enter a Username and Password
    • Specify one or more Tags as a comma separated list. If you want to give full access, enter ‘administrator’.
    • Click on the Add user button


  • Now click on the newly created user in the user list


  • The set permission section is shown


  • Leave the default settings and click Set permission.
  • That’s it!

Remark: You can do the same steps using the command line tooling. For example, if you want to set the user tags, you can use

$ rabbitmqctl set_user_tags yourName administrator

Monday, September 18, 2017

RabbitMQ–Enable Management plugin

To simplify management and monitoring of your RabbitMQ Service Broker it is a good idea to install the management plugin(don’t expect anything fancy).

  • To install it, logon to the server where you installed RabbitMQ
  • Open a RabbitMQ command prompt


  • Enter the following command
    • rabbitmq-plugins enable rabbitmq_management
  • You’ll get the following log output

D:\Program Files\RabbitMQ Server\rabbitmq_server-3.6.12\sbin>rabbitmq-plugins en

able rabbitmq_management

The following plugins have been enabled:







Applying plugin configuration to rabbit@SERVER01... started 6 plugins.


  • If you want to access the portal from outside the server, you have to configure a firewall rule that allows TCP traffic on port 15672.


  • Remark: Notice that when you try to access the management portal from outside the server using the default guest account, it will not work. This is a security feature that is enabled by default. To solve that, we’ll create another account, but that’s something we cover in another blog post.

Friday, September 15, 2017

ASP.NET Core–Configuring a WCF service

In an ASP.NET Core application(using the full .NET framework) we had to consume a WCF service.

Should be easy right? Unfortunately it turned out that be more work than I expected. In a first post I explained the steps how to generate a Client Proxy, this post is about  setting the configuration.

WCF configuration can be a daunting beast with a lot of options and things that can go wrong. The code generated by the proxy hardcodes (some part) of the configuration in the WCF proxy and provides you a partial method to override it but that’s not the approach we want to take.

I know we’ll host the WCF service in IIS, so adding a web.config and putting the configuration logic over there sounds nice…

Let’s try that:

  • Open the generated proxy reference file  and remove the call to Service1Client.GetDefaultBinding() and Service1Client.GetDefaultEndpointAddress() in the constructor. (Note: this is only for testing purposes)


  • Right click on your ASP.NET Core project and add a web.config file.
  • Right click on the web.config and choose Edit WCF configuration.


  • Go to the Client section and choose Create a New Client…


  • Follow the steps through the Wizard. After completing it you should have something like this inside your web.config:
  • Let’s now try to create a client proxy instance and execute a call:
  • Unfortunately, this didn’t work and we end with an exception when we try to run our application:


  • If that doesn’t work, where should we put this configuration? (And yes, I know I can do everything through code but that is not what I want here).
    • An ASP.NET Core project is an executable behind the scenes. The only thing that IIS does is forward the request to Kestrel that invokes the DotNet process.
    • This executable has its own configuration file that is generated for you out of the box behind the scenes.


  • If you want to change this config, you have to add an app.config instead of a web.config to your project. Let’s just rename the file, rebuild our project and try again…


  • This time it works!


Thursday, September 14, 2017

ASP.NET Core–Connecting to a WCF service

In an ASP.NET Core application(using the full .NET framework) we had to consume a WCF service.

Should be easy right? Unfortunately it turned out that be more work than I expected.

  • I right clicked on my project and searched for an Add service reference… option. No luck, instead I saw a Connected Services section. Maybe that will do it?


  • I right clicked on the Connected Services section and choose Add Connected Service.


  • This opened up the Connected Services window but no option was available to connect to an existing WCF service Sad smile


  • Maybe the Find more services… link at the button will help me? This brought me to the Visual Studio Marketplace. And yes… a search for ‘WCF’ showed up a Visual Studio Connected Services plugin that allows to add a WCF Web service reference to .NET Core projects. Exactly what I needed.


  • I clicked on Download, closed Visual Studio after which the installer appeared and I could install the extension.
  • After the installation has completed, we can open up Visual Studio again, try Add Connected Services again. This time we see a 3th option appear:
    • Microsoft WCF Web Service Reference Provider – Preview


  • Click on it and you’ll get the same options you had before when using Add service reference…