The third .NET Conf UY is taking place September 29th through October 1st in Montevideo, Uruguay.
Get the very latest on Microsoft technologies, including HoloLens, .NET Core, DevOps, Docker, Universal Apps, Windows 10, Internet of Things, Xamarin, Sharepoint, Office 365, SQL Server and Visual Studio. Hob-nob with top experts, and enjoy a unique opportunity to learn, share and network. Workshops, conferences and fun are all guaranteed, in an informal, friendly environment.
Sound good? You’ve always wanted to see Uruguay, haven’t you? What better time. Montevideo is a beautiful, modern city, and if you buy your ticket before August 31st, you’ll enjoy access to the entire conference for only $10!
HTTP Error 502.5 – Process Failure
Don’t worry. Nothing on our server or your site is broken. You just need to modify the web.config file a bit or create one in the appropriate directory because the AspNetCoreModule is the default handler for processing files.
I’ll show you how in this guide where I have an ASP.NET Core 1.0 application in the root and WordPress in a sub-directory. Since I don’t want to memorize web.config markup language, I’ll let IIS Manager do most of the work for me.
Log into your site using IIS Manager and highlight the folder WordPress was installed to, so that the web.config file in that directory will get modified or created if there isn’t one.
Double click on the Handler Mappings module.
On your right, select View ordered List…
Using the Move Up/Move Down Actions, move PHP##_via_FastCGI to the top where ## represents the PHP version number that you are using. This will create the necessary markup in the web.config file in the WordPress directory without affecting your other web.config files.
Now click on View Unordered List…
Highlight aspNetCore and click on Remove. Don’t worry, this doesn’t delete the AspNetCoreModule. It just removes the handler mapping (i.e. entry in the web.config file), and voila, your PHP application should be working again.
Now that we have launched ASP.NET Core 1.0 on DiscountASP.NET, here is a sample tutorial on how to successfully publish an application. First, make sure you have installed the pre-requisites on your computer to support an ASP.NET Core 1.0 application within Visual Studio. In this guide, I am using Visual Studio 2015 Community Edition.
Preparing a Sample Application
- Launch Visual Studio.
- Select File -> New -> Project (CTRL-SHIFT-N)
- Select ASP.NET Core Web Application (.NET Core), name your application and click on OK.
- For the ASP.NET Core Template, select Web Application and click on OK. Immediately, in the Solution Explorer window on the right hand side, a yellow pop-up window will open saying “Restoring Packages.” Wait until that finishes as the references for your application are being downloaded and added to your solution.
Publishing the Application via Web Deploy
- Log into your DiscountASP.NET Control Panel.
- Click on the Account Info/Edit link under the Account Management section in the menu to your left.
- Scroll all the way to the bottom and click on the Download Web Deploy Publish Settings.
- Download this PowerShell script from GitHub and place it in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\Publish\Scripts\1.1.0\publish-module.psm1 or wherever you installed Visual Studio to (e.g. if you changed the drive letter to E:)
- Now in Visual Studio, go to Build -> Publish appname. In the Publish window that opens, select Import.
- Find the publish profile you downloaded earlier from our Control Panel and click on OK.
- In the Connection section, you’ll notice the fields are already pre-populated for you. You’ll need to make a slight modification to the Server field by appending this query string:
Replacing domain-name.com with the domain name associated with your hosting account. The full line should look something like this:
- Click on the Validate Connection button to make sure you get a green check mark. If you don’t, you can open a support ticket to have one of our staff members recycle the Web Management Service for you. Sometimes the Web Deploy service on the server gets “stuck” and recycling usually fixes the problem. At this point, you can go ahead and click Publish if you want. Clicking on Next will allow you to further refine some configuration settings before deploying.
Tips/A Few Things to Note
- Publishing to a sub-directory does not work at this time. That should be fixed in an upcoming update.
- If you’re having trouble publishing, double check that your antivirus/firewall is not blocking port 8172.
- ASP.NET Core 1.0 is only supported on our newer Windows 2012 R2 servers. If your hosting account is not on this platform, please open a support ticket to have it migrated. The migration process takes about 30 minutes unless you have a large number of files.
- If you’re having trouble getting your ASP.NET Core 1.0 application to work and don’t know where to begin to debug, make sure you enable error logging in the web.config file. Change the stdoutLogEnabled to “true” and create the directories that will store the log (e.g. “.\logs\stdout”). It is not enabled by default.
If all goes smoothly, your site will look something like this:
It’s installed and available right now on all of the IIS8 servers. If you want to use Core but your site is on an IIS7 server, we can migrate you to IIS8. Just let us know.
The only known issue at the moment is deployment only works into your root directory. We’ve let Microsoft know that there’s an issue deploying to a subdirectory, and we expect that they’ll fix that in a future release.
We’ll be publishing some posts soon on developing with ASP.NET Core 1.0. Stay tuned.
With the launch of SQL Server 2016, one of the new features you might be interested in is Stretch Databases. It’s basically a data archiving feature which will move your data from your current SQL database to an Azure SQL database for storage, while still allowing the archived data to be queried.
It’s a great idea if you have a very large and growing database and need to keep a history of that data for use later. A perfect example would be a customer orders table. I won’t go in to detail on how to set it up as there is already a great guide on Microsoft for getting started, but I just wanted to highlight some of the pros and cons (in my opinion) of utilizing it:
- Great for very large and growing databases as it frees up space on your current SQL server database to record new data.
- Azure automatically backs up databases on its platform by taking snapshots every 8 hours and retains them for 7 days providing you with a range of restore points.
- Azure databases are geo-redundant and replicated several times to reduce the risk of data loss.
- Stretch databases utilize staging tables when moving data to Azure, providing an additional point of redundancy.
- Limitations on data that can be stretch-enabled.
- Costs incurred for storing data. (This could potentially be a pro if you are currently paying a high price for data storage.)
- Backups made on stretch enabled databases are shallow backups (i.e. they do not contain the migrated data), and in order to retrieve the data, your database will have to be large enough to accommodate the reverse transfer which also incurs a transfer cost.
In summary, it’s a great idea for a business sites which conduct a lot of business, but maybe not so great for your personal website or blog.
I’m pleased to announce that SQL 2016 hosting is now officially available as an add-on option. Some of the new enhancements include temporal tables, query store, stretch database, and native support for JSON.
SQL 2016 can be selected when ordering SQL service through Control Panel. All the backup, restore, attach MDF tools are available as well.
Back in August 2015, I wrote an article which showed how you could deploy an ASP.NET 5 application on our servers for those who wanted to try and test it out. I also mentioned in the same article that because ASP.NET 5 was still in beta, what I wrote may or may not work for future releases.
I can now say they are no longer applicable. They will still work for Beta6 but not for RC1 or RC2. This article covers some of the changes made since Beta6 and why we chose not to support RC1. ASP.NET 5 (vNext) has also been renamed to ASP.NET Core 1.0, and I’ll refer to it as such from now on.
We chose not to support RC1 for a couple of reasons. In order deploy an RC1 application successfully, some changes need to be made on the back end. RC1 requires the installation of an additional IIS module, the HTTPPlatformHandler. It’s a pretty interesting module which allows you to run non-native Windows languages such as Java, Node.exe, Ruby, etc. under IIS.
But that wasn’t the main reason we chose not to support RC1. RC1 just presented some technical challenges to overcome, mainly with how the file directory is setup and security (i.e. approot and wwwroot).
Since ASP.NET Core represents a paradigm shift in the way ASP.NET apps were being developed, integrating it with our current infrastructure while providing backwards compatibility for older versions of ASP.NET proved difficult.
There was also the problem with getting Web Deploy/FTP from Visual Studio working correctly which many of our current customers are familiar with and rely on to deploy their websites. Since this was just a Release Candidate, we adopted a wait and see approach to see what further changes would be made to the product.
Fast forwarding to May 2016, that proved to be a wise decision. RC2 helps address many of the issues we faced trying to integrate RC1 in our environment. It no longer requires the HttpPlatformHandler in order to run, but instead relies on a new module, ASPNetCoreModule, developed specifically for Core and can be enabled with the addition of one line in your web.config file.
If you also examine the file structure of an RC2 application, you’ll also notice some major changes. The approot folder is now gone, but the assemblies, runtimes, and configuration files are still stored outside of the wwwroot directory (either one file directory level above or adjacent to it).
What this means for us is that we no longer have to make changes to our file directory structure to accommodate/fix deployment and security issues such as the one mentioned in my previous article if you want to host the application in the root of your account. RC2 applications can now be deployed the same way as any other type of application (e.g. MVC, web forms, etc.)
We’ve also been working directly with Microsoft to get Web Deploy working, and I can now say it’s possible to use Web Deploy to deploy an RC2 application with a few minor modifications to Visual Studio and your solution’s publishing profile. Web deployment now looks and feels like what you’re used to.
We still have some testing to perform before we can roll this out to production, such as integrating the .NET Core Framework in order to support portable applications as opposed to self-contained applications, but you can rest assured that when we do, you’ll also have the technical expertise of a knowledgeable staff to help you get your ASP.NET Core application running on our servers.