Bill Blogs in C# -- Visual Studio 2015

Bill Blogs in C# -- Visual Studio 2015

Created: 12/31/2015 8:09:58 PM

This is the first of two posts on my thoughts for the coming year. This is a mixture of personal and global ideas. It’s my perspective, based on my experiences. In this post, I look back at the important trends and events I saw and experienced. (Part II will look at the year to come.)

The Growth of Humanitarian Toolbox

I’m very happy with all that has happened with Humanitarian Toolbox in the past year. We’ve continued to work on two different applications: Crisis Checkin and AllReady. The .NET Developer Community has really come together to help us achieve important milestones.

Crisis Checkin is being enhanced to support Operation Dragon Fire which will provide better data sharing during crisis. Watch the Github repo for updates on new feature requests to support this effort.

While Crisis Checkin has been moving along at a reasonable pace, AllReady has been moving incredibly fast. I need to thank our friends and colleagues on the Microsoft Visual Studio team for the incredible contributions they’ve been making to your effort.

The Visual Studio team started development as a showcase for many of the new features that shipped with Visual Studio 2015. They recorded a series of videos that documented that initial effort. HTBox took over the code and open sourced it shortly thereafter. We continued to work with community members over the summer, at ThatConference, and remotely to add features. Fall came, and we worked with Microsoft after the MVP Summit to get the application ready for Beta. You can see some of the experience at that sprint here.

We successfully hit our beta milestones, and our next step has been a pilot with the Red Cross in Chicago. The pilot has been successful, and we’ve been generating new tasks and feature requests from the pilot.

The success we’ve had building software has also brought an increase in contributions. We’re by no means a large charity, but we’r past the bootstrap phase and well on our way to a successful startup venture.

We owe a lot to everyone that has contributed:

  • The .NET Developer Community members that have contributed to our projects.
  • The Microsoft Visual Studio Team that adopted and help launch development of AllReady.
  • The donors that have made us a financially viable organization.
  • But most of all, my fellow board members at HTBox. I’ve never worked with a stronger and more dedicated leadership team.

I’m confident that we’ll continue this momentum over the next year.

C# 6 / Visual Studio 2015

Earlier this year, we saw the release of Visual Studio 2015, and with it the 6.0 version of the C# language. This is the first release using the Roslyn Codebase. I’m super excited about the rejuvenation of the C# and .NET community as the team reached this important milestone.

We have the Roslyn APIs to create analyzers, code fixes, and refactorings.

We have numerous new language features to support modern development.

We have an IDE and compiler that share more code, and thereby use less memory and have better performance.


Open Source all the things

The code for the C# and VB.NET compilers are Open Source (Apache 2.0 license) and stored on Github. Want to learn more about how it works? Look in the source. Want to participate? Grab an up-for-grabs issue, submit your fix. Want to experiment? Grab the source and try it out.

It’s also very instructive to see just how many tests and gates there are for the source code in the compilers.

But it doesn’t stop there. In addition to the Rosly source, many other parts of the .NET framework are currently, or are planned to be, Open Source as well. The full list is quite long, view it here.

The model of Open Source development is becoming the norm. Apple even responded by making Swift Open Source, also with a permissive license.

I believe the Open Source model is one of the key reasons for the rejuvenation of the .NET ecosystem.

Which brings me to…

.NET Foundation

The .NET Foundation is an indepent organization to support Open Source development in the .NET ecosystem.

While it was announced in 2014, its growth really started in 2015. (I’m biased, as I’m on the .NET Foundation Advisory Board).

The foundation nw includes parts of the .NET Framework, with source originally from the Microsoft product teams. It now also includes projects that started in the community, and have been brought under the .NET Foundation umbrella.

And, this post was written with the newest .NET Foundation project: Open Live Writer.

In my next post, I’ll talk about the topics that I think will be key in 2016.

Created: 9/1/2015 11:35:22 AM

Yesterday, this blog post documented how a bug accidentally cost Carlo $6500 in a few hours because his AWS keys were compromised. Please read the whole post.

Synopsis: He was using the GitHub Extension for Visual Studio. He published a new repository that he *thought* would be private, but due to a bug, he created a public repository. That repository contained his Amazon Access Key. Scanners found it and created lots of resources.

First, some good news and a task for all of you:  This issue was reported on the GitHub project for that extension (  That page shows the quick response by the team involved for that extension, and a fix has already been implemented, and deployed to the Visual Studio Extension Gallery:


A task for all of you:  If you are using the GitHub for Visual Studio Extension, update it now. You’ll get a notification from Visual Studio that there is an update available. Install it. Now. (This extension does not auto-update, so you will need to perform this task.)

A bit of background on how this happened so fast

One fact I learned yesterday was that there are organizations that constantly monitor Github commits to see if any contain credentials to AWS or other cloud providers. That is the price of success. A tremendous amount of code is added or modified on every day. It’s an attractive target.

As soon as a public repository gets created, or updated, that information will be captured. Be careful.

What habits could have prevented this?

Clearly, hindsight is 20:20, I’m writing this to share a few tips that might help you. I’m also interested in hearing what techniques you use to manage these kinds of secrets. My experience is with the open source projects for Humanitarian Toolbox. Those projects are deployed on Azure, and are all Open Source projects on GitHub. That means we must manage to keep secrets out of the repository. Here are the recommendations we use:

No Credentials in *.config

The default web.config files that are in the open source repositories are set for a localDB on the developer’s drive. There are no keys for our deployed resources.


Instead, we use the Azure Portal to configure any and all secrets for our sites.  (click on the image for a larger view..) This does mean that we, as an organization, must protect our Azure portal settings. And, folks like me must make sure to obscure the secrets in images like this.

Deploy Directly from Source Control.

We deploy our applications directly from GitHub source control. The staging site deploys from the master branch, whenever we merge pull requests. If you are one of our contributors, you can see your changes live as soon as we merge the pull request.

For release builds, we use the Release branch in GitHub. One of the commit team must merge changes from master to the release branch for those to be live. We do that after our partners have had the chance to validate the changes on Master.

Consider Visual Studio Online

For my projects that are not planned to be open source, but will remain private, I use Visual Studio Onilne. ( It supports Git, and has some pull request support for teams. (I’d like a model where I could use Pull Requests even with my shared repositories, but I haven’t found that feature yet.)

VSO is designed around a team model, not an Open Source model. It’s less likely (well, almost impossible) that I accidentally make a public repository on VSO.

What next?

The key takeaway for me is that the era of Open Source requires all of us to learn some new skills and take care of new potential risks. These security breaches can and do happen to experienced people. Teamwork, care, and multiple levels of defense are needed.

Most importantly, professionals did their job: I’m truly impressed with the speed and professionalism of the response to this issue by team members from both Microsoft and GitHub.

Created: 8/4/2015 4:07:44 PM

Whenever I teach or present, people ask me why their copy of Visual studio doesn’t look like mine. The reason is the extensions I have installed. I’m really impressed with Visual Studio’s extension model, and how rich the ecosystem for Visual Studio extensions are.

It’s even gotten more rich with the release of Visual Studio 2015, and Roslyn based analyzers.


Here (in alphabetical order) are the extensions I use all the time:

The .NET Compiler Platform SDK:  This extension provides all the tools and templates that I need to create Roslyn based analyzers, diagnostics, and refactorings. As of RTM, this extension includes the Roslyn syntax visualizer, which was previously a separate install.

C# Essentials: This extension is a set of Roslyn based analyzers and code fixes that help you adopt the new features of C# 6. If you falling into old habits, and using old constructs, when you want to adopt the new language syntax, this analyzer will help you build those new habits.

Chutzpah Test Adapter: This extension runs Jasmine based unit tests for my JavaScript code in the Visual Studio Test explorer window. Adding this extension means that my JavaScript tests run with every code change, just like my C# based unit tests run on every build. It’s a great way to enforce TDD practices with your JavaScript client code.

Chutzpah Test Runner Context Menu Extension: Sometimes I want to run my Jasmine tests in the browser to use the browser based debugging tools. With this extension, I can right-click on a test, and Chutzpah will generate a test HTML file with JavaScript loaded to run the tests.

Code Cracker for C#: This is another Roslyn-based analzyer that finds and fixes many common coding errors. It’s also available as a NuGet package, if you’d rather install it on a project-by-project basis.

Github extension for Visual Studio: I use this extension in addition to the standalone GitHub for Windows application. It makes it easy to stay inside Visual Studio while working with GitHub Flow.

Telerik JustDecompile extension: This requires you to install JustDecompile, which is free. I use these extensions to understand what IL my C# compiles down to. It helps me when I’m writing articles, or looking through the C# spec.

Powershell tools for Visual Studio 2015: This extension helps when I’m writing or debugging Powershell scripts.

Productivity Power Tools 2015: This extension provides many useful UI features: Presentation mode (switches font sizes), Tab Well enhancements, Visualizer enhancements in Solution Explorer, and many, many more.

Web Essentials: If you do web development, you need this. Period. It makes so many of the web programming tasks much, much, easier.

If you compare my list to yours, note that the above is an incomplete list. I did not include any of the extensions that install as part of the Visual Studio install (like ASP.NET templates, TypeScript support).

That’s my list. What’s yours?

Created: 7/23/2015 8:53:43 PM

This past Monday, Microsoft released the production version of Visual Studio 2015. Let’s get right to the lead: Visual Studio Community edition is free (for independent and Open Source developers). You have no excuse not to get this.

I’m not going to repeat all the information about the release and the total set of new features. Soma did that on his blog quite well. Instead, I’m going to focus on my areas of interest, and some of the resources I’ve written that can help you learn about these new features.

New Language Features

There are a number of new features in C# 6. Members of the team have been updating this page on Github with information about the new features.

I’ve written a number of articles about C# 6 for InformIT. The first four are live:

I recorded a Microsoft Virtual Academy Jump Start on C# 6 with Anthony D. Green, one of the program managers on the Managed Languages team.

And finally, I’ve written quite a few blog entries on the new language features. You can see a list here.

Language Service APIs

This version is particularly exciting because of the new compiler services that are part of Roslyn. These are a rich set of APIs that enable you (yes, you!) to write code that analyzes C# code, up to and including providing fixes for mistakes or other poor practices.

I’ve written an article for InformIT about the analyzers. You can read it here. I also did a Jump Start for Microsoft Virtual Academy with Jennifer Marsman.  If you missed the live event, watch the Microsoft Virtual Academy home page for updates. The recording should go live soon.

You can also learn more by exploring some of the open source projects that contain analyzers and code fixes:

  • Code Cracker. This project contains a number of different analyzers for common coding mistakes in C#.
  • DotNetAnalyzers. This contains a set of projects for different analyzers. Some manage particular practices. Others enforce rules, similar to the Style Cop effort.
  • CSharp Essentials. This project is a collection of analyzers that make it easier to adopt C# 6. If you don’t want to build it yourself, you can install it as an extension in VS 2015.

Humanitarian Toolbox and the All Ready app.

Finally, I was thrilled at the contribution from members of the Visual Studio team to Humanitarian Toolbox. Several members from different parts of the Visual Studio team worked for three days to build the initial release of the allReady application. The application source is on Github, under the HTBox organization.

This application was requested by the Red Cross. It provides features to lessen the impact of disasters on familes and communities. You can learn more about the project here on the Humanitarian Toolbox website.

The Visual Studio 2015 launch event included a profile of the developers and the process for building the initial code for allReady. You can watch the entire event on Channel 9. If you are interested in just the allReady app, and how it was built with Visual Studio 2015, look for the “In the Code” segments. There may be more In the Code episodes coming as the application grows.

All of us at Humanitarian Toolbox are grateful for the contribution from the Visual Studio team.

As a developer, I’m also grateful for the great new tools.

Created: 7/16/2015 5:05:29 PM

I was asked to review a bit of code for a friend the other day, and the result may be illustrative for others. I’ve stripped out much of the code to simplify the question. Examine the following small program:


public class SomeContainer


    public IList<int> SomeNumbers => new List<int>();


class Program


    static void Main(string[] args)


        var container = new SomeContainer();

        var range = Enumerable.Range(0, 10);

        foreach (var item in range)







If you run this sample, you’ll find that container.SomeNumbers has 0 elements.


How is that possible? Why does the container not have 10 elements?


The problem is this line of code:


public IList<int> SomeNumbers => new List<int>();


The author had used an expression bodied member when he meant to use an initializer for auto-property.

An expression bodied member evaluates the expression whenever the public member is accessed. That means that every time the SomeNumbers property of the container gets accessed, a new List<int> is allocated, and assigned to the hidden backing field for the SomeNumbers property. It’s as though the author wrote this:


public IList<int> SomeNumbers { get { return new List<int>(); } }


When you see it using the familiar syntax, the problem is obvious.

This fix is also obvious. Use the syntax for an initializer:


public IList<int> SomeNumbers { get; } = new List<int>();

Notice the changes from the original code. SomeNumbers is now a read only auto property. It also has an initializer, This would be the equivalent of writing:


public IList<int> SomeNumbers { get { return storage; } }

private readonly List<int> storage = new List<int>();


That expresses the design perfectly.


This just illustrates that as we get new vocabulary in our languages, we need to fully understand the semantics of the new features. We need to make sure that we correctly express our designs using the new vocabulary.

It’s really easy to spot when you make a mistake like this: every time you look at this property in the debugger, you’ll see that it re-initializes the property. That’s the clue that you’ve made this mistake.



Created: 2/5/2015 3:01:05 PM

There’s some new naming conventions coming for MSSQL LocalDB when Visual Studio 2015 ships. I found these while working on the Humanitarian Toolbox Crisis Checkin project. As more developers start using machines with VS 2015, especially machines that didn’t have a previous version installed, you may run into the same problem.

The web.config for Crisis Checkin on a developer box contains this connection string (highlight added):


<add name="CrisisCheckin" connectionString="Data Source=(localdb)\v11.0;AttachDbFilename=|DataDirectory|\crisischeckin.mdf;Integrated Security=True; MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />


When I ran this on my new Surface Pro III, using VS 2015 Preview, the application would not load. The app could not create and load the database.  After some investigation, creating apps using the new templates, and comparing, I found that I needed to change the connection string as follows:

<add name="CrisisCheckin" connectionString="Data Source=(localdb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\crisischeckin.mdf;Integrated Security=True; MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />

I asked around, and with the help of a couple team members, I now understand and know what to do.

Starting with this VS2015, the team is moving away from version dependent connection strings. That means, once you adopt VS 2015, you have the option of using a version independent  connection string moving forward. That’s the first recommendation:

To fix this issue for now, and future versions of Visual Studio, replace the version dependent connection string (e.g. “v11.0”) with “MSSQLLocalDB”.

However, you may need to continue to work with team members that are still using VS 2013. If that’s the case, you can follow the second recommendation:

Install the Version 11 LocalDB, which is free. You can then use Visual Studio 2015 (preview), but your database engine will be MSSQL LocalDB version 11.0.

Personally, I’d gravitate toward using the version independent connection strings as soon as possible. We will do that on crisis checkin once VS 2015 is officially released.

I hope this saves you some research when you first encounter this change.

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.