Project-system: Solution Explorer doesn't show files conditionally included

[clairernovotny]

The Solution Explorer lacks any kind of context to display files that may be selectively included by conditions.

See
https://github.com/onovotny/Zeroconf/blob/f72ae4c009b540d22096b0233c75e61e6ad8fa9f/Zeroconf/Zeroconf.csproj

In that file, there are platform-specific files that are included in some cases. When open in the IDE, the IDE has the correct per-file context, but there's no way to pick them in the solution explorer.

The solution explorer should show all these files (possibly with some parenthesis that show the applied precondition).

[dsplaisted]

Possibly related: Microsoft/MSBuild#1475

I'm not exactly sure what's going on here. I thought VS would evaluate the project with ShouldEvaluateForDesignTime set to true, so that all conditioned Compile items would be shown, but that doesn't seem to be happening here. Perhaps CPS and the Roslyn based project system don't use ShouldEvaluateForDesignTime anymore, but Microsoft/MSBuild#1475 makes me think that they are.

[davkean]

The new project system currently drives the solution tree off the "active" configuration.
The old project system drives the solution tree by ignoring conditions. They both have advantages/disadvantages.

Under the covers, in the new project system we represent TFMs as simply additional traits along the same lines as _Platform_ and _Configuration_, so targeting netcoreapp1.0 and net46, results in the following configurations under the covers (for a default project):

1. Debug | AnyCPU | netcoreapp1.0
2. Release | AnyCPU | netcoreapp1.0
3. Debug | AnyCPU | net45 
4. Release | AnyCPU | net45 

The order is currently dependent on the order in which you've listed the TFMs in the project file - this is important.

We don't actually expose all of these configs to the developer, nor let them change to them all. Instead when the user changes from from Debug -> Release, really we're only switching from 1 to 2 - the user can't make "net45" part of what Visual Studio considers the "active" config, outside of physically reordering the TFMs in the project file.

We do however, make use of all the configs in the following situations:

1. IntelliSense. Controlled by "context dropdown" at the top of the Text Editor. If _Debug_ is active, drop down will show results from 1 and 3 . If _Release_ is active, results from 2 and 4 will be shown.

2. Build. If _Debug_ is active - we'll build both 1 and 3. If _Release_ is active, we'll build 2 and 4.

For our first RTM, it is likely this won't change - all other features; Test Explorer, Solution Explorer, CodeMap, Class Designer, etc will only ever see a single active config - and get results based on the first TFM in the project file.

As we ship later updates, more and more features will become aware of multiple TFMs/configs and we'll do things such as above.

[davkean]

We also considered adding another drop down, similar to Debug and Platform drops downs to let the user choose the "active" TFM (like the editor drop down but for all of VS not just the editor) - but we felt that we're better off building out the experience so that features are aware of multiple TFMs. For example, we think that devs would rather have their tests run across all platforms rather than switching between TFMs to run them. Similar to Solution Explorer, you'd rather see all your source files at once.

[gulbanana]

That definitely sounds like the experience I want someday.

[clairernovotny]

Thanks for the explanation @davkean. I would agree that we need all of the features to be multi-TFM aware, especially unit tests :)

[clairernovotny]

Found one potential workaround until this is done "the right way"

    <Compile Include="**\*.cs" Exclude="Platforms\**\*.*;Resources\**\*.cs" />
    <!-- This is here so that the conditionally included files still show up in VS -->
    <None Include="**\*.cs;**\*.xml;**\*.axml" Exclude="obj\**\*.*;bin\**\*.*" />

Then later down, under an ItemGroup that's conditioned to a TFM, I do

 <Compile Include="Platforms\iOS\**\*.cs" />

Seems to work where VS shows all the files, things all compile correctly and when I open the file in VS, it does show me the applicable contexts in the file.

[natidea]

Also reported on VSFeedback | 486744

[FransBouma]

@natidea I reported that issue, but your reply suggests there isn't actually something wrong, but as it's closed already I can't reply there, so I'll do it here: the error list in visual studio suggests the wrong TFM where the issue happened as well as it couldn't open the file. As you can't reproduce that anymore with the repro I attached to that issue, I assume it's been fixed along the way since 15.3.2? In any case, the error is always reported as being an error in the netstandard TFM in the project, but the error is in a file which is only in the .net full TFM in the project, so can never occur (and also doesn't occur) in the netstandard build. As the error list shows the error as it happened in the netstandard build, the user (in which case here was me) is confused what happened, as it's in an error in a file that's not even included in the build for that TFM.

Again, I'd have replied on the issue at vsfeedback but that's not possible anymore so I do it here as you pointed there that this issue is the duplicate.

[davkean]

The fact that it cannot be opened when you double-click the error is fallout of above - VS thinks that we own the file, but when the Error List asks us to open it we cannot find the file as it's not a part of the files that we consider part of the project.

The other bug you mentioned, I opened https://github.com/dotnet/project-system/issues/2811 to track.

[eerhardt]

Any update here? This issue has been opened for over a year. Will it be resolved in VS 2017?

[davkean]

There will not be a change in VS 2017. You can work around this by including a <None Include="*.cs"/> that includes them.

[bartonjs]

On the one hand, what the new project system is doing makes sense. On the other hand, it's a change in my workflow, and I've come to enjoy the convenience of the solution explorer and find-all searching across even the conditionally-included files.

Guess I get to add <None Include"**\*.cs" /> and <None Include="$(CommonSrc)\yadda\yadda\**\*.cs/> to all of my multi-build projects.

[clairernovotny]

@bartonjs I'm adding the workaround to the SDK Extras if you want to use that...