Project Properties UI showing doubled input controls for Microsoft.VisualStudio.ProjectSystem.Managed.VS

[drewnoakes]

Visual Studio Version: main

Summary:

The UI shows doubled edit controls for selected properties.

Steps to Reproduce:

1. Open ProjectSystem.sln
2. Enable the preview flag for the new UI
3. Show the project properties for project Microsoft.VisualStudio.ProjectSystem.Managed.VS
4. Navigate to Build | Errors and warnings

Expected Behavior:

Single edit control when value does not vary by configuration.

Actual Behavior:

Doubled edit controls, despite there being no need for doubles

[drewnoakes]

@tmeschter this may be coming from the back end. These are the values received from the server (copied into a data structure verbatim from the Project Query API model types).

It shows that one configuration has an empty unevaluated value, while the other does not. I do not believe this is expected. The UI is deciding that these two values are materially different in some way, and must be presented individually.

The first is Debug|AnyCPU, the second Release|AnyCPU.

I've only seen this with the Microsoft.VisualStudio.ProjectSystem.Managed.VS project. It doesn't happen for a new .NET Console App.

[tmeschter]

Observations:

On my local system, msbuild /p:Configuration=Debug /pp Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj and msbuild /p:Configuration=Release /pp Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj produced different results. MSBuild couldn't find the NuGet-generated .props and .targets files because they didn't exist for the Release configuration. Running msbuild /t:restore /p:Configuration=Release Microsoft.VisualStudio.ProjectSystem.Managed.VS.csproj caused those files to be generated, at which point the preprocessed output was the same (other than the paths to the .props and .targets generated by NuGet), and subsequently opening the property pages no longer showed the duplicated controls.

My guess at the moment is that the missing .props/.targets somehow affects our ability to get the unevaluated value, but not the evaluated value. I will need to investigate further.

[tmeschter]

@drewnoakes I see part of what is going on here. Normally the project.assets.json file and .props/.targets generated by NuGet restore would go into <project folder>\obj. In our repo, however, they are in <repo root>\artifacts\<configuration>\obj\<project name>. We've taken files that are not normally configuration-specific, and put them in a configuration-specific location. So they are available to some configurations and not others, and this causes differences in evaluation later on.

I'm inclined to close this bug as I don't think this is a general issue, and instead open a new bug specific to the layout of intermediate files in our repo. What do you think?

[drewnoakes]

@tmeschter nice discovery. That sounds both plausible and reasonable to me.

Pinging @davkean in case he has any background context on the rationale for having the obj folder in a configuration-specific location.

[tmeschter]

Seeing as this is an oddity of how we have our repo set up, we're going to close this.

[davkean]

@drewnoakes @tmeschter Despite living in a configuration-independent location, The assets file is configuration-dependent, hence why we restore when the configuration changes.