As you know I have been doing Forum related work with a Virtual Machine and a clean installation of VS 2017 and related software, latest X# as well. Things have gone quite well.
However, I have noticed a couple of things which I feel I should report back to you - one is more of a "show stopper" than the other.
First the lesser problem :- If I add a new folder to my project (in the SE pane) and then decide to delete (remove) it, all seems well and it goes from the SE pane. However, if I then try to add the same (named) folder back again, I get a message from the VS system saying that the folder already exists. Looking with 'File Explorer' it certainly still exists in the project folder on disk.
I know the above situation is a bit odd - BUT - it does look as if Delete does a 'soft' remove but NOT a 'hard' remove. Meaning the solution/project appears not to have it BUT the file system does know about it. I hit this issue yesterday, survived by fiddling!
Secondly, the more difficult to get around problem / issue. Yesterday I was trying to add a 'Click' event to a Button in my WPF form - see below :-
The XAML text editor and the whole of the VS IDE seems to lock up, and I have to use task manager to close VS, and any recent changes are lost. It locks forever it would seem :-
This is a bit of a show stopper for new guys to VS, WPF and X#. I have a way around this BUT ;-0((
I write a comment line in XAML in which I embed the whole new 'Click' text - then copy and paste it into the attributes list for the Button. It does not appear to need the event handler to be there first, before the text 'fiddle', but I feel/think/remember I usually do make the code method before pasting.
In earlier VS integrations this Click event entry did nothing behind the scenes but did not lock, and later ones (integrations) introduced this effect - it appears still to be there.
It would also appear as if the system behind the XAML editing (a parser plus?) is trying to insert .NET code of X# syntax to create a stub for the event handler. And somewhere along the line it is hitting a brick wall.
This is rather critical and crucial for WPF work so it may be good to put it as high up the list of 'to dos' as possible ;-0) MVVM does not do events like this but everything else non-MVVM does.
The crash in the XAML editor has been identified and fixed.
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 ?
XSharp Development Team
You and the Team are most welcome - I will continue to keep a look out for the odd thing here and there that seems not to be right. I will try and play my small part, as you and the others are doing all the big and hard work ;-0)
I have to say that most stuff seems to work very well indeed - well done Team !!!
As promised I have done some testing with a C# project in VS 2017 - and - it is as I had assumed, the delete from the Solution Explorer pane does actually remove physically the folder and any files from the hard disk. Like as if we are using File Explorer.
Yes, it does give you a chance to Cancel, but it does NOT leave stuff on disk when it is removed from the SE pane.
I would vote to have our X# behaviour as like that of C# please.
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.
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...
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 :-
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.
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?
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 !!!
"...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.
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).