Paket integration with Visual Studio (and msbuild)

Description

When paket.lock changes, Visual Studio does not launch a "Restore" when I try to build the solution/project through the UI. Therefore if a package version has been changed in paket.lock, the project will still use the previous version and not the new one as wanted.

I've noticed that everything works fine if I use "dotnet build" instead of using Visual Studio UI to build the project because - in the latter - "Restore" is called before trying to "Build".

I know that Visual Studio UI uses msbuild under the hood, so I've tried to reproduce using msbuild and I observe the same behavior as when I use the Visual Studio UI to build.

Repro steps

I've created a python script (demo_lack_of_restoration.txt - I changed the extension to be allowed to upload it) that does the following:

1. Create a new C# console project
2. Install paket locally in this project
3. Configure paket (paket.dependencies, paket.references, paket.lock) in the project to handle exactly one direct dependency (System.Text.Json 8.0.5)
4. Build with msbuild with System.Text.Json 8.0.5 => we have the 8.0.5 version as our dependency
5. Change package version to 8.0.4 in paket.lock
6. Build with msbuild again => we still have the 8.0.5 as our dependency - this is the underlying issue - I'd expect it to be the 8.0.4
7. Build with dotnet build => we now have the correct 8.0.4 as our dependency
8. Change package version back to 8.0.5 in paket.lock
9. Build with msbuild => we still have the 8.0.4 - I'd expect it to be the 8.0.5
10. Build with dotnet build => we have the 8.0.5 as I'd expect

I attached the resulting project directly in this zip :
MyProject.zip

Expected behavior

I'd expect Visual Studio to be able to understand that paket.lock changed and that it needs to do a "Restore" before doing "Build" (same issue when I try to run the executable in the UI (shortcut F5)).

Actual behavior

Visual Studio only calls "Build", thinks there is nothing more to be done and still uses the old package version.

Known workarounds

If I add a new msbuild target (in Directory.Build.targets for instance) that uses a cached version of paket.lock to compare the two files in order to run a "dotnet restore" if there is a difference, I am able to have changes in paket.lock to be monitored and the msbuild will be able to "Restore" correctly before the "Build" :

<Project>
	<PropertyGroup>
		<PaketLockTimestampCache>$(MSBuildProjectDirectory)\obj\paket.lock</PaketLockTimestampCache>
	</PropertyGroup>

	<Target Name="RestorePaketOnLockChange" BeforeTargets="PrepareForBuild" Inputs="$(PaketLockFilePath)" Outputs="$(PaketLockTimestampCache)">
		<Message Text="Paket.lock has changed... Launching a new restore..." Importance="High" />

		<!-- Ensure the obj directory exists -->
		<MakeDir Directories="$(MSBuildProjectDirectory)\obj" Condition="!Exists('$(MSBuildProjectDirectory)\obj')" />

		<!-- Restore Paket if paket.lock changes -->
		<Exec Command="dotnet restore" />

		<!-- Update the timestamp cache -->
		<Copy SourceFiles="$(PaketLockFilePath)" DestinationFolder="$(MSBuildProjectDirectory)\obj" OverwriteReadOnlyFiles="true" />
	</Target>
</Project>

What is my use case

Ideally, we do not want developers to have to handle package updates manually on their own: we would like to be able to update packages (through "paket update" for instance) globally and then use locally the resulting changes specified in paket.lock so we know every developer, for a given git branch, will use the exact same version of each package without them having to do any additional steps.

What do you think ? Should we do things differently relatively to paket integration ? Or is there something you could do on paket side ?

Thanks,

Start by running the reproduction described in demo_lack_of_restoration.txt and compare the msbuild and dotnet build results after changing paket.lock. Read the Paket integration and the Directory.Build.targets workaround context. Done means Visual Studio and msbuild detect paket.lock changes and restore the locked package version before Build or F5.