Project System: Allow editing the project file without unloading

[davkean]

From @davkean on March 24, 2016 17:25

Related UserVoice: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2654545-don-t-close-all-files-when-a-project-file-is-edite

Currently we force you to reload a project when you want to edit it or it changes on disk. We shouldn't require that, we should let you edit it via a gesture (such as Edit on project context menu) and we should be smarter when it changes on disk, to only load the diffs - especially if it's only the addition of files.

Copied from original issue: dotnet/roslyn#10065

[davkean]

From @shaggygi on May 3, 2016 10:56

Looking forward to this feature :smile:

[davkean]

From @thecodejunkie on May 11, 2016 7:54

I have to say that this is an absolute must and has been one of the real strengths of project.json .. it's changed my workflow quite a lot and speed it up. I don't want to use clunky UI tools to set basic project properties and bring in references etc.. the auto complete support for project.json was great

[davkean]

From @Yantrio on May 11, 2016 8:33

I have some concern with the original wording of the issue, I feel that the project file shouldn't have to be edited via a gesture at all, the project.json project system allowed us to edit the file directly, and the current csproj system requires us (in visual studio) to unload to edit, or use "gestures".

Would it be possible to introduce a system where we don't have to unload or go through a GUI to edit the project file?

[davkean]

The wording was written before the xproj -> csproj merge. Based on recent developments we'll make sure we bring/develop a somewhat similar experience to what you have in xproj, we're open to ideas if you have any.

[davkean]

From @Yantrio on May 11, 2016 8:44

Okay, I will await the discussion to come once the design has been fleshed out a bit post-merge announcement.

[davkean]

Spent some time thinking about this, and there's a couple of different approaches we can take here - with varying costs:

1. Open the project file simply as XML language service that on save/focus loss, we blast over the in-memory MSBuild project that CPS has behind the scenes. We then rely on CPS's diff'ing logic to publish this to the visual tree, language service, etc.
   • Definitely the simplest approach, and can get this up and running very quickly
   • As only one component can write to the MSBuild model at a time, do we take the write lock for the entire editing session to prevent conflicts?
   • Solution Explorer, tree, etc would only get updated on save/focus lost
2. Open the project file with a full blown MSBuild language service similar to what Roslyn does that manipulates the MSBuild project that CPS has behind the scenes. This gets published via normal mechanisms to the visual tree, language service.
   • Extremely expensive to implement
   • Only need to take write lock as we manipulate tree
   • Instant update, adding a file for example, would cause it to immediately get published to both language service, Solution Explorer, etc

In both cases there's a few issues to figure out/fix:

• The shell has a explicit block that prevents you opening a project in an editor (see CVsUIShellOpenDocument::OpenStandardEditor)
• What do you do when the project file has errors and you attempt push to the in-memory MSBuild project? Maybe only push if it's valid?

As far as UI gesture to open the project via, prototyped this a bit, by showing the project file as an item in the tree, that you can double-click to Open:

Another option might be to add a gesture for the "App Designer" to switch to the editor ("View Code" like WinForms/XAML), and then just remember what you last selected (kind of a like Open With -> Set As Default for files).

[clairernovotny]

@davkean I want the Mercedes!

That said, if option 1 can be done quickly while option 2 is done as well as a future update, that'd be nice. Relying on focus seems really nasty and doesn't have the same responsiveness that everyone has come to expect.

[davkean]

@onovotny Update on focus lost is a pretty typical workflow for lots of editors including WinForms and XAML.

[clairernovotny]

I think there's something different about editing a project file though. I'd expect to see the solution explorer update pretty much in real-time (assuming the file is valid).

[khellang]

What @onovotny said :wink:

[davkean]

xproj's project.json only updates on Save.

I'm not yet convinced that dramatically changing the Solution Explorer as you type is going to have the benefit that you think it will. If it continues raining in Seattle this weekend, I'll see if I can prototype this, otherwise, I'm going outside to build my deck. :)

[clairernovotny]

I think updating on save is okay...but that doesn't seem to have anything to do with focus :)

[davkean]

The way WinForms, XAML (code behind), Resources Editor, etc work - they update on focus switch, then you can just blow away the unsaved changes in the editor with the current world when you switch back to the editor. It's such a simpler model.

[davkean]

But in saying that, maybe a visible thing like Solution Explorer, this might be a little strange. Either way - the invalid cases worry me the most, last thing you want to do is enter invalid XML, Save and then your entire project fails to load.

[clairernovotny]

What if you keep a "last known good" shadow project file? It could load that if the XML is invalid with a big fat warning/error to the user?

[clairernovotny]

With the solution explorer, you can't really just blow it away like you can with designers. At the very least, you need to keep state of the expandos, to see what folders are open, what the active highlighted file is, etc.

Also, don't forget that a user might be editing the project file outside of VS and expect that VS updates automatically and seamlessly when they save the file.

[davkean]

Due to the way CPS works, the state of the tree will be preserved when you write to the in-memory MSBuild project.

I'm going to treat editing outside of VS as a separate problem - different work has to occur to make that happen. I'll file a new bug for that.

[asbjornu]

@davkean:

The way WinForms, XAML (code behind), Resources Editor, etc work - they update on focus switch, then you can just blow away the unsaved changes in the editor with the current world when you switch back to the editor. It's such a simpler model.

Sorry, but it's not a simple model. It's an ugly hack.

The idea that there's a huge, valuable difference between in-memory changes to a file and how the file looks like on disk is the source of one gazillion bugs in Visual Studio today. That's at least my understanding and experience of the bugs I've encountered around Visual Studio not behaving according to what's stored on disk, because it has some other "truth" about the world.

If you want something persisted, save the file. Saving the file should obviously update whatever is dependent on the file, such as the Solution Explorer's dependency on .csproj. Not having to save to see the update and instead using focus/blur as a temporary scratch pad is nothing but poor UX and a hack.

If you save something to disk and want to revert it, you use source control. If people still want to use Visual Studio or any code editor today without source control, their life should be made harder so their incentive to start using source control increases. Their buggy edge-case of a development experience should in no way be catered to. In my humble opinion, of course.

And I agree with @onovotny. Do option 1 first, then build the Mercedes. :blue_car: :moneybag: :smile:

[davkean]

You can call it poor UX or a hack, but that's not how VS works. :)

Here's some examples:

1. I can add an API to a type, and immediately consume it in another project without saving/building
2. I can make a change to the project via project properties UI (say conditional compilation symbol), and it is immediately applied to the in-memory project without saving
3. I can drag a control onto a XAML designer, switch to code behind and immediately start consuming
4. I can add a resource to the resource editor, switch to code and immediately start consuming

None of these are required to be committed to disk for them to take effect. Until we change the commit model across VS to be immediate save - we should play nicely with the rules of VS.

If we don't try to apply the changes at some point without saving, conflicts really worry me the most:

1. I'm editing the project file via the editor
2. I leave unsaved changes and switch to do something else
3. Either I or something in the system, changes the project (say by adding a file)

Without the Mercedes approach, we now have conflicts - we now have to rationalize the changes we have in the editor buffer with the changes we have in the in-memory model of project. :(

Anyway, I'm going to hold judgement until I've actually started playing around with this - which I think will help me give a better understanding of the right place to "commit".

[asbjornu]

None of these are required to be committed to disk for them to take effect.

Yea. And therein lies the problem.

Until we change the commit model across VS to be immediate save - we should play nicely with the rules of VS.

Understood. And I believe the commit model across VS should be changed. That's perhaps not a very helpful thing to write since it's most likely way out of scope for this entire repository, but I'm a strong believer in fixing underlying problems instead of patching symptoms. :smiley:

I'm looking forward to hearing the temperature from you getting your feet wet with this challenge, @davkean! And I really appreciate the discussion. Thanks!

[swythan]

Another related UserVoice issue: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2033421-allow-a-project-file-to-be-edited-without-

Weirdly someone just closed it saying there were no plans to support this in VS 15!

[davkean]

Thanks @swythan, bit of a communication issue. Looking into it...

[srivatsn]

Basic editing and saving of project files is working now. #673 tracks some further work to sync the project state with the file.