The Solution Explorer lacks any kind of context to display files that may be selectively included by conditions.
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).
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.
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:
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.
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.
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.
That definitely sounds like the experience I want someday.
Thanks for the explanation @davkean. I would agree that we need all of the features to be multi-TFM aware, especially unit tests :)
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.