Migrate C++ projects from packages.config to PackageReference with Central Package Management

[Alan-Jowett]

Summary

Migrate C++ projects from the legacy packages.config approach to the modern PackageReference format with NuGet Central Package Management (CPM). This will eliminate the local packages/ directory (~2.5 GB) and centralize version management.

Current State

The repository has 12 packages.config files across C++ projects:

• ebpf_extensions/ntosebpfext/sys/packages.config
• ebpf_extensions/ntosebpfext/user/packages.config
• ebpf_extensions/neteventebpfext/sys/packages.config
• ebpf_extensions/neteventebpfext/user/packages.config
• tests/ntosebpfext/ntosebpfext_unit/packages.config
• tests/neteventebpfext/neteventebpfext_unit/packages.config
• tests/neteventebpfext/netevent_sim/packages.config
• tools/process_monitor_bpf/packages.config
• tools/ntos_ebpf_ext_export_program_info/packages.config
• tools/netevent_ebpf_ext_export_program_info/packages.config
• tools/netevent_monitor/packages.config
• scripts/setup_build/packages.config

These reference the following packages:

• eBPF-for-Windows.x64 (1.0.0-rc1)
• Microsoft.Windows.SDK.CPP (10.0.26100.4204)
• Microsoft.Windows.SDK.CPP.arm64 (10.0.26100.4204)
• Microsoft.Windows.SDK.CPP.x64 (10.0.26100.4204)
• Microsoft.Windows.SDK.CPP.x86 (10.0.26100.4204)
• Microsoft.Windows.WDK.ARM64 (10.0.26100.4204)
• Microsoft.Windows.WDK.x64 (10.0.26100.4204)
• Microsoft.Windows.WDK.x86 (10.0.26100.4204)

The Directory.Packages.props file exists but has ManagePackageVersionsCentrally set to false and only covers .NET packages.

Benefits

1. Eliminates ~2.5 GB local packages directory

With packages.config, NuGet restores packages to a local packages/ folder in the repo. With PackageReference, packages are stored in the global NuGet cache (%userprofile%\.nuget\packages), which is shared across all repositories.

2. Faster builds and clones

• No need to download/extract packages per-repo
• Smaller repo footprint (if packages/ was ever accidentally committed)
• Shared cache means packages only download once per machine

3. Centralized version management

All package versions defined in one place (Directory.Packages.props), making it easier to:

• Update package versions across all projects atomically
• Ensure version consistency across the solution
• Review package dependencies in one file

4. Better dependency resolution

PackageReference uses transitive dependency resolution, automatically handling package dependencies without manual management.

5. Simplified project files

PackageReference entries go directly in .vcxproj files, eliminating the need for separate packages.config files.

6. Aligns with .NET projects

The .NET projects in this repo (process_monitor, process_monitor.Library, process_monitor.Tests) already use PackageReference. This change would make all projects consistent.

Proposed Changes

1. Update Directory.Packages.props:

   • Set ManagePackageVersionsCentrally to true
   • Add C++ package versions:
     xml <PackageVersion Include="eBPF-for-Windows.x64" Version="1.0.0-rc1" /> <PackageVersion Include="Microsoft.Windows.SDK.CPP" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.SDK.CPP.arm64" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.SDK.CPP.x64" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.SDK.CPP.x86" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.WDK.ARM64" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.WDK.x64" Version="10.0.26100.4204" /> <PackageVersion Include="Microsoft.Windows.WDK.x86" Version="10.0.26100.4204" />

2. Migrate each .vcxproj: Add <PackageReference Include="..." /> (without version) for each package

3. Delete packages.config files: Remove all 12 files

4. Update .gitignore: Ensure packages/ is ignored (if not already)

5. Delete local packages/ directory: Remove the ~2.5 GB folder

6. Update submodules: The external/usersim submodule also has packages.config files that would benefit from the same migration (separate effort)

References

• NuGet Central Package Management
• Migrate from packages.config to PackageReference

[Alan-Jowett]

Investigation Findings from PR #299

After attempting the migration in PR #299, we discovered several complexities that require a more careful approach:

Issues Discovered

1. Mixed Import Approaches in vcxproj Files

The current vcxproj files have both old-style manual imports AND the new PackageReference entries:

<!-- Old-style import at top of file -->
<Import Project="$(eBPFForWindowsPackagePath)\build\native\ebpf-for-windows.x64.props" />

<!-- New PackageReference added by migration -->
<ItemGroup>
  <PackageReference Include="eBPF-for-Windows.x64" />
</ItemGroup>

This causes duplicate imports and build errors like:

warning MSB4011: "...ebpf-for-windows.x64.props" cannot be imported again. It was already imported...

2. EnsureNuGetPackageBuildImports Targets

The vcxproj files contain error-checking targets that reference the old package paths:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
  <Error Condition="!Exists('$(eBPFForWindowsPackagePath)\build\native\ebpf-for-windows.x64.props')" ... />
</Target>

These need to be removed when using PackageReference.

3. wdk.props and ntosebpfext.props Dependencies

The wdk.props file imports SDK packages using paths based on $(NuGetPackageRoot) or local packages/ folder. These imports conflict with PackageReference-generated imports.

4. dotnet restore vs msbuild /t:restore

• dotnet restore only restores .NET SDK-style projects
• msbuild /t:restore is needed for C++ projects with PackageReference
• But msbuild restore generates project.assets.json files that cause "Sequence contains no elements" errors

5. Mixed .NET and C++ Projects

The .NET projects (process_monitor.Library, process_monitor.Tests) have project references to C++ projects (process_monitor_bpf), causing compatibility errors during restore:

error NU1201: Project process_monitor_bpf is not compatible with net8.0-windows7.0

Required Migration Steps

A proper migration would need to:

1. Remove old-style imports from each vcxproj file (the manual Import statements for package props/targets)

2. Remove EnsureNuGetPackageBuildImports targets from each vcxproj file

3. Update wdk.props to not manually import SDK/WDK packages (let PackageReference handle it)

4. Update ntosebpfext.props to derive $(eBPFForWindowsPackagePath) from the NuGet global cache

5. Update CI workflow to properly restore C++ PackageReference projects

6. Test thoroughly on a clean machine without cached packages

Recommendation

This migration is more complex than initially estimated. Consider:

• Breaking it into smaller PRs (one per package type)
• Testing each change in isolation
• Possibly keeping packages.config for now if the complexity isn't worth the benefit