The canonical way to deploy a Web Pages application to a remote server is to use the Publish facility of WebMatrix. (Or the publish facilities in Visual Studio, if that's what you're using.) Using a publish tool is nice, because it copies not just your application files (.cshtml pages, etc.), but also dependencies, notably the DLL files that are required for Web Pages (Razor) and the DLLs for SQL Server Compact, if needed.
But what if you cannot (or don't want to) use WebMatrix for deploying? You can still deploy using something like FTP, but it's then up to you to include the dependencies. This isn’t hard, it's just that you need to know what files to copy, from where, and where to put them.
To perform a manual FTP deploy, you copy everything from the website on your development computer (root folder + children) to the appropriate folder on the server. Copy all the .cshtml files, .html files, .css files, images, etc. (If you've got data in App_Data, there are additional considerations — see below.)
Then on the server, if there isn't already a bin folder under your app root, create one. (If you've installed NuGet packages, there probably already is a bin folder that contains the package files.) Copy everything that's in the following folder to the app's bin folder on the server:
C:\Program Files\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies
For a 64-bit machine, that's the Program Files (x86) folder.
This copies all the ASP.NET Web Pages assemblies — that is, the dependencies — to the server for this app. You need to copy the DLL files to the bin folder separately for each application that you deploy.
Deploying SQL Server Compact
If your app has a SQL Server Compact database (.sdf file in App_Data), you also need to copy the DLLs for the SQL Server Compact engine. This is known as a "private file-based deployment" or just "private deployment." The technique is similar to what you just did for the Web Pages assemblies.
From your development computer, copy everything from the following location to the app's bin folder:
C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private
Again, that's Program Files (x86) on a 64-bit machine.
You also need to register the SQL Server Compact assemblies. Create a Web.config file for the app (or open the existing one if the app has one) and make sure that it has the following highlighted entry:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.4.0" />
<add
invariant="System.Data.SqlServerCe.4.0"
name="Microsoft SQL Server Compact 4.0"
description=".NET Framework Data Provider for Microsoft SQL Server Compact"
type="System.Data.SqlServerCe.SqlCeProviderFactory,
^ System.Data.SqlServerCe, Version=4.0.0.1, Culture=neutral,
^ PublicKeyToken=89845dcd8080cc91" />
</DbProviderFactories>
</system.data>
</configuration>
Note! The carets (^) in the previous example indicate a place where I've wrapped the text. If you copy this text directly, remove the carets and make the line that starts with type= be all just one line through to the PublicKeyToken attribute value.
Note that the type attribute includes a version number. If you see something like the following error, you might have the wrong version number for the System.Data.SqlServerCe assembly:
Could not load file or assembly 'System.Data.SqlServerCe, Version=4.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Deploying SQL Server Compact Data
There's a hiccup if you have an .sdf file in App_Data that contains test data. Do you want to deploy that data to the server? If not, you have to copy off the test data to a new .sdf file, delete everything in the database, and then copy the .sdf file from your development computer to the app's App_Data folder on the server.
An additional complication arises if you have a membership data in the .sdf file, because you might want to deploy those tables (e.g., your existing administrative users) but not include other test data. There's no real solution here other than to do a variant on the previous — copy off the test data, then selectively clear data out of the database, then copy the .sdf file to the server. (For what it's worth, this can be tricky even if you're using fancy deployment tools.)