Getting DotNet Core on your computer – Part 1/3: Clean Environment

I’m almost impressed with how difficult of a time I’ve had with using DotNet Core on my windows machine.

I’m not a regular .NET developer, but I have built a number of different tools, functions, PoCs with C#.

While I’m at it, this is one of the main reasons I’ve struggled grokking .NET to help people. The versioning and naming convention issues. C# is an incredibly robust and articulate language, with an incredible diverse set of tools and services. Once your over the hurdles the potential to be productive at Common Enterprise Scale is supes appealing. But before that, I need to get the stuff working in a flexible manner on my computer because I work in many different environments.

Maybe I’m approaching it the wrong way, maybe I should create a VM and do all my work on that? Maybe I should reimage my computer everytime I start a new project? This seems rather silly though. The ability to build, debug, test, and release projects from your own computer seems like one of the compelling reasons to use C#. In some ways, it’s design aligns with the Operating System of windows. Most specifically .dll files. Learning .NET has been a slow process some of the books I’ve read include: “The Yellow Book of C#” and “Functional Programming in C#”. One of the things I struggle with is the stuff in between. I want to move beyond class declaration but not quite all the way into Functional Programming.

So… here I am wanting to learn more and many projects I’ve been working on include a Web components, so ASP.NET Core stand out to me right away. The tough thing here is that to practice writing production code you should design your projects and solutions in a way that optimizes for testing and deployment pipelines. Following best practices from the get go with C# is a bit tricky. So I found this course about testing with ASP.NET Core MVC Unit Testability.

Now I’m stoked to go through this content, but before I do I’d like my dev environment to be similar or at lease working int he same way as Benjamin Day, the author of this course.

Okay, so to begin, I have a couple versions of .NET installed on my computer. But I’m going to uninstall everything to start. I’m also going to uninstall VS Code and all extensions because things were acting weird there as well.

First I uninstalled VS code from the Apps and Features page of the settings in Windows 10!
Then, I found this post for uninstalling VS Code extensions:
And this one from Scott Hanselman for uninstalling Dotnet Core:
Then I went into my Apps and Features and uninstalled them again…
I even checked my paths, both User and System variables.
I’m also deleting “.omnisharp”, “.nuget”, “.vscode” from my user folders.

And then restart your computer, because that may have been the solution all along \__0__/

So, should have a nice clean environment

Okay have you done all that???
That should take an hour to make sure everything is gone…

Now let’s install dotnet core…

But first a photo:

Picasso’s got me inspired

Missing The Blog – MeatSpace Part Two

I’ve been missing blogging heavily.

I’ve been rearranging my desk at home, and I think the reconnection with my home workspace made me nostalgic for taking time to blog.

So, as a personal way to kick things off, I want to revisit meatspace…

This photo comes courtesy of the corner of Irving and 22nd… Maybe… Right across from the Cricket store. Anyways, does this billboard have googly eyes???

Oh dear, our Norfolk Pine is dying and we don’t know what to do. It’s now sitting outside, in the cold, waiting for us to reuse the planter and it makes me sad.

Look at this big pups footsies! We took this Photo in Barcelona, I’m impressed with the amount of bakeries in Barcelona and how awesome-terrible a Nutella Croissant could be.

Holy friojoles, one last photo from Barcelona, this one is Sagrada Familia. If you go, I’d recommend waiting to the light is just right and waiting for the space to clear out a little at the end of your reservation for an incredible view of color and architecture. One of the few times I’ve been left awestruck.

Major Key – webpack init

Webpack Init

Why isn’t that the default instruction.
Its the most complicated thing and does all sorts of crazy stuff, I always end up breaking it, and it has an initialization command.

> webpack init

Then, you need to set the development mode or this will bug you… Forever.
They even ask you if you’re going to run this in production during the init script.
What the heck?


Hacking the Microsoft Hack

Thanks for listening to my spiel!

Photos from:

Microsoft Cloud Info
All the Stuff

4 Relevant Services
Cosmos DB
Web App in Demo
Virtual Machines
Web Apps
GitHub Deployment Bing Maps
Office Graph
Cloud APIs
Bing Knowledge, Images, NewsCognitive Services:
Bot Framework for everything!

Important Hack Principals
Come up with a good idea
Visit Devpost
Go Visit the Booths
Send in your resume
Don’t spin your wheels
Use GitHub Search
Use GitHub workflowsCreate something you want to use!

Ask us questions: @timmyreilly


Bot Demo and Azure Resources

Hope you enjoyed the demo!

Here are the resources I used to build the demo this evening:
Microsoft Bot Framework SDK
PayPal Demo Source Code
Microsoft Cognitive Services
Microsoft Language Understanding and Intelligence Service (LUIS)
Microsoft Azure Web Applications
Visual Studio Code

Here’s a couple more resources for you to consider as you make the leap into bots

Microsoft Case Studies
Real World Code
Bot Framework SDK
Bot Builder Examples
Bot Builder Node Samples
Bot Builder C# Samples
Location Dialog
FAQ Builder
Bot Directory – Check out Murphy Bot
And Hipmunk Bot for Skype

Azure Resources:
Data Center Geography
Azure Pricing Calculator
Support your Startup with BizSpark
Azure Homepage
Azure Video Series

Cognitive Services:
Main Page

If you have any specific questions feel free to reach out to me on twitter: @timmyreilly

Ocean Beach!
Ocean Beach!

Using Deployment Slot Settings in Azure Web Apps

This post elaborates on a specific learning from our work Athena Intelligence.

One great feature of Azure Web Apps is deployment slots. I recently had an excellent use case for them as a small startup I’m working with is trying out ASP.NET MVC. In the process, we learned how effectively deployment slots allowed their team to work on the project commit code, test it against a test DB as if in production, then quickly swap when ready to the new site and the production database.

Here’s a quick sketch to highlight what I’ll be demoing today:

Azure Subscription
GitHub Account + Git Installed

This tutorial provides a specific workflow for deploying and testing code using Visual Studio 2015, Azure SQL Server, and Web Apps for Azure. It is designed to help you quickly get resources into the clowd, supporting users, testing deployments, working with a small devops cycle and learn by doing.

There are 10 parts to this tutorial:
Creating a Azure SQL Server Instance in a Resource Group
Creating a Web App in Visual Studio
Push Your Project to GitHub and add Version Control
Create a Web App in Azure
Create a deployment slot
Connect the Staging Slot to your GitHub Repository
Update the Application Settings to connect to your Test Database
Check Data is Entering the Database
Move onto production setup
Make the swap

1. Creating a Azure SQL Server Instance in a Resource Group

Go to

Select new > SQL Database

Database name: TestDatabaseJanuary
Create new or use existing Resource group (creating a new one makes it easier to tear down when done)
Server: Create a new server – name = januarysqlserver, admin login = conductor, password = d0nt4get! location = same as everything else in Resource group
Select a price and select create.

Here’s what it looked like for me:

After the SQL DB instance is spun up and the database is provisioned, go to the overview page.
In the top right corner you can see the name of the server hosting this DB, and a show connection strings link:

After selecting that link, you’ll see a number of different connection strings. In this case, we’ll be using ADO.NET to connect to it from an ASP.NET web application.
Keep track of that string. You’ll also notice that the ‘username’ and ‘password’ are left empty. That’s the username and password you set when you created the SQL server instance.

Now that we have a Database ready to go, let’s get a web app connected to it.

2. Creating a Web App in Visual Studio

Open up any Edition of Visual Studio 2015 and select File > New Project.

Then select Templates > Visual C# > Web.
You’ll see ASP.NET as an option.
Give it a name e.g. MyDemoApp
Then Press okay.

You’ll then be met with an MVC Scaffolding page:

Select MVC and make sure the authentication is “Individual User Accounts”
For now I’ve unselected "Host in the Cloud" we’ll take care of this later.

Press Okay again and you’ll soon have a basic web application using ASP.NET MVC with User Authentication Cooked In.

Press F5 or select the green arrow on the toolbar of Visual Studio to see you application:
Right now when you register an account you’re updating a localdb called MSSQLLocalDB

BONUS: You can test your database from your local machine by editing your Web.Config Connection strings.
Change the “DefaultConnection” from local to the string connection string provided by the Azure SQL Server Instance:
This isn’t required for this tutorial but good to know if you want to see if its working meow.

3. Push Your Project to GitHub and add Version Control

In this case we’re going to use Git via the command prompt. Open up a command prompt to you DemoApplication Directory:
And enter the command C:\echo > .gitignore
This will create a .gitignore file. We want this file next too your .sln file.

Open the .gitignore file with your favorite text editor and copy the contents of this file into it:

Should look like this, make sure *.mdf and *.ldf are in your .gitignore:

Save the file and close the text editor.

Now go to and create a new repository:

Next, Initiate the repository, add your files, and commit your code.
These instructions on the github page are accurate:
And here they are again:

C:\ echo # MyDemoApp >>
C:\ git init
C:\ git add .
C:\ git remote add origin http://yourrespoastaoisdgaosuhd.git
C:\ git push -u origin master

And what it looked like on my machine:


You now have code in a GitHub repository that you can share with lots of different developers.
As they push changes we want to see how they look and if they break the application, so let’s go create a web app.

4. Create a Web App in Azure

Go to the Azure Portal and the resource group that has the SQL Database we created earlier
Select add in the top left corner > Then Search Web App:

Here you can see I’ve configured the name and placed it in the same resource group.

After that’s provisioned we can can make our first deployment slot!

5. Create a deployment slot

Go to the overview blade of your Web App and select “Deployment Slots”

Then Add Slot in the top left corner.
Now create a slot called “staging”
You can create as many slots as you want. They are essentially other Web Apps that are related to each other.

It will take a second to spin up, but once ready you can treat it like its own web app.

6. Connect the Staging Slot to your GitHub Repository

Select the staging slot and select “Deployment Options”:

You now get to pick a deployment source. In this case, we’re going to use GitHub. You’ll authorize Azure to pull your repositories and choose the ASP.NET Project you created a repository for in step 3:

7. Update the Application Settings to connect to your Test Database

Now that the project is deploying from the GitHub we need to connect it to a database to support the user login functions.
We have the code, now we need the data.
Go to the Application Settings and scroll down to connection strings.
Set the name to: DefaultConnection
And the Value to something like this:,1433;Initial Catalog=TestDatabaseJanuary;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

This is the connection string we took down in step 1.
Note: the {your_username} and {your_password} needs to be substituted with the SQL Server settings you set during step 1. It can be helpful to make the changes in a text editor before copying into that small textbox.

Also make sure you mark this as a slot setting. This tags this setting to only be used in this slot and is really the meat of this whole operation.

Here’s what that looked like for me:

Go back to the overview for the staging slot and select the url to visit your new site. Try registering some accounts and making sure everything works properly. If you get errors during registration that might be because the string was copied improperly or you used the wrong username and password. Try again, that’s what the cloud is for!

Here’s my site url and me registering an account:


8. Check Data is Entering the Database

Visual Studio 2015 has a SQL Object Explorer cooked in! It makes it super easy to check the state of your database and make sure you’re getting data.

Go to Visual Studio select View -> Server Explorer from the toolbar.
Now select connect to Azure Subscription if there isn’t one there already.
Login with the same credentials you do when you go to the portal in the browser.
Once connected drop down into SQL Databases and right click on the “TestDatabase” and select “Open in SQL Server Object Explorer”
Now open YouDatabaseName > Tables > Right Click AspNetUsers > Select “View Data”
Here’s a couple results from my data:

Isn’t that sweet!?

9. Move onto production setup

Now we have a working web app talking to a test database. Let’s create a production Database just like we did in step one and connect our web app to that.
I followed the same steps as Step 1, but now named the Database JanuaryDemoProductionDB:

And grabbed the connection string:
Eg:,1433;Initial Catalog=JanuaryDemoProductionDB;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

Now let’s go place this in our original Web App Connection string.
Don’t forget to mark it as a slot setting.

Okay, time for the big finale. This represents the future of our development workflow.
Let’s go make a small change in our local copy of the web app.

Here you can see I changed the text on the home page:

Now we commit the change and push to github:

The Staging slot picks up on this change and deploys the changes to our staging slot:

We check the staging slot site to make sure everything is still working
Looks good! And we can still login with our test accounts.

10. Make the Swap!

Now let’s put it into production!

Select Swap from the Overview Blade of our Main Web App (not staging):

Select the source and destination of the swap:

And wait a minute:

Now go visit your production site!

And try to login with one of your test accounts.
No Luck!
This slot is now on its own db.

Not very often you get to be excited about invalid login attempts!

10b. Finally

Now you can keep pushing changes to GitHub without worrying about messing up your production environment. After everything checks out, you can push it over to production and your customers.

Thank you deployment slots!

Let me know if you have any questions in the comments below or say hi on Twitter: @timmyreilly

Really looking forward to the next generation of Surface.
Really looking forward to the next generation of Surface.

Generating an SSH Key and Using it on Azure

SSH KEYS allow us to connect to VMs without using passwords but by passing a private key that can be managed by you or your organization.

For more about SSH

There are three parts to this tutorial:
A. Generate an SSH Key
B. Create a VM in Azure that uses the public key
C. Connect to VM using SSH keys

ssh-keygen ($ info ssh-keygen to learn more)
An Azure Subscription

A. Generate an SSH Key

Open bash and enter:
$ ssh-keygen -t rsa -b 2048 -C "Ubuntu@azure-server"
Keyname: server-key
Passphrase: somethingMemorable

Copy the contents of
$ cat

Should look like this:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMlUr7PCEdBmCVZHG5RqI8i7GgYAzd2G/FZ987XXa63vnqxZmZogVmmXrTnBHeM6oDv7v7g495CiiiINhJbGR4o7t4agiHOM43egDv7BbiViTlfVr3y5AxLUvRwHnC3egl8ABVX1anfXXR73x7IS3YRNWkh6gXtlhImw8UKG04UoZEmWB9BLt53lk/9c3Hxz22YZarzImrpQYy1XEUZ096B9mK/Fe+/McH78ZHUpXEgOZBIDP5KdqPk5XKznpwUDJ4/SPXPEWWCCjQ8gOoTFcFMaiMnXp5o5Udsi/DFO1TS/t8BeCRymkr5tdPvzexjkjkjkjkjkjkjkjkjkjkjkjt Ubuntu@azure-server

Here’s what it looks like for me:

Cool and you’ll also notice that there’s another file in that same directory – server-key
$ ls | grep server
Here’s what that looks like for me:

Now that we have our public and private keys let’s get our VM setup.

B. Create a VM in Azure that uses the public key

1. Go to the Azure Portal

2. Select New -> Search: Ubuntu Server
(I’m using 14.04 this time)

3. Make sure you’ve selected Resource Manger and click Create:

4. Now configure the basics per our ssh-keygen parameters
Name: azure-server
VM Disk Type: Up To You
User name: Ubuntu
Authentication type: SSH public key
SSH public key: Paste the results of $ cat
Subscription: Depends how you want to pay for the server
Resource Group: Up to you – I’m going to create a new one so I can quickly delete it.
Location: Up to you

Should look like this:

Then select OK to go to the next section.

5. Choose Virtual Machine Size
I’m going with the smallest VM for testing.
You can also view all different VM sizes to find the right one for your use case.

6. Configure optional Features
Setting the Storage account name to something you’ll remember easily is good.
And if you want to configure ports now you can select Network Security group to allow ports specific traffic.
Here’s what that looks like:
Click okay to continue to the Summary of your VM.

Here’s our summary:

Select okay to start your VM.

7. Wait for it to be ready.
Dashboard will have an icon and you’ll get a notification when its ready:

8. Once ready select on it to see the overview and the IP address.
Should look like this:

Great! We have a VM and its IP address. Lets use our Private SSH key to connect.

C. Connect to VM using SSH Keys

1. Open bash to file location you created the keys in.
Make sure they’re there:
$ ls | grep server

2. Enter this command to use SSH to connect:
$ ssh -i server-key Ubuntu@ -v
or more generally
$ ssh -i keyname username@ip.address -v
Make sure you’re using server-key and not
Tip: -v is the verbose option. Not necessary, but it helps to see if the key is being accepted

3. Great, now accept the certificate, and enter your memeroablePassphrase
Whole thing should look like this:

And you’ll be in the terminal of your VM:

You’ve got the key, you’ve got the VM, now put it to work!
Flask on Ubuntu
Node on Ubuntu
Mongo on Ubuntu
Connecting to VMs from Azure Web Apps

Let me know if you have any questions by posting in the comments below!

These people just want High Fives!
These people just want High Fives!

Connecting your Azure Web App to a Database using Application Settings

You just built an application that connects with a Database on your local machine, but now you want to share it with the world. But you don’t want to share everything about your application with the world.

Azure web apps supports a number of different web platforms, but to effectively build while maintaining code on GitHub we need to keep configuration details of our app private including the connection string for our database.

In this case we’re going to be using a Node JS application connected to a Mongo Database hosted on a Virtual Machine.

Before we get started…
Do you have a MongoDB up and running?
Nope. – Read this post!
Yep! – Great keep going!

For reference, I’m starting with a chat application originally written by fellow evangelist Rami Sayar for an excellent Node Course he taught recently.

Azure Subscription
Connection string for a DB in Mongo – mine looks like this:

The Steps:
1. Clone or fork the repository
2. Create an App Service
3. Connect App Service to Repository
4. Add app settings in Azure Portal
5. Try it out!

1. Clone or fork the repository

The project I’m using for this demonstration is found here: Github
Now clone the project to your local machine, or fork it in GitHub.

Take a quick look at these files:
– package.json : checkout out the dependencies of the project, notice how we’re using the official mongodb driver
– mongoClientTest.js and dbTest.js : provide other examples/test files to run, just substitute your ip address of where mongo is being hosted to make sure you’re able to connect.
– app.js : this is the main file that will be run by Azure Web Apps (app.js or server.js will automatically be started by the cloud when deployed). Also, in app.js you’ll see we set ‘db’ using process.env app.set('db', process.env.DB ); – we’ll be using that in step 4.

Once comfortable with the files locally or in GitHub we’re ready to spin up our App Service in Azure.

2. Create an App Service

App Service is a PaaS service offered by Azure to make deployment of website/web services simple and easy to maintain, develop against, and scale.

To begin select the ‘Plus’ button in the upper left corner and select web+mobile, then select Web App:

Now configure your web app:

You may have to create a app service plan and resource group if you haven’t created one yet, for more info on this portion of the architecture click here and here

You’ll see this icon on your dashboard while the resource is spinning up:

Once running the portal should automatically take you to that resource, if not you’ll see it on your dashboard:

Here’s the overview pane and the items we’ll be using in the rest of this tutorial highlighted:

3. Connect App Service to Repository

Now that we have an app service, let’s connect it to our repository.
There are a number of options for deployment.

In this case we’re going to deploy from GitHub, but we could have also used a local repository by adding Azure as a remote repo.

Azure will detect changes made to the repository on GitHub and redeploy the project. This makes deployments during hackathons super easy.

Select Deployment options from the overview pane -> Choose Source -> GitHub:

Note: You can also select Local Git Repository if you’ve liked to keep your code off of GitHub and add Azure as a remote repository git add remote azure "http://git.asdfgafdgasdfgasdf" – will be displayed in overview portal once initialized.

You’ll then be asked to login to GitHub so it can access the list of your repos.
Select your forked repo or the cloned repo you’ve committed to GitHub:

Once selected you’ll see a notification in the top right corner with a loading bar for the deployment:

Once that’s finished, you have code ready to roll in the cloud.
Azure has automatically installed the packages listed in your package.json and found the file named server.js to deploy. Next let’s configure it to talk to Mongo!

4. Add App Settings in Azure Portal

Now we have a project connected and deployed on Azure, but it won’t store the data anywhere, because a connection string hasn’t been included in the environment variables (aka application settings).

To add our monogodb to the project we just need to include the variable name and the connection string.
In our project, as noted before, we set db using process.env.DB

Select application settings and scroll down to until you see app settings then enter into the two empty fields “DB” and the connection string mentioned earlier: mongodb://
Like this:

Then hit save!

Go back to your website and try entering some chatter!

Try it out!

If you visited the page it should look something like this:

In the middle of the above screen shot you can see a terminal with a connection to the VM and same data in the MongoDB.

If you’re running into issues try connecting using dbTest.js or mongoClientTest.js after you add the specific IP for your VM hosting mongo.

Hope this made it super simple to connect your application to a database using Azure Web Apps.
Please let me know if you run into any issues in the comments below.

When Brett Stateham comes to town...
When Brett Stateham comes to town…

Running Mongo on Ubuntu Virtual Machine in Azure

You just setup a VM and you want to store data!

You checked out Document DB, but decided Mongo was more your style.

An Ubuntu Virtual Machine in Azure

Let’s get started!

There are four steps:
1. Open the appropriate port on Azure
2. Install Mongo
3. Configure Mongo to connect to all external IPs
4. Connect your application

1. Open the appropriate port on Azure

Go to your virtual machine’s landing page and select the resource group in the top left corner:

Resource groups are the way Azure breaks down how our VM interacts with the internet, other VMs, storage, and public/private networks.

To open the port we need to change our Network Security Group, which is represented by the shield and underlined in the screenshot above.

Then, once you’ve selected the Network Security Group, select Settings -> Inbound Security rules

This will allow us to open up our VM to the Public Internet via a port that we'll connect our client side application to.
This will allow us to open up our VM to the Public Internet via a port that we’ll connect our client side application to.

You’ll notice that SSH is already included, that’s what we’re using in our terminal. You may also have other ports opened if you’ve followed some of my other posts.

We’re going to create a new Inbound Security Rule called MongoPort where we’ll set the Destination port range to 27017 (the default port for MongoDB)

You can see the configuration pane in the screenshot above identified as item 3.

Once you hit ‘Okay’ or ‘Save’ the port will be opened in a couple seconds.

You should see a notification in the top right corner once completed. Now the port is available to the open internet, but Mongo isn’t installed or configured to be listening at that port. So let’s get to it.

2. Install Mongo

Installing Mongo on Ubuntu is easy and well documented by the MongoDB group. Just enter a few commands and you’ll be up and running in no time.

I followed the directions provided by –

Make sure you’re following along with the directions for your specific instance of Ubuntu.

To check your version of Ubuntu enter:
$ lsb_release -a

Once you’ve followed the directions provided by Mongo, here are some other helpful commands to make sure everything is configured properly.

See a log of what MongoDB is doing:
$ cat /var/log/mongodb/mongod.log

See all the processes running on your machine:
$ ps -aux

See all the processes with mongo in the listing:
$ ps -aux | grep mongo

See the status of the ports:
$ netstat -ntlp

Here’s what the bottom of my log file looks like as well as a double checking of the current status of Mongo and what port its running on.


Before we access this DB from our application we need to change one setting so Mongo accepts connections from different IP addresses besides the local IP address.

3. Configure Mongo to connect to all external IPs

Before we go on, I need to make it clear that this is not a best practice, and no user data should be stored on a VM with an open port like this. But for development and practice purposes we’re going to make it easy to connect.

If you’re going to go into production, please refer to MongoDBs security checklist HERE.

Okay, having said that.

Open up the mongod.conf file using nano:

$ sudo nano /etc/mongod.conf

And uncomment the binding IP by adding an octothorpe at the beginning of the line like so:


Save and close the file. ( Ctrl+X -> y -> enter )

Alright, now MongoDB should be ready to be connected to!

4. Try it out and Connect your application

Open the Mongo Command line by typing mongo in your ssh terminal.
And show your DBs and collections
show dbs
show collections

Here’s the getting started tutorial from Mongo that I found helpful:

And a great way to generate some test data to get familiar with your Databases and collections:
Here’s what it looked like for me!


The connection string for the VM is the IP address and the DB you’d like to write too. To connect to the test database on the is vm the connecion string to use looks something like this:


In the next blog I’ll show you how to connect your Azure Web App to Mongo on this VM!

Caught a Giants game this week!
Caught a Giants game this week!