We need a setting to define the what double clicking project does

[sharwell]

Version: 16.0 Preview 2

Steps to reproduce:

1. Open a solution with a CPS-based C# project
2. Double click to expand the project in Solution Explorer.

Expected results:

The project expands in Solution Explorer.

Actual results:

The project does not expand in Solution Explorer, and instead the project opens.

📝 I was aware of the behavior change but avoided filing this issue until I actually hit it by accident. It happened within 5 minutes of installing Preview 2.

[aaubry]

Well, I do. Basically one command (double-clicking on the project) results in two actions, expand the project AND open the project for editing. It's not that I can't live with it, but it feels even weirder than only opening the project. It is rare that I need to edit a project manually. Maybe once in a while to set LangVersion. Other than that I don't see many use cases for it. Why would I want to be constantly opening it ?

[stefankip]

Just disable the preview window. It's no good at all anyway :-)

[mchudinov]

Make this "feature" disabled by default please.

[StingyJack]

@drewnoakes - why did inconsistency get chosen as the default?

[davkean]

Its inconsistent with some things but consistent with all other files and the direction we want to head; project files are user-editable similar to source code. The option is there for folks that want to switch on the old behavior, it roams with your profile so you will never ever need to set it again.

[StingyJack]

I dont like that direction. Not because its different, but because I dont want to have to think about editing project files in the first place. Proj files been working just fine for the most part, and I've only had to edit them to add odd build configurations or to remove elements added due to bugs in VS or package uninstallation. There is nothing in these project files anymore really, so nothing to see on that double click except annoyance at this inconsistent behavior.

Why is it so important to push staring at project files into the way of the general user? This just adds needless clicks to close the proj file and click the ever shrinking expand icon.

(What I really need is the option to not use this inferred content project file format, its a PITA for several reasons)

[StingyJack]

Also does this mean that eventually when I double click on other expandable items like folders that i'm going to get a filesystem properties dialog for the folder?

Part of our rationale for shipping this feature, and the rest of project file editing improvements, in a preview release was to gauge the response from our users before the final release. Please keep us updated if your opinion changes at all as you use the preview more and potentially get used to the new experience.

VS 2017 cured me from ever taking a preview release again (and almost from using VS entirely), and I know I'm not alone in that regard. Take care to measure that preview release feedback for what it is and that is is not necessarily representative of the general audience.

[cartermp]

@StingyJack Note that this:

not necessarily representative of the general audience

Is 100% true 🙂. In fact, we've seen a lot of positive reception over making these files easier to edit, especially now that with SDK-style projects, it's possible to edit these files without having to sift through potentially thousands of seemingly unrelated MSBuild XML.

So, which do we trust more: a GitHub issue, or a channel for the product designed to gauge feedback? Hence the option in the settings.

[cjbush]

I'm not a big fan of this feature either, and I thank the team for adding the checkbox to turn it off, but I honestly don't understand the harsh vitriol some people are expressing over it. It's a checkbox you uncheck once and then your settings are synced to your account forever. I unchecked it weeks ago and moved on with my life.

[aaubry]

@cjbush I think the reason for the criticism is that the checkbox to disable it was inexistent at first. When people are used to a behavior and it suddenly changes without a way to revert, that's when people get annoyed. Of course they can't add settings to control everything, so it is to be expected that sometimes people get annoyed.

[StingyJack]

@cjbush - the criticism from me is about the direction(s). Something that was a "just works" or "no think" a few years ago is soon to be no longer available, replaced by something that requires more effort (ex: running a netcore console app vs netfx, anything dealing with devops build tasks, figuring out where the compiled output is going to end up) on my part to get the same result, something that falls wildly short feature-wise to it's predecessor or has needless restrictions (nuget package reference style) that I've now got to spend time to cover gaps , or that is just not getting carried forward due to a Shiny Things affectation (unshelve to a different branch).

The last 3-4 years of output from a software tools vendor I've used for 30 years has been riddled with thousands of these little (and sometimes not little) impediments.

I can't count how many times this specific interruption-by-design broke my flow. I saw it happening countless times to co-workers too.

We don't need designs that create interruptions, unless that interruption is important. Showing me a proj file, when I already know to right click if I want to edit it is not important.

[drewnoakes]

@StingyJack I interpret part of what you're saying (the more general part, less around this particular issue) as being a frustration with the rapid changes to platform and tooling that have been going on over the last years. I can see why you'd feel that way. .NET Framework was very stable for a long while and during that time the tooling matured, however the platform started to show its signs of age.

Since .NET Core we've had an incredible amount of progress across the entire stack, which is great for the long term health of .NET (and our careers as .NET developers), however the tooling is playing catch up to get to that previous level of maturity. These changes have forced us developers to learn new concepts and unlearn old behaviours. Patterns we've known and used for a long time (e.g. output paths) have had to change as new concepts (e.g. multi-targeting) have been introduced. This isn't change for change's sake -- it's unavoidable if we want to progress and grow the platform.

As for your particular preference on this issue, I don't think there's much more I can add here.

I can't count how many times this specific interruption-by-design broke my flow.

Have you not unchecked the option?

[StingyJack]

Have you not unchecked the option?

@drewnoakes - The option wasn't there until recently, and I came across this quite by happy accident. Its now set to just expand or collapse the projects for me (at least until the next bug that loses my settings).

Your problem though (not mine now), is that you guys made the new and interrupting behavior the default, so there are probably quite a few - lets just say most - VS .net developers at least scratching their head and thinking "why does this do this now" at varying degrees of exasperation while trying to partially unlearn a conditioned behavior. I would think telemetry would be available to support or dispute this, or at least I hope so.

Its not like its an easy setting to find.

as being a frustration with the rapid changes to platform and tooling ...

No no, not upset about speed of changes. MSFT has been making things that do not materially improve on prior creations or that improvement holds little value or that serve some FOTM. And then coercing me to use that in one way or another, often times by declaring "no longer supported". This is usually the point of frustration. This "feature" is a smaller example; assumption riddled and hidden default heavy proj files and nuget package reference are larger examples.

Some of this frustration could be abated if I understood that it was a transition step to something better but I don't see anyone explaining what that "better" is. I've re-read both your and @davkean's responses again and neither have given a reason for the proj file opening change, so I'm asking again: Why was this important enough to interrupt development workflow?

new concepts (e.g. multi-targeting)

This was always do-able in .netfx and fairly easy to do by creating a build configuration for it.

[davkean]

Going to lock this thread, I don't think its productive to discuss the same thing over and over again. The original request has been resolved, the setting is permanent, once set you should never have to think about it again.