Doesn't work if temp directory is on a different volume than programdata
amoldeshpande opened this issue · 13 comments
[04:50:50.502 - Warning]::The folder i:\temp\j2hcs5wm.wnd\Templates can't be moved to C:\ProgramData\WindowsTemplateStudio\Templates\Pro\1.0.17131.2. Error: Source and destination path must have identical roots. Move will not work across volumes.
----------- Addtional Exception Info -----------
System.IO.IOException: Source and destination path must have identical roots. Move will not work across volumes.
How did you hit this? While running the solution or the VSIX? Can you give us more information so we know exactly how to repro this?
Since I have my temp directory to set to I:\temp, when I select the "Windows Template Studio" project type during new project creation in Visual Studio, I get this error instead of a list of templates.
You can reproduce this by opening a "Developer Command Prompt for Visual Studio 2017" and set your TEMP and TMP environment variables (I didn't bother to track down which one devstudio actually uses) before starting devenv from the command line. I used this in reverse to work around the bug.
The root cause is that the SafeMoveDirectory function in Fs.cs uses Directory.Move instead of Copy+Delete
Would it be better to extract directly into the appdata folder after download in RemoteTemplateSource ? Since the target directory cannot already exist (or the Move would fail anyway), all you'd have to do is delete the target folder if an exception is thrown anywhere in the extract path.
ok, i can repro what you're seeing when i clean out my template folder in programdata.
This uncovered a great code issue, our unit test, local copy, and remote copy code differs.
set your tmp and temp var to something on a USB drive or network share
delete programdata\windowstemplatestudio
start VS
run WTS
fails to extract and a user gets no real notification anything bad happened.
Looking, the root cause is these all have different implementations that act differently and locally and in unit test, we can’t even repro this issue.
• UnitTestsTemplatesSource
• LocalTemplatesSource
• RemoteTemplatesSource
I feel like all the real code should be abstract TemplateSource class as virtual method with abstract methods for “Download” and “Extract”, the base logic really should be the same.
'TestRemoteSource' does test Remote, but how it is structured is different than how people would have this installed.
string drive = Path.GetPathRoot(Assembly.GetExecutingAssembly().Location);
string targetFolder = Path.Combine(drive, @"Temp\TestRts");
if you had d:\temp (like me), that gives you D as the drive. Then when you're further down the code for Acquire, it also grabs the temp directory. ergo, it passes when in the real world it would have failed.
https://github.com/Microsoft/WindowsTemplateStudio/tree/Issue333 is the branch i'm working in
ok, i have a patch ready i think. Want a few extra eyes on the it.
This should be solved with the current version 1.0.17137.1; @amoldeshpande can you confirm?
I have tried on my installation and now seems works in the correct way.
The only problem I have seen, but I don't know if this is normal, is that it's not possible to update the template. Before it's necessary to uninstall the previous version and next install the new one.
@gigios it should be possible to update in-place. How did you install originally? (Through the extensions search in VS or via downloading the VSIX directly?) And how did you update?
Mine is set to automatically update within Visual Studio and did so just fine.
I can confirm the latest version does show the templates and I can create projects with it. thanks for the quick turnaround
@mrlacey I installed directly from the Extension Manager of VS (Enterprise).
To confirm if there is a problem on the 'upgrade' process we can wait the next release. If the problem still present I can open a new issue.
For the moment thanks for the support :)
I'm closing this issue now as the problem pointed is solved.