Exception calling "ExtractToFile" when unzipping - powershell

I've tried a couple of solutions to unzip a file containing the path:
\Content\F_C\Jenkinsworkspace\workspace\BUILD.PROJECT.GENERICS\PROJECT_Generics\PROJECT.Generics\PROJECT.Generic\obj\Debug\Package\PackageTmp
but I get the error:
Exception calling "ExtractToFile" with "3" argument(s): "Could not find a part of the path
Expand-Archive -LiteralPath F:\Jenkinsworkspace\workspace\BUILD.GENERIC.GENERICS\GENERIC.Generic.zip -DestinationPath F:\Jenkinsworkspace\workspace\BUILD.GENERIC.GENERICS\UNZIPED2 -Force
Exception calling "ExtractToFile" with "3" argument(s): "Could not find a part of
the path 'F:\Jenkinsworkspace\workspace\BUILD.GENERIC.GENERICS\UNZIPED2\Content\
F_C\Jenkinsworkspace\workspace\BUILD.GENERIC.GENERICS\GENERIC_Generics
\GENERIC.Generics\GENERIC.Generic\obj\Debug\Package\PackageTmp\modules\
_protected\EPiServer.GoogleAnalytics\EPiServer.GoogleAnalytics.zip'."
At
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:1033 char:25
+ ... [System.IO.Compression.ZipFileExtensions]::ExtractToFile( ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : DirectoryNotFoundException
I'm guessing it's because I have a zip within a zip.

In our case, though the path was short, we were getting the same error.
Sharing our solution which might be useful for someone.
We were trying to unzip the package on our application server through powershell script. Basically powershell script runs on our build server & remotely connect to our application server. It was then trying to unzip the package present on application server.
The above scenario was working fine for quite some time before it starts to throw the error during unzipping.
Solution:
We found the reason was anti virus policy, which was blocking the unzipping through remote powershell script.

Soved using this Blog :
https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/
changing the group policy solved the problem

Related

WebClient HTTP upload - "An exception occurred during a WebClient request."

Hoping someone can offer some advice with this - it may be that I've been staring at my screen too long so apologies if I'm missing the obvious!
Within a script I'm trying to add an upload/download speedtest to my webserver, but I'm having an issue trying to upload a file to my webserver via HTTP(s) in Powershell. I can get download working no problem.
The upload snippet of my script is as follows:
$uploadPath = "https://www.domain.co.uk/speedtest/up/"
$localfile = "C:\Users\user\Downloads\100MB.bin"
$wc = New-Object System.Net.WebClient
$wc.UploadFile($localfile, $uploadPath)
I've tried over HTTP & HTTPS, file permissions are currently 777 on the "up" folder on the server (just as a test) and I've also tried $uploadPath as:
"https://www.domain.co.uk/speedtest/up/100MB.bin".
The following is the error received when running the upload section of the script:
Exception calling "UploadFile" with "2" argument(s): "An exception occurred during a WebClient request."
At C:\Users\User\desktop\uploadtest.ps1:4 char:1
+ $wc.UploadFile($localfile, $uploadPath)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException
(file paths etc are just temporary for this test too)
Any suggestions you can make would be appreciated! I'd ideally like to use the webclient method (if possible) as the download uses the same method.

Problems loading iTextSharp in PowerShell

I am having problem loading the iTextSharp.dll in PowerShell. Sometimes it works fine using either:
[System.Reflection.Assembly]::LoadFrom("C:\dll\itextsharp.dll")
Add-Type -Path C:\dll\itextsharp.dll'
However, most times I get the following error:
Exception calling "LoadFrom" with "1" argument(s):
"Could not load file or assembly 'file:/// C:\dll\itextsharp.dll'
or one of its dependencies. Operation is not supported.
(Exception from HRESULT: 0x80131515)"
At line:1 char:1
+ [System.Reflection.Assembly]::LoadFrom("itextsharp.dll")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : FileLoadException
I have tried unblocking the file but I still get the error above.
Looks like this on StackOverflow will probably solve your problem. Apparently you need to add the option <loadFromRemoteSources enabled="true" /> to the .EXEs config file to load an assembly from a network share.
I found this by searching for the HRESULT 0x80131515
I have found that the DLL works with PowerShell ISE (x86), but not the 64-bit version of PowerShell ISE.

Strange Error with Powershell when downloading files

I got a very strange error when trying to install dnvm on powershell. Actually I get this error with any attempt to download anything, e.g. "wget" produces a similar error.
I thought first that I don't have the rights to execute but running this in an Administrator shell + I changed the Security Policy.
Then I figured that the PS doesn't have access to the internet, so I adjusted the Firewall and even added PS to the allowed programs. No luck!
Now the weird thing is that I can download files just fine via IE.
This is the error that I get
Exception calling "DownloadString" with "1" argument(s): "An exception occurred during a WebClient request."
At line:1 char:17
+ &{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.gith ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException
Anyone as an idea?
Also this is a machine running on AWS.
This is a shot in the dark, but first thing that comes to mind is proxy settings.
System.Net.WebClient does not automatically pick up IE's proxy configuration, but you should be able to force it to do so with:
$WebClient = New-Object System.Net.WebClient
$WebProxy = [System.Net.WebProxy]::GetDefaultProxy()
$WebClient.Proxy = $WebProxy
$WebClient.DownloadString($url)
or with your very compact syntax:
&{$Branch='dev';($w=New-Object Net.WebClient).Proxy=[Net.WebProxy]::GetDefaultProxy();iex $w.DownloadString($url)}

Exception creating client using AWS SDK

I am currently using the following sequence of commands in a Windows 7 PowerShell window.
Add-Type -Path "C:\Program Files (x86)\AWS SDK for .NET\bin\Net35\AWSSDK.dll"
$secretKeyID="ABCDEFGHIJKLMNOPQRS"
$secretAccessKeyID="LONGKEYBLAHBLAHBLAHBLAHBLABLAH"
$AWSclient=[Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID,$secretAccessKeyID)
However, I get this exception below. Please let me know what Im doing wrong. This is what I see most people using successfully.
Exception calling "CreateAmazonS3Client" with "2" argument(s): "No RegionEndpoint or ServiceURL configured"
At line:1 char:1
+ $oAWSclient=[Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID,$secret ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : AmazonClientException
One thing that I think is a problem is that my bucket is not checked for 'enable website hosting'. Does this need to be set to true? I just want to upload a file to the bucked via powershell script.
Duh... I realized that I need to use the AWS Powershell because it has all the settings built into it. Im not exactly sure how to properly refer to this version of powershell, but it is available after installing the AWS SDK.
Since the error specifically states that you're missing the RegionEndpoint or ServiceURL, you could also just include one of them. Since you're connecting to S3, all you need is to include the RegionEndpoint.
Add-Type -Path "C:\Program Files (x86)\AWS SDK for .NET\bin\Net35\AWSSDK.dll"
$secretKeyID="ABCDEFGHIJKLMNOPQRS"
$secretAccessKeyID="LONGKEYBLAHBLAHBLAHBLAHBLABLAH"
$client = [Amazon.AWSClientFactory]::CreateAmazonS3Client($secretKeyID, $secretAccessKeyID, [Amazon.RegionEndpoint]::USEast1)
(Replace USEast1 with the value configured with your S3 Bucket)

Open a Solution from the Package Manager Console

I'm trying to automate the process of opening a solution from source control.
I have VS12 open, but no solution or project open. Is it possible to change directories and then open a solution from the Package Manager Console?
(This is kind of beside the point, but in case there is a better way overall to do this) I'm trying to script this so that a powershell module installed via nuget could be run:
PM> Get-MyProject 'SomeName'
The module would then from pwd get the latest source cd into it and open the solution. My module can already get the source, but I'm not able to figure out how to open the solution in powershell. It seems like $dte should be able to do it, but I tried:
PM> $dte.Solution.Open('NugetTest.sln')
I get back the error
Exception calling "Open" with "1" argument(s): " could not be found. (Exception from HRESULT: 0x80030002 (STG_E_FILENOTFOUND))"
At line:1 char:1
+ $dte.Solution.Open('NugetTest.sln')
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : COMException
The default directory for the package manager console (unless you have defined a profile where you change it) is %userprofile%. Probably not the place where your solution sits. If you write a powershell script and place it in your solution directory, then execute it from the Power Shell Console, you can get the path of your solution doing this:
$path = Split-Path -parent $MyInvocation.MyCommand.Path
You can create a solution like this:
$solution = $dte.Solution
$solution.Create("C:\Temp", "MySolution.sln")
The first argument indicates the directory where you want to create the solution, the second one is the name of the solution itself.
To open an existing solution:
$solution = $dte.Solution
$solution.Open("<path to your solution>")
If it doesn't work, your path is probably incorrect.