Resolving .NET Framework v4.7 Reference Errors When Building System.Data.SQLite

Project Configuration Mismatch in System.Data.SQLite Build Process

Issue Overview: Target Framework Declaration Conflicts in Legacy .NET Projects

The core issue revolves around a build failure when attempting to compile System.Data.SQLite projects using Visual Studio 2019 or 2022, with the error "Your project does not reference ‘.NETFramework,Version=v4.7’ framework." This error indicates a mismatch between the project’s declared target framework and the build system’s expectations. The problem is observed specifically in projects like System.Data.SQlite.Module.2017 and System.Data.SQlite.2017, which are part of the SQLite library’s source distribution. These projects use legacy .NET Framework targeting mechanisms but are interpreted by modern NuGet and MSBuild tooling as requiring updated project file syntax. The root conflict lies in the interaction between the TargetFrameworkVersion property (used in older .csproj files) and the TargetFrameworks property (used in SDK-style projects or multi-targeting scenarios). The build system expects the project to declare compatibility with .NET 4.7 through a format that NuGet can recognize during package restoration, but the existing project files use outdated XML configurations that do not align with post-2017 tooling defaults.

Possible Causes: NuGet Compatibility, Project File Syntax, and Framework Targeting Gaps

Three primary factors contribute to this error:

1. Legacy Project File Format vs. Modern Tooling Expectations: The System.Data.SQLite 2017 project files predate the widespread adoption of SDK-style .csproj files introduced with .NET Core and later retrofitted into .NET Framework tooling. These older projects use <TargetFrameworkVersion>v4.7</TargetFrameworkVersion>, which is valid for single-targeting but does not trigger NuGet’s framework compatibility checks. Modern NuGet versions (v6.0+) and Visual Studio 2022 enforce stricter validation of the TargetFrameworks property (plural) even when building .NET Framework projects, leading to a mismatch.

2. Missing or Incorrectly Installed .NET 4.7 Targeting Pack: Visual Studio 2019/2022 might lack the .NET Framework 4.7 targeting pack if the ".NET desktop development" workload was not fully installed. This causes MSBuild to fail when resolving references, even if the project file technically declares v4.7. The error message about missing framework references can be misleading here, as it conflates NuGet’s framework checks with physical SDK availability.

3. NuGet Package Restoration Incompatibility: The unmodified System.Data.SQLite source code does not include NuGet package references in the conventional packages.config or PackageReference format. However, the presence of .nuget folders or residual NuGet.targets import statements in the project files can force NuGet to attempt package restoration against a non-existent TargetFrameworks property. This creates a chicken-and-egg scenario where the build process demands framework validation before restoring packages, but the validation fails due to syntax mismatches.

Troubleshooting Steps: Aligning Project Configuration with Modern Build Pipelines

Step 1: Validate .NET 4.7 Targeting Pack Installation

Open Visual Studio Installer and modify the existing Visual Studio 2019/2022 instance. Under the Individual components tab, ensure the following are checked:

• .NET Framework 4.7 targeting pack
• .NET Framework 4.7 SDK
• .NET Framework 4.7.1/4.7.2 targeting packs (for backward compatibility layers)

Reboot the machine after installation to ensure PATH variables and registry entries are updated. Launch Developer Command Prompt for Visual Studio and run:

msbuild -p:Configuration=Release -p:TargetFrameworkVersion=v4.7

If this command succeeds but the build.bat fails, the issue lies in the build script’s environment configuration.

Step 2: Migrate Project Files to Hybrid SDK-Style Syntax

Modify the .csproj files (e.g., System.Data.SQlite.2017.csproj) to include both legacy and modern properties. Replace:

<TargetFrameworkVersion>v4.7</TargetFrameworkVersion>

with:

<TargetFramework>net47</TargetFramework>
<TargetFrameworkVersion>v4.7</TargetFrameworkVersion> <!-- Preserve for legacy tools -->

This dual declaration satisfies NuGet’s requirement for TargetFramework (singular) while retaining compatibility with older build scripts that parse TargetFrameworkVersion. For projects requiring multi-targeting (uncommon in System.Data.SQLite), use:

<TargetFrameworks>net47;net472</TargetFrameworks>

Step 3: Force NuGet Restoration with Framework Overrides

Navigate to the solution root containing the .sln file and execute:

nuget restore -Force -Property:TargetFrameworkVersion=4.7

This bypasses the project-level TargetFrameworks check by explicitly setting the framework version during package resolution. If the build.bat script invokes NuGet internally, modify the script to include the -Property:TargetFrameworkVersion=4.7 argument.

Step 4: Patch Build Scripts to Enforce Framework Consistency

Edit build.bat (or equivalent build scripts) to explicitly pass framework parameters to MSBuild. Locate lines invoking MSBuild and append:

-p:TargetFrameworkVersion=v4.7 -p:TargetFramework=net47

For example:

msbuild "%SQLITE_SOLUTION%" -p:Configuration=Release -p:TargetFrameworkVersion=v4.7 -p:TargetFramework=net47

Step 5: Disable NuGet Implicit Framework Checks

As a last resort, add the following property to problematic .csproj files:

<PropertyGroup>
  <ValidateFrameworkCompatibility>false</ValidateFrameworkCompatibility>
</PropertyGroup>

This suppresses the "does not reference framework" error but may mask deeper issues. Use this only after confirming that .NET 4.7 tooling is correctly installed.

Step 6: Manual Framework Reference Injection

For projects with no NuGet dependencies but still throwing the error, manually add a dummy framework reference. Insert in .csproj:

<ItemGroup>
  <Reference Include="System.Net.Http" />
</ItemGroup>

This forces MSBuild to validate framework presence without relying on NuGet’s automatic checks.

Final Validation: Build in Clean Environment

Create a fresh directory, extract the original System.Data.SQLite source ZIP, apply the above modifications, and run:

nuget restore
msbuild /p:Configuration=Release /p:Platform="Any CPU"

Successful compilation indicates that the project file syntax and environment are now aligned. If errors persist, use MSBuild’s detailed logging:

msbuild -fl -flp:verbosity=diag -clp:ShowCommandLine

Inspect the msbuild.log file for unresolved references or framework validation failures.