Visual Studio flaws while starting a project?

[ic2]

I assume these are again several Visual Studio flaws which while starting a project but I hope I am missing something.

I create a new project in VS which default says: WpfApplication1, both for Name and Solution name.
I change that to MyProject and I change path to d:xSharpProjectsMyProject

This has 2 consequences:

1 The sln is created under D:XSharpProjectsMyProjectMyProject which contains another directory MyProject that contains the actual program data. I now close VS and move this up one level. Can't I just prevent that?
2 My prg and XAML files are called WPFWindow1.xaml.prg. Why does VS not call this 'MyProject'? I can change it in the Solution Explorer but after that I still have to change it in one or more places in the program. E.g. in the top of the XAM it still says <Window x:Class="MyProject.WPFWindow1" Can't I indicate the desired prg name directly somehow?

Dick

[TerryB1]

Hi Dick

If there are flaws in Visual Studio I've yet to find them.

What you've said is happening is just what I would expect.

Your solution Name and Directory can be anything you like.

You can change the name of anything listed in solution explorer by right clicking on the required entry and selecting rename.



But having said that I would advise you to be a bit careful. If you don't you'll find yourself in a muddle, messing with project files and so forth.

The VS file structuring/naming is flexible in the extreme, and VS itself handles it well if left alone!

The penalty for fiddling is that if you want/need to tie it all up with directory names, you may find yourself having to amend things all over the place.

It is all working towards a more modular approach to program build/construction found with Net Core.

I try to keep the naming of my directories/structures in sync as far as possible with folders etc. introduced in VS - it's much easier to follow.

Terry

[Chris]

Hi Dick,

1-> When you create a new project/solution, there's a checkbox to the right of the "Solution name" box, which is labeled "Create directory for solution". You can use that to either put the project in a subdirectory or not.

2-> That's because the template of the WPF app includes a standard WPF window already, guess we should also include an "empty" WPF project template. Anyway, what you can do is (the easiest way) completely delete the window in the Solution Explorer (the base node), then add a new WPF window with the name you want.

Chris

[Phil Hepburn]

Hi Terry,

I totally agree.

Put in my layman's terms - don't mess with it (VS being it). Leave it alone.

I suggest (and do myself) let VS do all the managing of folders and files (and projects) via the SE pane. Only work in the SE pane and "NEVER" go to the 'File Explorer' and have a hack at things there. Leave the Manager to manage.

To be honest, I even let the VS 'system' place all my new solutions (containing projects) in the Documents folder - and there are separate ones (folders) for each version of VS.

I gave up trying to 'force my way' on VS years ago, and glad I did too.

Things just seem to work this way.

I have not found any VS issues either. And I have use drag an drop with SE panes quite a lot too - still OK.

The reason Dick got a MyProject/MyProject folder structure is because he called the solution and the first project both "MyProject". Neither of these should be removed.

In my attached file we can see a similar situation with "WpfDXgoGO" but it is easier to spot because there are a couple more differently named projects as well.

Here is the SE pane :-

SEpaneMagic_01.jpg (30.16 KiB) Viewed 660 times

and now the File Explorer view :-

SEpaneMagic_02.jpg (62.76 KiB) Viewed 660 times

Now then Dick, the extra two folders in FE and not SE pane, are because through the SE pane I chose to remove/delete them BUT when offer a dialog to say remove from disc permanently? I said no. I think ;-0)

The images may help you. Oh! and in the top level folder (solution folder) we have a '.sln. file for VS, and in each of the sub-folders (projects) we have an '.xsproj' or 'csproj' file depending on t he flavour of your code. So even if you name two 'MyProject' folders, we MUST still have a parent Solution folder AND a child Project folder.

HTH,
Phil.
Wales, UK.

[Phil Hepburn]

Sorry guys,

This further image may interest you :-

SEpaneMagic_03.jpg (53.03 KiB) Viewed 660 times

These are all default folders place in Documents by the Microsoft defaults etc..

Note it goes from October 2012 up to today, and these at modified dates, so the projects will go back much further.

HTH,

Phil.

[Phil Hepburn]

Chris,

In fact there are only a couple of places that needs the name editing from WPFWindow1 to the users choice. It can be done quite easily, even without an empty template.

I put this in my XAML/WPF eNotes ages ago - BUT - folks don't read them ;-0)

I will give this a go and post back here.

By the way I feel/think it is the same with C# too - again I will cross-check.

Cheers,
Phil.

[ic2]

Hello Chris,

Thanks all reacting.The solution to my problem comes from Chris:

So simple and very effective. Not sure what the logic is of 3 levels of directories - are you really expecting that Terry? I find the 2 levels I got now already 1 too many but here I agree with Phil - trying to clean the mess VS creates is not without risk. But simply deleting the WPF window created and creating a new one with the desired name solved the problem - well almost. The program doesn't run, of course no visual clue (why don't they call it No Visual Studio?) because it stops att the app:Run() which you only see in debug mode. And there I found that some of the humbug produced by VS, a file called App.g.prg, in the Debug directory, still had this:

SELF:StartupUri := System.Uri{"WPFWindow1.xaml", System.UriKind.Relative}

I changed it to SELF:StartupUri := System.Uri{"MailReaderWindow.xaml", System.UriKind.Relative} and then my converted X# project

So in short, I converted this Vulcan program to X# and it seems to work fine.

Now I'll prepare my notes for Wolfgang's WIki.

Dick

[robert]

Dick,

The extra folder under the solution is indeed not needed for solutions with a single project. Those are very rare to my experience.

I find that in almost all solutions that I work on there is more than one project in a solution. And there it is a good idea to have a solution folder and separate (child) project folders.

When that happens, I usually create an output folder at the solution level for debug and release builds and set the output folders for all projects to $(Solutiondir)$(Configuration). That way all build put their output in a common folder so less file copying is needed and builds are usually a little faster.

As intermediate output folder I usually choose a folder with a name like
$(Solutiondir)Intermediate$(ProjectName)$(Configuration).
That way all intermediate files are in one folder under the solution and can be deleted with a simple single folder deletion, so you can be sure that all 'garbage' is gone and a new build will rebuild everything.

Robert

[FFF]

...I put this in my XAML/WPF eNotes ages ago - BUT - folks don't read them ;-0) ...

Phil,
i know you'll hate me (again) for this :dry: , but you might give some thought, WHY this is so.

IMHO you have a base problem with your notes - the conflict between a "diary" for your own reference, the real "reference role" and the teaching part for us outsiders.

I consider my (reading) skills of english rather ok, but i see me to often start and then drop out, because it is simply too much text with too much "noise" around. Yes, you might rightly argue, that we have to invest more effort and time, but it is hard to justify if all i need NOW (and the next deadline is waiting) is some special trick...

So, to make your commendable effort still more of a success, i'd like to see:
a) sort of a marker / search list or similiar, to see which nodes in your structure contain more than "TBD" ,
b) a way to see "what's new" since the last update,
c) give any page you write a final "check", trying to shorten it to the utmost (might easily be the most work...)

Kindest regards
Karl

[TerryB1]

Hi Dick

I think Robert has probably answered your question - why so many directories?

Terry