Enabling remote connections to a named instance of SQL Server

Recently, I installed SQL Server 2012 on a machine that I also had SQL Server 2008 R2 installed.  Because the default instance was the 2008 instance, I had to create a new instance that I named STEVE2012.  Even though STEVE2012 was configured to allow remote connections (by default), I still got the tell-tale "make sure remote connections are allowed" error messages when I tried to connect a web app to this instance.  I had to do the following:

1. Open up SQL Server Configuration Manager (You can find this in the Start Menu under Microsoft SQL Server).
2. Expand SQL Server Network Configuration and then click on Protocols for STEVE2012.  Double-click TCP/IP and set the Enabled property to "Yes".
3. Then, click SQL Server Services in the tree view, and restart the service for STEVE2012.

So Named Instances are listening on a dynamic port rather than the standard 1433.  If your database server has a firewall (mine doesn't...development), you'll need to configure the instance to listen on a static port using the configuration manager.  Then open up this port in your firewall.

Publishing Web Applications using Visual Studio

"Publishing" a web application means preparing the application into a state from which it can be "deployed" to the web server.  For me, this has always been two distinct processes, but Visual Studio has some publishing options that allow you to deploy to a web server as part of the publishing process.

You have 4 "publish methods" to choose from when you right click a web application project and select Publish.  FTP, File System, Web Deploy, and Web Deploy Package.

File System

Here you are simply choosing a folder and when you click Publish, the files will be placed in this folder.  You can then copy these files into the physical directory of the site.

FTP

Same idea as above except you are selecting a folder on another computer.

Web Deploy

This is also known as One-Click Publishing.  You simply specify the server name and the site, and Visual Studio will deploy the site for you when you publish.  Specify the Destination URL field if you want the default browser to open up with this address when publishing and deployment is complete. Keep in mind that the server you are deploying to must support Web Deploy.  Here are the instructions to set up a web server to support Web Deploy:

1. Download and install Web Deploy 3.5.  (This assumes you are publishing using Visual Studio 2013).  During installation, be sure to click Custom and choose to install all the features available.
2. Open up IIS, and click the root server node in the tree view on the left.
3. Select Management Service.
4. The options will be grayed out if the Web Management Service is running.  Stop the service, and be sure to check the "Enable remote connections" checkbox.
5. In addition you may need to add your development machine's IP address to the box at the bottom.
6. You might also need to open a firewall port (8172 by default), on the server.

Web Deploy Package

Same idea as Web Deploy except a package is created instead of Visual Studio deploying the application for you.  A package is simply a zip file that contains the published application files that you would also see if you selected the File System option.  However, the package can be imported using IIS with a nifty wizard.

Web deploy packages allow you to set some runtime parameters for the web.config file.  If there is a value that the developer does not know at compile time (like a password), the administrator will be prompted for the value when he imports the web deploy package.  Simply add a file called parameters.xml to the project directory in Visual Studio and put something like this in there:

<parameters>
  <parameter name="Test Key 1 Entry" 
             description="Specifies what environment you are in."
             defaultValue="Development" tags="">
    <parameterEntry kind="XmlFile"
                    scope="\\Web.config$"
                    match="//appSettings/add[@key='TestKey1']/@value">
    </parameterEntry>
  </parameter>
</parameters>

The parameter node describes what it will look like in the IIS wizard when you import the package.  The parameterEntry node describes how to update the file.  The scope attribute defines the file to update, and the match attribute represents an XPath that selects the attribute and node to update.

A note on transforming web.config files

When you do know the web.config settings for various environments at compile time, you transform web.config files.  Essentially this means modifying the web.config that gets published based on the build configuration.  Instructions for doing this is beyond the scope of this post.

ASP.NET Membership Encryption and View State Encryption/Validation

When using .NET's Membership provider to implement Forms Authentication in your application, the user names and passwords are encrypted in the database (aspnet_Membership) table.  You must specify the encryption method and a key to perform the encryption and decryption in the web.config file.  This is where this is specified:

<system.web>
    <machineKey decryptionKey="YOUR KEY GOES HERE" decryption="AES" />
<system.web />

Despite the name, the decryption and decryptionKey attributes are not only used for decryption but are also used for encryption.  This tells Membership how to encrypt passwords and usernames in the database.  It will also tell ASP.NET how to encrypt the View State if you are configured to encrypt the View State.  This decryption attribute is set to AES.  This is the standard for encryption at the time of this writing.  In fact the decryption attribute's default is AES.  Triple DES (3DES) is also acceptable if you have older DES stuff.

How do you generate a decryptionKey?  Click on the application in IIS, and double click the Machine Key icon.  Here you can select the Generate Keys option on the right to generate a key for you.  If you click Apply, it will update the machineKey node in the web.config file with the information.

The validation and validationKey attributes are only used to validate the View State.  A hash value is created by using the validationKey and the hash function specified by the validation attribute.  This hash value is compared to what it initially was when it was sent by the browser to what is is when the server receives it.  If they are different, then the server knows that the View State was tampered with.  The validation attribute is set to "SHA1" by default.  You don't necessarily need to generate a validationKey.  ASP.NET can generate one each time a request is made.  However, if you have multiple load balanced web servers, then you must generate a validationKey so that the servers can share the Session Id.  You would follow the same procedure in IIS to generate a validationKey if you so desire.  Here is an example of the machineKey node with both validation and decryption attributes configured.

<system.web>
    <machineKey validationKey="YOUR KEY GOES HERE" 
        decryptionKey="YOUR KEY GOES HERE" decryption="AES" validation="SHA1" />
<system.web />

How to encrypt the View State

How to enable SSL on a web site in IIS

1. Open IIS.
2. Click the root node in the tree view at the left.
3. Double click Server Certificates.
4. In the list on the right, choose either Create Self Signed Certificate or Import.
5. Click the site you want to secure.
6. Click Bindings on the right and click Add.
7. Choose https and select the certificate in the drop down list.

That's it.  Now you're site is listening on port 443 (default for https requests).  If you're using a self-signed certificate, your browser will throw up all kinds of red flags, but you are encrypted now.

Lots of good info here.

ASP.NET IIS Registration Tool (aspnet_regiis.exe)

Let's say you install a new version of Visual Studio which also installs a new version of the .NET Framework.  If you are using IIS (not IIS Express) on your local PC to host a site you are developing, it won't work until you register the new version of the framework with IIS by using the registration tool.  The tool exists in each version of the frameworks folder.  Just browse to the folder of the framework you want to register and run the tool with the -i option.

Open a Command Prompt as an administrator.

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319 for example.

Then, aspnet_regiis.exe -i

MS info on tool