Open jonthysell opened 1 year ago
Note, we can't just turn this off because of our mixing of C## and C++ projects. From https://github.com/microsoft/react-native-windows/issues/11998#issuecomment-1673859527:
... because we have UWP C# projects (such as Microsoft.ReactNative.Managed) that depend on C++/WinRT projects (such as Microsoft.ReactNative), and we're using PackageReferences in both, NuGet restore always fails if we don't use force evaluate. We get these errors:
D:\a\_work\1\s\vnext\Microsoft.ReactNative.Managed\Microsoft.ReactNative.Managed.csproj : error NU1004: The project Microsoft.ReactNative has no compatible target framework. The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file. [D:\a\_work\1\s\vnext\Microsoft.ReactNative.sln] D:\a\_work\1\s\vnext\Microsoft.ReactNative.Managed.UnitTests\Microsoft.ReactNative.Managed.UnitTests.csproj : error NU1004: The project Microsoft.ReactNative has no compatible target framework. The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file. [D:\a\_work\1\s\vnext\Microsoft.ReactNative.sln] D:\a\_work\1\s\vnext\Microsoft.ReactNative.Managed.IntegrationTests\Microsoft.ReactNative.Managed.IntegrationTests.csproj : error NU1004: The project Microsoft.ReactNative has no compatible target framework. The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file. [D:\a\_work\1\s\vnext\Microsoft.ReactNative.sln]
This is a bug in VS/NuGet. Related issues/comments:
- https://github.com/NuGet/Home/issues/12010
- https://github.com/NuGet/Home/issues/10511#issuecomment-778400668
- https://github.com/dotnet/project-system/issues/2491#issuecomment-1020163199
So we're stuck in a spot where we have to force the evaluation on every restore, even if everything is correct and we're happy with the state of our lock files.
Is this something you are going to look at @jonthysell or should @JunielKatarn look into it?
This is technically important, but we can't really implement this without ONE of the following:
Putting this on the backlog until we get some kind of alert.
Problem Description
The whole point of using (NuGet) dependency lock files is to ensure reliable builds by locking to the dependencies in the lock file.
However, we let the PR/CI re-evaluate the dependencies at build time, which is a big no-no. Worst case scenario we download and use a hijacked dependency package, ignoring that the version/hash doesn't match what's in our (trusted) lock file.
Steps To Reproduce
See PR/CI issues such as #11998 for examples of PR/CI using dependencies we didn't expect.
Expected Results
No response
CLI version
npx react-native -v
Environment
Target Platform Version
None
Target Device(s)
Desktop
Visual Studio Version
Visual Studio 2022
Build Configuration
None
Snack, code example, screenshot, or link to a repository
No response