Missing System.Data.SQLite.SEE.License Assembly Error After Upgrade Due to Deprecated CryptoAPI Codec

Legacy CryptoAPI Codec Dependency Triggers Missing Assembly Error in System.Data.SQLite 1.0.114.0

Issue Overview: Deprecated Encryption Mechanism Causes Missing Assembly & Connection Failures

The core issue arises when upgrading an application to System.Data.SQLite version 1.0.114.0 (bundling SQLite 3.35.5) while relying on the legacy Password connection string property for database encryption. This triggers a runtime error:

Could not load file or assembly 'System.Data.SQLite.SEE.License, Version=1.0.114.0, Culture=neutral, PublicKeyToken=433d9874d0bb98c5' or one of its dependencies. The system cannot find the file specified.  

This error occurs because the CryptoAPI-based encryption codec, historically used to handle the Password property, was fully removed in System.Data.SQLite 1.0.113.0. Prior versions (≤1.0.112.2) included the System.Data.SQLite.SEE.License assembly as part of the SQLite Encryption Extension (SEE), which implemented the deprecated CryptoAPI codec.

Applications migrating from older System.Data.SQLite versions (e.g., 1.0.109.0) to 1.0.114.0 will encounter this error if their connection strings explicitly use Password=... for database encryption. The removal of SEE components breaks backward compatibility for encrypted databases dependent on this mechanism.

Key technical relationships:

• System.Data.SQLite.SEE.License: A licensing assembly required for the proprietary SEE module, which enabled encryption via the Password property.
• CryptoAPI Codec: A legacy Windows cryptographic API integration deprecated due to age, lack of maintenance, and incompatibility with modern .NET architectures.
• Connection String Password Property: Directly tied to the deprecated codec; its use in post-1.0.112.2 versions triggers assembly load failures.

Possible Causes: Architectural Changes & Unsupported Legacy Features

The missing assembly error stems from three interrelated factors:

1. Removal of CryptoAPI Codec in System.Data.SQLite ≥1.0.113.0
   The underlying SQLite core library underwent architectural changes that rendered the legacy CryptoAPI codec non-functional. This codec had been unmaintained since 2011 and unsupported since 2017. The System.Data.SQLite maintainers removed it entirely to streamline dependencies and align with modern encryption standards.

2. Implicit Dependency on SEE Components via Password Property
   Applications using Password= in their connection strings implicitly depend on the SEE module’s CryptoAPI integration. Newer System.Data.SQLite packages exclude SEE-related assemblies (e.g., System.Data.SQLite.SEE.License), causing load failures when the runtime attempts to resolve these missing dependencies.

3. Incomplete Migration to Supported Encryption Methods
   The Password property was never part of SQLite’s native API but a convenience wrapper around SEE. Developers unaware of this abstraction may assume it uses SQLite’s built-in encryption, leading to upgrade surprises when the dependency chain breaks.

Troubleshooting Steps, Solutions & Fixes: Migrate to Modern Encryption or Downgrade

Step 1: Confirm Use of Deprecated Password Property

Inspect the connection string for Password or HexPassword parameters. Example:

provider connection string="data source=C:\dbs\encrypted.db;password=MySecret"  

If present, the application relies on the deprecated CryptoAPI codec.

Step 2: Evaluate Encryption Requirements

Determine whether encryption is mandatory for compliance or security. If not, removing the Password property and using unencrypted databases may suffice. However, most production systems require encryption.

Step 3: Choose a Migration Path

Two primary solutions exist:

Option A: Downgrade to System.Data.SQLite 1.0.112.2
This retains compatibility with the legacy CryptoAPI codec but forfeits security updates and newer SQLite features.

1. Download System.Data.SQLite.Core.1.0.112.2.nupkg:
   Obtain the package from:

   https://system.data.sqlite.org/downloads/1.0.112.0/System.Data.SQLite.Core.1.0.112.2.nupkg  
   

2. Install via NuGet CLI:

   nuget install System.Data.SQLite.Core -Version 1.0.112.2 -Source C:\path\to\downloaded\package  
   

3. Verify Dependencies:
   Ensure all projects reference 1.0.112.2 packages to avoid version conflicts.

Option B: Migrate to SQLCipher Encryption
SQLCipher is a widely supported, open-source encryption extension integrated with System.Data.SQLite via the SQLitePCLRaw provider.

1. Install SQLCipher Packages:

   Install-Package SQLitePCLRaw.bundle_sqlcipher  
   Install-Package System.Data.SQLite.Core  
   

2. Modify Connection String:
   Replace Password=... with a PRAGMA key command:

   provider connection string="data source=C:\dbs\encrypted.db;Password=MySecret"  
   →  
   provider connection string="data source=C:\dbs\encrypted.db;PRAGMA key='MySecret'"  
   

3. Migrate Existing Databases:
   Use the sqlcipher_export() function to re-encrypt databases:

   ATTACH DATABASE 'new.db' AS encrypted KEY 'MySecret';  
   SELECT sqlcipher_export('encrypted');  
   DETACH DATABASE encrypted;  
   

4. Update Data Access Code:
   Ensure SQLiteConnection uses the SQLCipher provider:

   SQLiteConnectionStringBuilder builder = new SQLiteConnectionStringBuilder();  
   builder.DataSource = "encrypted.db";  
   builder.Password = "MySecret"; // Now maps to PRAGMA key  
   

Step 4: Handle Edge Cases & Testing

• Mixed Provider Environments: Applications using Entity Framework 6 must ensure System.Data.SQLite.EF6 references the correct provider. Reinstall EF6 packages after changing SQLite versions.
• x86/x64 Mismatches: Verify that all projects target the same architecture. Mixed-platform builds cause "bad image" exceptions.
• Backward Compatibility: Databases encrypted with SQLCipher cannot be opened by older System.Data.SQLite versions without re-encryption.

Step 5: Long-Term Maintenance

• Monitor Deprecations: Track System.Data.SQLite release notes for breaking changes.
• Automate Encryption Testing: Implement integration tests that verify database encryption/decryption workflows after upgrades.
• Consider Alternatives: Evaluate third-party encryption providers like Microsoft’s Always Encrypted for centralized key management.

By methodically addressing the CryptoAPI codec dependency and migrating to supported encryption methods, developers can resolve the missing assembly error while future-proofing their data security infrastructure.