Playgroud-composition.sln produces a build error

[TatianaKapos]

Problem Description

Running playground-composition locally produces the following error, I think it's from Nuget package restore failing in VS but the app will still run fine.

While the app still works, this is confusing to see and should suppress this error or fix!

Steps To Reproduce

1. Run playground-composition.sln

Expected Results

No response

CLI version

npx @react-native-community/cli -v

Environment

npx @react-native-community/cli info

Community Modules

No response

Target Platform Version

None

Target Device(s)

No response

Visual Studio Version

None

Build Configuration

None

Snack, code example, screenshot, or link to a repository

No response

[jonthysell]

This appears to be a regression in Visual Studio as it repros for all of our solutions, not just playground. VS seems to be seeing different dependencies that what msbuild sees, but the error message is hard to parse.

Our CI is succeeding, which is where we would fail if the lock files get changed during the build (i.e. they were out of date).

[frankcalise]

Also experiencing this

 × Build failed with message 0>C:\Users\fcali\code\react-native-windows\packages\playground\windows\playground-composition.sln : Solution file error MSB5010: No file format header found.. Check your build configuration.

Tried opening the solution directly, but it says it is not a valid solution file.

[jonthysell]

VS and msbuild have never agreed on how to handle nuget restore lock files, and VS has recently changed to be worse. Since we need lock files to be compliant, the only solution is to always build with RestoreForceEvaluate=true locally.

Unfortunately, I can't seem to get msbuild or VS to actually do a forced evaluate by setting the variable within props/project files. I tried here but the error persists, even though every project evaluates the variable to true. The only way it seems to work is to literally pass a global msbuild variable, i.e. direct from the command line.

You can see here where I try to unblock the e2e-test-app by adding the --msbuildprops RestoreForceEvaluate=true to the run-windows command. That seems to be the only option of our in-repo projects right now.

Until we can find a better solution, first off, make sure you have the latest VS and reboot after if you had to update (or if you never rebooted since the last VS update). Then add --msbuildprops RestoreForceEvaluate=true to your run-windows command for in-repo projects for now.