make copying of files windows localization agnostic

[hvoigt]

On a german Windows when building I get the following error:

(D = Datei, V = Verzeichnis)? Ist das Ziel ...\Terminal\x64\Debug\TerminalSettings.pdb ein Dateiname
oder ein Verzeichnisname
(D = Datei, V = Verzeichnis)? f

The trick with piping 'f' for folder into stdin does not work here, since in
german folder is called 'Verzeichnis'. Due to the fact that the UI is
translated a 'v' is expected.

Lets use plain 'copy' which does not have the problem of asking whether a
target is a folder, if the target does not exist.

NOTE: I discovered this because the xcopy in src/cppwinrt.build.post.props failed for x64. The other locations I just applied the same pattern and did not test, since I do not know the code base that thoroughly. But if one location works the others should be fine, right? ;) Please test if this also works for others.

[msftclas]

All CLA requirements met.

[zadjii-msft]

This will fix #507

[hvoigt]

Wait I just discovered there is a little more stuff needed, since copy does not create directories. I will rename the PR to WIP.

Needs to handle creating dirs

[mKay00]

I just tried it with robocopy, which can't rename a file when copying, so the best way I found to solve this is to use xcopy with a workaround I found on stackoverflow: https://stackoverflow.com/a/14022309/5899174

Since I don't know what the best way to share my solution is, I just pushed the commit to my fork and paste the link here.
mKay00@08e6039

[DHowett-MSFT]

Since it's difficult to get xcopy to do the right thing, should we just switch to the Copy or CopyFiles MSBuild tasks? It'll get proper dependency resolution going, and only copy files if they've changed, which should also reduce the number of rebuilds we suffer.

I realize this won't help the batch files. 😄

[hvoigt]

Since none of the copy lines modify the filename, my next approach would be to switch back to xcopy with directories as targets and backslash at the end. IIRC that should suppress the folder question. I was not able to test that properly yet, so I did not update the PR yet.

Will take a couple hours for me to get back to this though.

Getting rid of xcopy is of course always appreciated. We can then just fix the leftovers with my approach.

[mKay00]

There are copy lines that modify the filename (e.g. (copy /Y %_last_build%\OpenConsole.exe %TEMP%%copy_dir%\conhost.exe) > nul)
This is the reason I didn't use robocopy and copy can't create directories, thus my approach with xcopy and the workaround. I also tried robocopy and replaced the renaming lines with copy, but then the build failed and only worked the third time I clicked on build.

[DHowett-MSFT]

The props changes were merged in as part of #847. This pull request is still useful for the cmd and ps1 files!

[hvoigt]

Sorry I was not able to look into this until now. I just pushed an updated version. For me the open... commands were failing without this.

I could not test two commands:

• openterm
• opencas

It seems their targets (CascadiaWin32.exe, cascadia.exe) are not build as part of bcz or their output filename changed?

Since there is no testsuite for this. Please also test on other systems.

[zadjii-msft]

Ah, you're okay not testing those. I didn't realize opencas even got checked in, it's fundamentally the same as openterm. Additionally, we broke them some time ago, and I don't think we really have a plan for fixing them. You're right that CascadiaWin32.exe doesn't exist anymore, it's been renamed to WindowsTerminal.exe

[hvoigt]

Ah, you're okay not testing those. I didn't realize opencas even got checked in, it's fundamentally the same as openterm. Additionally, we broke them some time ago, and I don't think we really have a plan for fixing them. You're right that CascadiaWin32.exe doesn't exist anymore, it's been renamed to WindowsTerminal.exe

How about I add a cleanup commit before mine to fix that? Will remove opencas.cmd and fix the filename.

How are you running the terminal usually just through Visual Studio?

[hvoigt]

BTW, what about these CI failures? I am not changing anything related to them am I? Are those also failing on master?

[zadjii-msft]

@hvoigt sure, that's fine with me. I'm just using VS now. We used to support unpackaged activation of the app, so I did everything with openterm. However, like a month ago we took a dependency on something that broke unpackaged activation, so I've been in VS ever since.

As far as the CI failures - that happens really rarely with a couple of our tests, I think you just got unlucky. @miniksa should take a look and confirm, I think that's one of his tests.

[hvoigt]

@hvoigt sure, that's fine with me. I'm just using VS now. We used to support unpackaged activation of the app, so I did everything with openterm. However, like a month ago we took a dependency on something that broke unpackaged activation, so I've been in VS ever since.

What does "unpackaged activation" mean? Can we include the "packaging" using the cmd file? I changed the cmd file so now it will run the right executeable again, but as you mentioned the terminal does error out early. If we can not fix this the maybe the file should also be removed.

As far as the CI failures - that happens really rarely with a couple of our tests, I think you just got unlucky. @miniksa should take a look and confirm, I think that's one of his tests.

Lets see what this run does.

[hvoigt]

[...] I don't think we really have a plan for fixing them. [...]

Just reread this. To get this PR done: Removed the openterm command in another commit. This way the "fixed" state is in the history in case anyone wants to revive them.

[zadjii-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[zadjii-msft]

@hvoigt "Unpackaged Activation" means running the app from outside the context of a application package. That means launching WindowsTerminal.exe directly. This used to work, so long as all the dependent dlls where adjacent to the exe and all our winrt types were registered in our manifest.

However, since that broke, you need to build the appx/msix package and install that instead.

[hvoigt]

Since it should be ready.

[ghost]

Hello @miniksa!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me and give me an instruction to get started! Learn more here.

[miniksa]

@msftbot make sure @DHowett-MSFT signs off

[ghost]

Hello @miniksa!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I'll only merge this pull request if it's approved by @DHowett-MSFT

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

[DHowett-MSFT]

Thanks!