Private Deployment vs. Central Deployment (SQL Server Compact)
You can deploy managed applications built with SQL Server Compact 4.0 by using either central deployment or private deployment for SQL Server Compact. In central deployment, SQL Server Compact is installed on a computer by using the setup executable. In private deployment, the SQL Server Compact binaries are placed in the application folder itself. Privately deploying SQL Server Compact in this manner is also referred to as XCOPY deployment of SQL Server Compact.
With central deployment, an application uses the SQL Server Compact managed assemblies (System.Data.SqlServerCe.dll and System.Data.SqlserverCe.Entity.dll) installed in the Global Assembly Cache (GAC) and the SQL Server Compact native components from the central location i.e. %Program Files%\Microsoft SQL Server Compact Edition\v4.0. If a newer version/update of SQL Server Compact 4.0 is installed, then the applications that use central deployment of SQL Server Compact will use the updated version of SQL Server Compact 4.0 the next time they are run. A potential disadvantage of central deployment is that SQL Server Compact 4.0 can only be installed by a user with Administrator privileges on the computer. (This is because these privileges are required to install assemblies in the GAC and to register the native components.) If the application is deployed using ClickOnce technology and SQL Server Compact 4.0 is centrally deployed as a prerequisite during the installation, the installation may fail because the user lacks the necessary privileges to install SQL Server Compact 4.0.
With private deployment, an application uses its own local copy of the SQL Server Compact managed assemblies and the required SQL Server Compact native libraries. These assemblies and native libraries are bundled with the application and installed in the application's file path on the target system when it is deployed. The privately deployed SQL Server Compact assemblies need to have a higher version number than those installed centrally in the GAC for the application to use the privately deployed assemblies rather than those centrally deployed. If there are no SQL Server Compact assemblies in the GAC (SQL Server Compact has not been centrally deployed on the target computer), the application uses its privately deployed assemblies. One advantage of using private deployment is that, because the SQL Server Compact assemblies are not installed in the GAC and the native components are not registered with COM and hence the user does not need the administrative privileges on the machine thus avoiding the potential problems faced with central deployment on locked down systems. Private deployment places greater responsibility on the developer, however, because updates to privately deployed SQL Server Compact assemblies cannot be centrally serviced. If an update to the SQL Server Compact assemblies deployed with the application is necessary, the developer must rebuild the application with a version of SQL Server Compact 4.0 that includes the necessary updates and then republish it.
The installation behavior of SQL Server Compact 4.0 on 32-bit and 64-bit operating systems is as stated below:
SQL Server Compact 4.0
The following are the managed and native assemblies installed:
Managed assemblies: These are installed at the location %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private:
Native assemblies: These are installed at %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private\x86 and %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private\amd64,except sqlceoledb40.dll, whose location is %Program Files&\Microsoft SQL Server Compact Edition\v4.0.
In addition to the above, there is one assembly and one manifest for the Microsoft Visual C++ 2008 Runtime Libraries (CRT):
Updates and Private Deployment
One of the issues with private deployment is that the CLR, by default, loads assemblies from the GAC. For this reason, it is difficult to push updates to privately deployed SQL Server Compact assemblies when an older version of SQL Server Compact exists in the GAC, because the CLR will continue to load the SQL Server Compact assemblies from the GAC. The only case where a privately deployed assembly will be loaded by the CLR occurs when it has an assembly version that is different from the one in GAC, and the application has been compiled with the assembly that is deployed in the GAC.
In SQL Server Compact 4.0 , this problem has been addressed by:
Incrementing the assembly version number for all software updates including hotfixes, service packs, critical patches, and security updates. The assembly version is incremented as follows: 126.96.36.199 , 188.8.131.52 , 184.108.40.206 , and so on.
Installing additional copies of the managed assemblies (System.Data.SqlServerCe.dll and System.Data.SqlServerCe.Entity.dll) in the following folder: %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private.
Updates are applied in the following manner:
For regular hotfixes, the update is applied to all copies of either or both of the two managed assemblies; however, the assembly version is only updated for the copies of the assemblies in the Private folder. This ensures that assemblies in the Private folder on a development computer have a higher version number than those installed in the GAC for non-critical updates. This also ensures that for applications that use private deployment on computers where the update is applied, the CLR will continue to load the SQL Server Compact 4.0 assemblies from the application's path (because the version number of the assemblies in the GAC will not change).
For security updates, service packs, and critical updates, the update is applied to all copies of the two managed assemblies and the assembly version is also updated for all of them. In addition, the Publisher Policy is updated to ensure auto re-direction of all lower version assemblies to the new version. This ensures that for computers on which the update is applied, the CLR will load the managed assemblies from the GAC for all SQL Server Compact 4.0 applications; including those that used private deployment.
Developing Applications that use Private Deployment
To develop a desktop application that uses private deployment of SQL Server Compact 4.0:
Ensure that updates are current for SQL Server Compact 4.0 on the development computer.
Add any references to the two SQL Server Compact managed assemblies to your project by browsing to the %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private folder in the Add Reference dialog box in Visual Studio. (For applications that use central deployment, these references are added from the .NET tab.)
Add any required native libraries to the project. These should be added by browsing to the %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private\x86 folder, the %Program Files%\Microsoft SQL Server Compact Edition\v4.0\Private\amd64 folder, or both. The folder from which you add the native libraries depends on the platform (x86, x64, or Any CPU) for which you are developing your application.
At a minimum, the following native assemblies must be added:
All the native components find a place in the private folder itself. For the ease of manageability and use, the folder structure of native components for x86 and amd64 platforms, the directory structure is identical in the setup.
The 64-bit SQL Server Compact 4.0 setup is an all-inclusive setup. It installs the 32bit components, 64bit components and architecture neutral components on the machine. Both the 32-bit and 64-bit setups include native binaries of either architecture for private deployment. Therefore, to build the SQL Server Compact 4.0 applications for 64-bit computers when using 32-bit development environment, you do not need to extract any 64-bit native assemblies. You just need to pick 64-bit native binaries from %Program files%\Microsoft SQL Server Compact Edition\v4.0\Private\amd64 folder.
Ensure that the managed assemblies and the native libraries added above are copied to the build output.
For more detailed information about building desktop applications, see Building Applications for Desktops (SQL Server Compact).