ProjectDirectories.from hangs on Windows 10 when LIB environment variable contains non-existent directory

[marq]

Version 26

// LIB=C:\nope

import dev.dirs.ProjectDirectories
ProjectDirectories.from("com", "Foo Corp", "Bar App")

It's stuck on a powershell call:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2 -NoProfile -EncodedCommand JgAg...

When I try running it manually it fails:

Add-Type : (0) : Warning as Error: Invalid search path 'C:\nope' specified in '
LIB environment variable' -- 'The system cannot find the path specified.

[soc]

Hi @marq,

what are you trying to do with the LIB env?

Thanks,

Simon

[marq]

Hi @soc,

I'm not doing anything with it. It was set by something else (I think one of the paths was set by Visual Studio).

I was just trying to find out why Metals in VS Code didn't work on my machine and this led me to the problem I've described.

[soc]

Interesting, thanks! I'm evaluating other approaches (like using the new Java FFI, but that's still a long way to go), not sure what can be done to keep this PowerShell stuff from breaking.

[softwareCobbler]

I have a similar issue with spawning SBT on Windows 10, both via metals and directly on the command line. I usually end up killing about 4 blocked powershell processes , all stuck on something like the following:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2 -NoProfile -EncodedCommand JgAgAH...

where the encoded command decodes to

& {
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Add-Type @"
using System;
using System.Runtime.InteropServices;
public class Dir {
  [DllImport("shell32.dll")]
  private static extern int SHGetKnownFolderPath([MarshalAs(UnmanagedType.LPStruct)] Guid rfid, uint dwFlags, IntPtr hToken, out IntPtr pszPath);
  public static string GetKnownFolderPath(string rfid) {
    IntPtr pszPath;
    if (SHGetKnownFolderPath(new Guid(rfid), 0, IntPtr.Zero, out pszPath) != 0) return "";
    string path = Marshal.PtrToStringUni(pszPath);
    Marshal.FreeCoTaskMem(pszPath);
    return path;
  }
}
"@
[Dir]::GetKnownFolderPath("3EB685DB-65F9-4CF6-A03A-E3EF65729F3D")
[Dir]::GetKnownFolderPath("F1B32785-6FBA-4FCF-9D55-7B8E7F157091")
}

If I run the command manually, just as it was spawned (i.e. with the base64 encoded command), I get the following error:

Add-Type : (0) : Warning as Error: Invalid search path 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\lib\x64' specified in 'LIB environment variable' -- 'The system cannot find the path speci
fied. '
(1) : using System;
At line:3 char:9
+ Add-Type <<<<  @"
    + CategoryInfo          : InvalidData: (error CS1668: W...th specified. ':CompilerError) [Add-Type], Exception
    + FullyQualifiedErrorId : SOURCE_CODE_ERROR,Microsoft.PowerShell.Commands.AddTypeCommand

Add-Type : Cannot add type. There were compilation errors.
At line:3 char:9
+ Add-Type <<<<  @"
    + CategoryInfo          : InvalidData: (:) [Add-Type], InvalidOperationException
    + FullyQualifiedErrorId : COMPILER_ERRORS,Microsoft.PowerShell.Commands.AddTypeCommand

Dir : Unable to find type [Dir]: make sure that the assembly containing this type is loaded.
At line:18 char:6
+ [Dir] <<<< ::GetKnownFolderPath("3EB685DB-65F9-4CF6-A03A-E3EF65729F3D")
    + CategoryInfo          : InvalidOperation: (Dir:String) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

Dir : Unable to find type [Dir]: make sure that the assembly containing this type is loaded.
At line:19 char:6
+ [Dir] <<<< ::GetKnownFolderPath("F1B32785-6FBA-4FCF-9D55-7B8E7F157091")
    + CategoryInfo          : InvalidOperation: (Dir:String) [], RuntimeException
    + FullyQualifiedErrorId : TypeNotFound

The LIB environment variable does point to a non existent path, just kruft left over from an old visual studio installation I guess. Fixing it to point to a valid path seems to have resolved the process hangs.

It would be cool if it did a hard "print trace/message and terminate" or something like that to reduce friction for future users.

[soc]

Hey @marq, hey @softwareCobbler,

I think the current way of dealing with Windows is neither reliable nor maintainable anymore.

Would you be willing to test-drive https://github.com/dirs-dev/dirs-cli-rs, if I build and send you the binary for it?

I'm mainly interested whether the binary runs (without UAC, warning dialogs, malware false-positives) and prints out the expected values.

If that works, I'd look into replacing the existing machinery with shipping this binary in the JAR, extracting and running it.