- Unblock-File the extracted WinSCP files after unzip: Windows tags
downloaded files with Mark-of-the-Web, which makes Add-Type refuse to
load WinSCPnet.dll (FileLoadException 0x80131515) until unblocked.
- run.bat passed -EntityDir "%~dp0", but %~dp0 always ends in a trailing
backslash. cmd's argument parser treats a lone backslash before a closing
quote as an escaped literal quote rather than the string terminator, so
PowerShell received the path with a stray " character baked in
(Entities\CAMBS" instead of Entities\CAMBS), breaking Test-Path. Strip the
trailing backslash before quoting it.
Root cause found: winscp.net's download URL serves a human "please wait"
landing page (18KB HTML) instead of redirecting to the real file, unless
the User-Agent contains a known download-tool signature like curl or Wget.
PowerShell's own default UA always gets the landing page - confirmed by
reproducing locally with various UAs against the live URL. Not antivirus,
not TLS, not a network block; overriding -UserAgent to a curl string on
Invoke-WebRequest resolves it.
The 1MB size-check catches a bad download but gave no way to see why - on a
locked-down network something is very likely substituting a small HTML page
(proxy/AV block page) for the real zip. Print the first lines of whatever
was actually saved so the content is visible without another round trip.
Expand-Archive was failing with a cryptic "End of Central Directory record
could not be found" on Melissa's PC - the inline one-liner in setup.bat had
no error handling, so a blocked/truncated download (antivirus, firewall, or
an older TLS default) surfaced as a raw .NET exception instead of a useful
message. Moved the logic to Get-WinSCP.ps1: forces TLS 1.2, validates the
downloaded file size before unzipping, and reports what actually went wrong.
blance