When you create a new project using the Windows 8 Style application templates Visual Studio does a number of things behind the scenes on your behalf.  Understanding these is handy should you knowingly or unintentionally develop an application that depends on any of these settings.  Creating your own Windows 8 style applications in Visual Studio 2012 is very straightforward, it is upon leaving the safe cocoon of Visual Studio that things get interesting. 

Visual Studio acquires a Windows 8 developer license on your behalf in order to permit testing Windows 8 style applications before approval from the Store and to allow deployment of non packaged applications (more on that later).  You will be prompted to login to a valid Windows Live ID in order to obtain this license when creating a new Windows 8 style application or loading a solution that contains a Windows 8 Style application if you do not have a developer license on that machine already.  They periodically expire and require reacquisition.  An alternative to doing this in Visual Studio is to manage you developer licenses at the command prompt using these PowerShell cmdlets :

• Show-WindowsDeveloperLicenseRegistration requires elevated permissions and shows the dialog to obtain a new developer license.
• Get-WindowsDeveloperLicense  will work with normal permissions and gets the expiration time and a boolean value indicating if the developer license is valid.
• Unregister-WindowsDeveloperLicense can be used to remove the local machine's developer license.  You will be warned that some apps may no longer function properly.  This cmdlet requires elevated permissions to execute.

The new project you created also includes a test certificate.  You will find this in your project named {yourappname}_TemporaryKey.pfx and it facilitates the signing and deployment of your application package.  Signing and deploying your package is a fairly complex operation which Visual Studio manages to completely abstract away into a simple press of the F5 key.

Finally, Windows 8 also employs a new loopback rule that prevents Windows 8 style apps from access to localhost.  In order for a Windows 8 style app to access localhost in any way the application must be exempted from the loopback lockdown.  Visual Studio takes care of this for you without any mention of doing so but outside the IDE you'll quickly find that your WinRT applications get an error trying to communicate with localhost (rather silently).  I'll get into how to do it yourself outside of Visual Studio later since this requires some additional understanding of publisher, application and family identities. 

Signing and Side loading your packages

Creating and deploying packages with self signed certificates is the de-facto testing scenario but the real world case for doing so is very limited.  After some experimentation it becomes very evident in real-word scenarios that one should obtain a code signing certificate from a certificate authority to sign app packages instead of trying to manage self signed certificates.  The complexity of creating, distributing, and installing your own certificates can quickly eclipse any monetary savings over buying a CA issued certificate.

While testing on a development platform, Visual Studio makes certificate management simple by embedding a test certificate in the project itself, thus removing any need to generate and install your own certificates.  Once you move beyond a development platform you can either create and install your own certificates or use one from a certificate authority like Verisign, Thawte, or Comodo.

Signing and deploying you application depends on the package name and publisher name set in the application manifest file.  By default the publisher name is set to the current user name, the same name you would see in your C:\users path, and the application ID is a GUID created by Visual Studio when the project is created.

Limitations and Pre-Requisites of side loading

In order to side load applications for Windows 8 Style applications (formerly Metro) in addition to having a properly packaged and signed (with a trusted certificate!) appx package the Group Policy must be altered to "allow all trusted applications to install" or by setting the following in the Registry.  Configuring your Group Policy is already well documented in a number of other blog posts.

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

One recent change imposed between the release of RC and RTM is that only domain joined SKUs of Windows 8 will permit side loading without obtaining a "product key" from Microsoft, so side loading is only truly practical in this scenario.  This is well suited for what Microsoft intended, which is permitting deployment of internal line of business applications on a corporate network.   If you need to install to a consumer SKU then you must obtain this product key, in which case perhaps you would be better served to simply publish through the Store.