You can deploy managed applications built with SQL Server Compact 3.5 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 Microsoft Windows Installer (MSI) file and on a device by copying and installing the device-specific SQL Server Compact Windows Cabinet (CAB) files. In private deployment on both computers and devices, the SQL Server Compact components 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 that are registered in COM. This means that updates to SQL Server Compact 3.5 can be centrally serviced by using Microsoft Update. Applications that use central deployment of SQL Server Compact will use the updated version of SQL Server Compact 3.5 the next time they are run. A potential disadvantage of central deployment is that SQL Server Compact 3.5 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 3.5 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 3.5.

With private deployment, an application uses its own local copy of the SQL Server Compact managed assemblies and any 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. If the privately deployed SQL Server Compact assemblies have a higher version number than those installed centrally in the GAC, then the application uses the privately deployed assembles 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, the potential problems faced with central deployment on locked down systems can be avoided. Private deployment places greater responsibility on the developer, however, because updates to privately deployed SQL Server Compact assemblies cannot be centrally serviced. (Only the centrally installed instance of SQL Server Compact 3.5 is updated by Microsoft Update.) 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 3.5 that includes the necessary updates and then republish it.

Private and central deployment of SQL Server Compact based applications are supported for both desktop and devices applications.

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.

Beginning with SQL Server Compact 3.5 Service Pack 1 (SP1), 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: 3.5.1.0, 3.5.1.2, 3.5.1.3, 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\v3.5\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 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 3.5 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 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 3.5 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 3.5:

1. Ensure that updates are current for SQL Server Compact 3.5 on the development computer.

2. 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\v3.5\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.)

3. Add any required native libraries to the project. These should be added by browsing to the %Program Files%\Microsoft SQL Server Compact Edition\v3.5 folder, the %Program Files(x86)%\Microsoft SQL Server Compact Edition\v3.5 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: sqlceme35.dll, ssceqp35.dll, sscese35.dll, and sqlceer35xx.dll.

   The 64-bit SQL Server Compact 3.5 native assemblies are not installed on a 32-bit computer. To build SQL Server Compact 3.5 applications for 64-bit computers when using a 32-bit development environment, you must extract these assemblies from the 64-bit SQL Server Compact 3.5 installer (SSCERuntime_x64-ENU.msi). For more information, see How to: Extract 64-bit DLLs from the SQL Server Compact Runtime Installer.

4. 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).

To develop a smart device application that uses private deployment of SQL Server Compact 3.5:

1. Ensure that updates are current for SQL Server Compact 3.5 on the development computer.

2. Add a reference to the .NET Compact Framework Data Provider for SQL Server Compact from the .NET tab of the Add Reference dialog box in Visual Studio. This adds the data provider from the %Program Files%\Microsoft SQL Server Compact Edition\v3.5\Devices folder to your project. This step is the same for all smart device applications whether they use privately or centrally deployed versions of SQL Server Compact.

3. Add any required native libraries to the project. These should be added by browsing to the appropriate folder for your target platform: %Program Files%\Microsoft SQL Server Compact Edition\v3.5\Devices\platform\processor folder. At a minimum, the following native libraries must be added: sqlceme35.dll, ssceqp35.dll, sscese35.dll, and sqlceer35xx.dll.

4. Ensure that the managed assemblies and the native libraries added above are copied to the build output.

For more detailed information about building smart device applications, see Building Smart Device Applications (SQL Server Compact).

Reference

Deploying Smart Device Applications

Deploying Desktop Applications

Concepts

Building Applications for Desktops (SQL Server Compact)

Building Smart Device Applications (SQL Server Compact)