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.
This is a premium spam filter solution that will not only keep your inbox virtually free of spam, scams, viruses and phishing, but also comes with a powerful management portal, where you can review your email logs and easily set up whitelists and blacklists. You also get daily quarantine reports.
This service will store a backup of all your clean incoming emails that go through the SpamExperts system. Your email archive is stored in compressed and encrypted format on redundant cloud servers in the cloud.
Increased security is always a good idea, especially for important pages like your WordPress admin login. So this article will show you how to protect the wp-admin directory in a WordPress site hosted on an IIS Server. We’re going to do that by blocking access to the directory to everyone but yourself.
On our IIS servers we allow you to use the IP Address and Domain Restrictions module. In this tutorial you’re going to need to connect to your site via IIS Manager. See our Knowledge Base article: How to connect to your site via IIS Manager. (If you prefer a direct web.config file solution, skip to the end of this article for the necessary code.)
- Once connected to your site via IIS Manager, navigate to your wp-admin directory by double clicking on the folder within IIS Manager. It’s important that you’re in your wp-admin directory – if you create the following rule in the root of your WordPress site, you’ll end up blocking everyone from accessing your site.
- Next, double click on IP Address and Domain Restrictions icon
- Under the Actions panel click on Edit Feature Settings…
- This will pop up the Edit IP and Domain Restrictions Settings Click on the drop down menu under Access for unspecified clients and select Deny. Leave Deny Action Type: as Forbidden. Click on OK button.
Now anyone from around the world will be blocked. This means you will be blocked too but that’s okay. The next steps creates a rule to only allow your IP address to access the wp-admin directory.
- Within the IP Address and Domain Restrictions module under Actions click on Add Allow Entry…
- Enter your IP address into the Specific IP address Click the OK box to save the IP.
Now we blocked everyone in the world but only allowed your IP address to access the wp-admin directory. This also means if your IP address changes you will need to update the rule to allow your new IP address. If you don’t know your outside IP address you can always Google What’s My IP. Google will tell you at the top of the search results. That’s the IP address you want to allow.
If you just want to cut to the chase, simply create a web.config file within the wp-admin directory and enter the following:
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <security> <ipSecurity allowUnlisted="false"> <add ipAddress="188.8.131.52" allowed="true" /> </ipSecurity> </security> </system.webServer> </configuration>
Of course you want to replace 184.108.40.206 with your real IP address.