At the point the basics of my ASP.NET 4 contacts application have been moved to the ASP.NET 5. This is never going to be a production application, but I want it run it on a remote server just to prove it works. I decided to publish to Microsoft Azure which is Microsoft’s cloud offering. The process was a lot more challenging that I had expected, but as with all the rough spots I have hit with ASP.NET 5 I am sure the path will be made smooth for the final release.
Publishing to Azure from Visual Studio 2015 RC
To get started right click on the project to be published and select the Publish.
This will load the Publish Web dialog. On the Profile tab select the Microsoft Azure Web Apps option.
This will show the Select Existing Web App dialog. Click the New button to add a new Web App.
The new button show the Create Web App on Microsoft Azure. This dialog has a bit more to it. Web App name sets the url of the app as well as the app name with Azure. For region I just chose the closest data center. My application uses a database and I don’t have an existing database server in Azure so I chose Create new server for Database server selection. Database username and password are self explanatory. With all the options filled in click Create.
After the creation process, which creates all the infrastructure need for the app in Azure, is done Visual Studio returns to the Publish Web dialog. The following is the Connection tab. The fields are editable, but are auto filled from the creation process. In case changes are need use the provided Validate Connection button to verify Visual Studio is still able to communicate with Azure.
The Settings tab allows selection of Release or Debug configurations as well as the target DNXÂ version.
The last tab on the Publish Web dialog is Preview. It is not overly useful on a first publish since all the file for the project needed to be push, but on subsequent publishes it would be useful to verify nothing unexpected is being pushed.
Pushing the Publish button on the Publish Web dialog push the files to Azure and opens a browser with the newly published web app.
Issues
After a few seconds I was greeted with a HTTP 500 Internal Server Error instead of my web app. I spent a lot of time on the Azure Portal trying to find my issue. I created a new project and published it without issue which means it is a problem with my app and not the publish process. I spent a lot of time digging and Googling my issues, but thankfully ended up with answers.
App Configuration
My first issues were the result of not setting up the configuration options for my user secrets. As I posted last week this was the main worry I had with user secrets. You would think with my concerns that would be the first thing I checked but it actually took me awhile to get around to checking my user secrets. Just to be clear I am not against user secrets I think they are an awesome feature I am just not used to dealing with this side of configuration. The steps to make the proper configuration for user secrets follow.
From the Azure Portal click Browse everything to get a list of all resources.
From All resources click on the Web App that needs configuration. If you are paying close attention you will notice the name of my web app is different than the publication settings above. This is the result of one of my tries to get the site running before discovering the problem was configuration.
Selecting a web app cause the details page to load. On the details page select Settings.
From the settings details page click Application Settings which will load the Web app settings page.
In Web app settings scroll down to the App settings section. In my case I was missing the Authentication:Google:ClientId and Authentication:Google:ClientSecret settings used for OAuth with Google. Also make note of the Connection strings section as  this is the section where the connection string to the database needs to be entered.
With all the above changes I was finally able to get the site to load.
Database/Entity Framework
As soon as I click on the contact list section of my app I got another HTTP 500 Internal Server Error. This happens to be the first time the app hits the database. The issue this time is that the DefaultConnection string that needs set so the app can connect to the database.
First step to fix this issue is to go back to the All resources on the Azure Portal and select the database that goes with the web app, aspnetcontacts_db in this example.
This will load the SQL Database detail. Under Connection string is a link for Show database connection strings. Clicking this will load a page with a list of connection strings for this database. Copy the appropriate string and replace the dummy password with the real one. Take that connection string with the password enter and put it in your web app’s DefaultConnection. With the DefaultConnection set the 500 error went away.
The next time I ran I got a stack trace with a message that migrations needed to be run. In order to get migrations to run I made a few changes to my project.
The first change was in the ConfigureServices function of Startup.  I added the setup for the ContactsDbContext using the DefaultConnection string. In the ContactsDbContext I removed the OnConfiguring function which is where the connection string for the ContactsDbContext had been set before.
// Add EF services to the services container.
services.AddEntityFramework()
.AddSqlServer()
.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]))
.AddDbContext<ContactsDbContext>(options =>
options.UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]));
In order to actually run migrations for the ContactsDbContext I added a constructor with a call to Database.AsRelational().ApplyMigrations() which will ensure anytime the DbContext is constructed that the latest migrations will be applied. The following is the full ContactsDbContext class after the changes.
public class ContactsDbContext : DbContext
{
private static bool _created;
public DbSet<Contact> Contacts { get; set; }
public ContactsDbContext()
{
if (!_created)
{
Database.AsRelational().ApplyMigrations();
_created = true;
}
}
}
The last project change was to the ContactsController to allow ASP.NET to inject the ContactsDbContext instead of creating the context with in the controller.
private readonly ContactsDbContext _db;
public ContactsController(ContactsDbContext dbContext)
{
_db = dbContext;
}
The change made above to the ConfigureServices function in the Startup class is how ASP.NET knows what to inject into the ContactsController. Build in dependence injection is one of the new features of ASP.NET 5.
After all the above changes I published to Azure and tried to access the contact list again. This resulted in a different error and a stack trace. The issue this round turned out to be that the default SQL Server created by Azure does not support the way that Entity Framework 7 is auto incrementing the ID column on contacts table. Thankfully there is an updated version of SQL available and the default server just need to be upgraded.
Back on the detail page for the SQL database there is a Server version listed as V2. Click the V2.
This will load the Latest SQL database update page. Click Upgrade This Server.
Currently the SQL Server created by the Visual Studio 2015 RC is in the Web tier which does not support the latest version of SQL which resulted in the warning below.
Click on your database name to load the Recommended pricing tier page. Since this is a new database Azure does not have enough information to recommend a tier and defaults to S0. At the very bottom of the page there is a big blue S0 link. Click it to change pricing tiers.
The Choose your pricing tier page will load. The current setting for the server is Web which shows as a retired. I chose the Basic tier but anything that is not marked as retired should support the newer version of SQL Server. After clicking on the option you want click the Select button at the bottom of the page.
Now that the new pricing tier has been selected go back to the server details and click the V2 link under Server version. This round you will get a big warning. Under the warning enter the name of your server and click OK to perform the upgrade.
The upgrade process took less than 20 minutes for me. After the processes was complete the app worked as expected.
Next either browse the list for the type of VM you are looking to create or use the search. For this example use the search box and type “Visual Studio 2017” and press enter.
This will bring up a list of VMs that come with Visual Studio 2017 already installed. For this example, I will be using the VM with Visual Studio Enterprise 2017 RC on Windows 10 Enterprise N (x64).
When you select a VM on the screen above it will add a new blade with information about the VM. If the VM is what you are looking for then you can click the Create button.
Next, there will be a series of steps to collect information and settings needed to create the VM. The first is the basic setting where the VM will be named, given a username, password, resource group, and data center location. After finishing the settings click OK.
Next, is VM size selection. I am just using one of the recommend, but if you need more options click View All. Click the size you want to use and then click the Select button.
Next, is more settings. I just took the defaults and clicked OK.
The final screen is a validation and summary. If all looks good on this screen click the OK button to kick off the creation of the VM.
You will now be back on your dashboard page which will contain a new tile showing that your new VM is being deployed.
Connected to your VM
Click the Connect button in the top center of the page which will trigger the download of a VS2017Blog.rdp. Open the file that was downloaded which a Remote Desktop Connection. With the following warning. Click Connect.
