Visual Studio 2017 with Beta 11 - some issues to report >

[FFF]

Robert,
better than C#, but risky, and, sorry, not really comfortable
There are folks who routinely empty their bin...

BTW, how do you think, the "rescue" should work? Re-instate a file to a folder, which possibly does not exist anymore? Or, recreate the folder from bin, but then you have ALL files again in...

[Phil Hepburn]

Hi Robert (Karl and others),

Thanks, that seems to fall in line with the operation of the VS environment for other languages in VS 2017.

Karl and others, it is not that we are copying C# or that what it does is the Holy Grail, or the smartest thing around - BUT - that for guys like me who move between projects in the VS IDE shell we need some consistency, so that using VS is as easy as it can be.

At the moment I think there is an inconsistency between single and double clicks of items in the S.E. pane - this becomes hard work when translating manually C# to X#.

However, in the X# compiler 'stuff' - get as smart as you like ;-0) That is different.

Thanks and my 10c worth,
Phil.

[FFF]

AFAIK, here we talked about deleting/removing things, no clicks

And, if R. follows my wish, where's your problem?
Delete a C# folder, all is gone;
Delete a X# folder, and you get asked what to do, IF, and only if it contains detached files which you probably hadn't realised they would be lost...

[Phil Hepburn]

Karl,

Please do remember that many guys coding in VS these days do so with the full use and support of 'Team Explorer' (was Team Foundation Server) and there are GIT options too, and the Cloud.

So VS users should 'Commit' changes to the server on a regular basis, very regular. Any problems and we can then restore the solution to a previous state.

In other words we should use the tools provided and not be so guarded when it comes to basic functionality of 'add and remove' in the SE pane - which should mean just that.

If you are not using 'Team Server' then I recommend it - I was a convert after I lost 3.5 hours of heavy coding back in the old days - I just went for it after that. And these days it is much easier to use the Team Server facility.

I attach a couple of images (just for a flavour) of my developing EF6 solution I am creating for Forum Pearls :-

TeamServer_01.jpg (52.16 KiB) Viewed 432 times

TeamServer_02.jpg (55.45 KiB) Viewed 432 times

Here are a couple more for you to get the feeling of what is on offer - my app is small and new so there are only a handful (5 ?) changes so far.

TeamServer_03.jpg (66.45 KiB) Viewed 432 times

TeamServer_04.jpg (70.25 KiB) Viewed 432 times

Hope this interests a few,
Phil.
Wales, UK.

[FFF]

Holy sh.. Phil,
i asked for a dialog form with some lines to move some files to another place.
Why are you so damn "guarded" if one wants some simple func without the need to invest the next week to understand it?

[Phil Hepburn]

Karl,

Calm down ;-0)

The point you may have missed is that some guys may have their SE pane contents managed by the built-in tool(s). So we can't have more than one management system changing out SE pane contents.

It just looked to me like we were discussing re-inventing the wheel, again.
We need to thing carefully about what we do, that was my message.
I don't want my VS environment moving files around with dialogs etc.

Enormous thunder storms while I create and write this, so you may not get it, or a lot of water !!!

My 13c worth,
Phil.

[FFF]

Phil,
<sigh>.

a) Nobody asked about another management of the content of the SE pane. I asked for a convenient way to manage possible loss of data.

b) "some guys" might use some internal tools. So what? Because they do, we all have to? Because they do, no other functionality may be added to VS? Why? Because VS breaks then? C'mon.

c) "the environment moves your files" - it shouldn't DELETE files without asking me - and if i deny, an easy option to move them to a place -where I want them to be- may come handy, no?

Thunderstorm didn't stop me reading all of your post, "our's" seems to have lost steam

[robert]

Karl,

When you delete a file or folder in VS you will see a confirmation dialog.
After you select Ok, then the (changed) X# project system will move the selected item to the trash can.

I think that behavior is exactly what you would expect.
And yes, if you empty the trash can then it will be gone "forever".
That is exactly what you would expect as well.

Of course it always helps to have backups or source code control...

Discussion closed for me.

Robert

[FFF]

Robert,
you wrote:
"...W.r.t. deleting folders: there could be more files in a folder than you are seeing in the project inside Solution Explorer (so called "excluded files").
What would you expect: should the folder be deleted if the folder contains files that are not part of the project ?..."

These "invisible" files started my interest in this thing. If your confirmation dialog let's handle them separated from the "included" parts, all is fine. If not, from the reactions i get, it seems, neither you nor Phil understood my concern.

[wriedmann]

Hi Karl,

I think, I understand your concerns, but personally I think that when the user decides to delete a folder, it should be really deleted with all contents. Even the Windows Explorer does this.
And I don't think it is not a good idea to keep files in the VS project structure - files that are not visible to Visual Studio itself.

Personally I'm using XIDE, and I have learned to add all files of my project (i.e. all files that are in the project structure) also to the XIDE project.

Of course, coming from the repository based VO, we tend to see things differently than guys that don't know it. But a regular backup keeps you safe... (my XIDE makes an automatic export to another disk every 30 minutes, as also VO AutoExport does).

Wolfgang