Move temp folder into repo to avoid state that causes build errors from time to time when rebuilding locally (and packages have updated)

[bergmeister]

Ideally, we should avoid this business and just use NuGet's global cache for that but this is a quickfix for not having to delete those folders in AppData that cause build errors when rebuilding. Now, a clean of the repo will sort this out (which is usually run when building the extension or PSES) to make those annoying local build errors disappear

[corbob]

Should this new temp directory be added to the .gitignore?

[rjmholt]

@bergmeister Would you be able to give a quick description of the kind of errors you're seeing?

[bergmeister]

I have not recorded it but it should be somewhere in the Slack channel, multiple other people have experienced it as well where they had to delete those packages folders created by the build in the temp appdata folder.

[rkeithhill]

I occasionally get build failures that require me to remove the NuGet packages from some folder in my AppData directory before the build will succeed.

[corbob]

Here is (hopefully) relevant discussion from Discord/Slack when I encountered the error:

The error:

ERROR: Cannot find path 'C:\Users\corbob\AppData\Local\Temp\System.Security.Principal.Windows.4.5.0\runtimes\win\lib\netcoreapp2.0\System.Security.Principal.Windows.dll' because it does not exist.
At C:\Users\corbob\repos\PowerShellEditorServices\PowerShellEditorServices.build.ps1:163 char:5
+     Copy-Item -Path $internalPath -Destination $DestinationPath -Forc ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At C:\Users\corbob\repos\PowerShellEditorServices\PowerShellEditorServices.build.ps1:403 char:1
+ task LayoutModule -After Build {
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At C:\Users\corbob\repos\PowerShellEditorServices\PowerShellEditorServices.build.ps1:327 char:1
+ task Build {
+ ~~~~~~~~~~~~
Build FAILED. 4 tasks, 1 errors, 0 warnings 00:00:09.9432025
Copy-Item : Cannot find path 'C:\Users\corbob\AppData\Local\Temp\System.Security.Principal.Windows.4.5.0\runtimes\win\lib\netcoreapp2.0\System.Security.Principal.Windows.dll' because it does not exist.
At C:\Users\corbob\repos\PowerShellEditorServices\PowerShellEditorServices.build.ps1:163 char:5
+     Copy-Item -Path $internalPath -Destination $DestinationPath -Forc ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (C:\Users\corbob...pal.Windows.dll:String) [Copy-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand

And a link if you have Discord

[rjmholt]

Sucks that the .NET API is giving us such a dud folder. I'd hope a solution to PowerShell/PowerShell#4216 doesn't have this issue.

[bergmeister]

Even if .Net or PowerShell adds better API support for temp folders, the main point of this PR is to avoid any of that because it is effectively a global state that is causing issues and any state of a repo should be possible to be cleared with git clean -dfx.
Yes, one could possibly enhance the code to work better with this state or just use the NuGet cache directly but fixing it in this way provides the same benefit to the user experience whilst being a simple change to get rid of this annoying problem

[TylerLeonhardt]

@bergmeister do you want to also update the Clean task to just use git clean -dfx?

[bergmeister]

@TylerLeonhardt Good point about the Clean task. I think a git clean -dfx is a bit much and should only be executed manually as a last resort as always executing it might slow down the build quite a bit. I added the deletion of the folder to the clean task though but I am also happy to take it out.

[rjmholt]

I think a git clean -dfx is a bit much and should only be executed manually as a last resort

I agree. When tools have secretly run git clean, I have lost work. Because git touches local and remote history, I tend not to automate calls to it -- seems like a bit of a layering violation too.

[TylerLeonhardt]

LGTM

[TylerLeonhardt]

We don't need to backport this since it's build related.