New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solution Explorer doesn't show files conditionally included #935

Open
onovotny opened this Issue Dec 13, 2016 · 13 comments

Comments

Projects
None yet
9 participants
@onovotny
Member

onovotny commented Dec 13, 2016

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).

@srivatsn srivatsn added this to the 1.1 milestone Dec 13, 2016

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Dec 14, 2016

Member

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.

Member

dsplaisted commented Dec 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Dec 14, 2016

Member

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.

Member

davkean commented Dec 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Dec 14, 2016

Member

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.

Member

davkean commented Dec 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Dec 14, 2016

That definitely sounds like the experience I want someday.

gulbanana commented Dec 14, 2016

That definitely sounds like the experience I want someday.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Dec 14, 2016

Member

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

Member

onovotny commented Dec 14, 2016

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Dec 19, 2016

Member

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.

Member

onovotny commented Dec 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@natidea

natidea Sep 9, 2017

Contributor

Also reported on VSFeedback | 486744

Contributor

natidea commented Sep 9, 2017

Also reported on VSFeedback | 486744

@FransBouma

This comment has been minimized.

Show comment
Hide comment
@FransBouma

FransBouma Sep 9, 2017

@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.

FransBouma commented Sep 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Sep 11, 2017

Member

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 #2811 to track.

Member

davkean commented Sep 11, 2017

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 #2811 to track.

@eerhardt

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Jul 20, 2018

Member

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

Member

eerhardt commented Jul 20, 2018

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

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Jul 20, 2018

Member

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

Member

davkean commented Jul 20, 2018

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

@bartonjs

This comment has been minimized.

Show comment
Hide comment
@bartonjs

bartonjs Jul 23, 2018

Member

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.

Member

bartonjs commented Jul 23, 2018

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Aug 17, 2018

Member

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

Member

onovotny commented Aug 17, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment