I have a Powershell error that only happens when I run a script through a Tentacle on one Windows 7 (64-bit) machine.
If I run (as an example):
@@@
Import-Module WebAdministration
Get-WebSite -Name “Default Web Site”
@@@
I get the following error:
ERROR: Get-WebSite : Could not load file or assembly 'Microsoft.IIS.PowerShell.Framework' or one of its dependencies. The system cannot find the file specified.
However, if I run the same through the Powershell.exe it works correctly. I assumed that there was something I needed to do to make the custom powershell host that the tentacle uses pick up the correct version.
Finally, out of desperation I tried some other commands and got to the point where I had the following (ridiculous) script:
@@@
Import-Module WebAdministration
Get-WebSite -Name "Default Web Site"
Get-WebSite -Name “Default Web Site” #yes, it is the same line - not a typo!
@@@
And, guess what?! The first “Get-WebSite” fails with the FileNotFoundException and the second one works fine! Is it a timing issue with loading the assemblies in the Powershell Host? And, do you have a workaround for this?
Thanks for the bug report. I’m glad you found a workaround and I’m sorry it was such a frustrating issue.
Our custom PowerShell host does seem to have incompatabilities with PowerShell and unfortunately there’s not a lot of guidance form Microsoft on how to create a real, 100% compatible PowerShell host. So in our next release, we’re going to include a few different PowerShell invocation options:
I’ll watch out for new feature. In the meantime I got around the issue with something like this:
@@@
Import-Module WebAdministration
Try{
$site = Get-WebSite -Name “Default Web Site”
} Catch [System.IO.FileNotFoundException]{
$site = Get-WebSite -Name "Default Web Site"
Break
} Finally {
Write-Host $site.name # or do whatever meaningful thing we want to do…
}
@@@
We’ve discovered subsequently that this issue occurs in PowerShell run outside of Octopus as well - it seems to be related to some broken error code checking in PowerShell itself.
Most of the time it can be resolve by writing something to the console before running the problem line, e.g. :
Write-Output "About to run tricky PowerShell"
# Other PS command goes here
Thanks for the update. I also noticed that the error occurs outside of Octopus. It wasn’t resolved by writing something to the console but the try catch solution seems to work.
I just thought I’d drop a note here, I’ve been having the error too, but not within Octopus (we aren’t using it here, you just came up as a top search hit :P).
The problem that we hit was related to the IIS SnapIn. I have a script that was looking for the module and the snapin and then loading the appropriate one. It seemed that the get-pssnapin -Registered | select-string -pattern 'WebAdministration' command is the problem.
Our solution was to look for the module with get-module, if it exists then import it, else look for the snapin.
And I thought I would chime in as well: We have the same problem but with Powershell 3 itself (and I also found this post via search engine). Interestingly, in our scenario running the command mentioned by Aaron above actually seems to FIX it:
We never had this problem - but now have it with the upgrade to 2.4.10.235
This seems to point to the interaction between powershell and octopus.
That module is definitely installed in our boxes and our previous version of octopus deploy worked.
Thanks for getting in touch! Can you share some more information about the errors you are getting, the version of Windows you are using, whether 64 or 32-bit, and what your script looks like? This is a rather old thread.
We’ve started doing this to load the IIS cmdlets regardless of the OS/powershell configuration:
This is the only script in our whole stack which is called from PostDeploy.ps1 – in other post and predeploy scripts we invoke import-module WebAdminstration directly.
Write-Host "Updating CMS Website $cmsWebsiteIisName"
$webAdminModuleTest = get-module -ListAvailable -Name WebAdministration
if ($webAdminModuleTest)
{
# Web Administration module available.
# SCRIPT FAILS HERE!!!!!!
import-module WebAdministration
}
else
{
$webAdminSnapInTest = get-pssnapin -Registered | select-string -pattern 'WebAdministration'
if ($webAdminSnapInTest)
{
# Web Administration snap-in available.
add-pssnapin -name WebAdministration
}
else
{
Write-Error "Neither Web Administration module nor IIS Powershell snap-in are available."
Write-Verbose "In a powershell window type in: get-module -ListAvailable. "
Write-Verbose "If you don't see Web Administration module listed, install the IIS Powershell snap-in."
Write-Verbose "http://www.iis.net/download/powershell"
return
}
}
# Hack because import-module WebAdministration intermittently fails
# starting from octopus 2.4.10.235
$cmsWebsitePhysicalPath = $OctopusActionPackageCustomInstallationDirectory
# Original code below
#$cmsWebsite = Get-Website -Name "*$cmsWebsiteIisName*"
#$cmsWebsitePhysicalPath = $cmsWebsite.physicalPath
We are using Windows 2008 R2 64 Bit Powershell 3.0
Another thing is that we run this same script from other octopus projects and it runs fine sometimes and gets past. But once in a while it doesn’t get past the above line.
This is the only script in our whole stack which is called from PostDeploy.ps1 – in other post and predeploy scripts we invoke import-module WebAdminstration directly.
$webAdminModuleTest = get-module -ListAvailable -Name WebAdministration
if ($webAdminModuleTest)
{
# Web Administration module available.
# SCRIPT FAILS HERE!!!!!!
import-module WebAdministration
}
else
{
$webAdminSnapInTest = get-pssnapin -Registered | select-string -pattern 'WebAdministration'
if ($webAdminSnapInTest)
{
# Web Administration snap-in available.
add-pssnapin -name WebAdministration
}
else
{
Write-Error "Neither Web Administration module nor IIS Powershell snap-in are available."
Write-Verbose "In a powershell window type in: get-module -ListAvailable. "
Write-Verbose "If you don't see Web Administration module listed, install the IIS Powershell snap-in."
Write-Verbose "http://www.iis.net/download/powershell"
return
}
}
# Hack because import-module WebAdministration intermittently fails
# starting from octopus 2.4.10.235
$cmsWebsitePhysicalPath = $OctopusActionPackageCustomInstallationDirectory
# Original code below
#$cmsWebsite = Get-Website -Name "*$cmsWebsiteIisName*"
#$cmsWebsitePhysicalPath = $cmsWebsite.physicalPath
We are using Windows 2008 R2 64 Bit Powershell 3.0
Another thing is that we run this same script from other octopus projects and it runs fine sometimes and gets past. But once in a while it doesn’t get past the above line.
The script actually fails on the Get-Website call.
ERROR: Get-WebSite : Could not load file or assembly ‘Microsoft.IIS.PowerShell.Framework’ or one of its dependencies. The system cannot find the file specified.
Thanks for the reply. Looking around the web some people seem to have had success either stopping or removing the default web site in IIS, or putting a Write-Host call prior to Import-Module, but none of these seem to solve the problem 100%. You could also try a try/catch and retry the command since it only seems to be an intermittent problem. Sorry I can’t be of more help.
With the new update in octodeploy, I can deploy vdir websites, but Im getting this error on the server. Ive tried to update powershell to 4.0 and the problem are still there.
Anyone has a solution for this, since its in a flow I havet control over how can I Write-Host or anything like that before the Get-Website call?
I “fixed” the problem with some script, not beautiful:
Write-Host "Getting web site $parentSite"
try{
$site = Get-WebSite -Name “Default Web Site”
} catch [System.IO.FileNotFoundException]{
Write-Host “Try again to get website”
$site = Get-WebSite -Name "Default Web Site"
Break
} finally {
Write-Host $site.name # or do whatever meaningful thing we want to do…
}
Its weird because the same flow on our “test” Environment worked when deploying, but then when I deployed to our “staging” environment the error happend. The windows version is the same, the powershell version is the same. Now ive updated the powershell version on staging to 4, but the problem still excised until I changed the script.
There must be some kind of diff between our test and staging, since the error happened only on staging, ill happily fire off some scripts you send to gather some server information if you need it.
4 months ago you responded to this thread on our support forums, recently someone has added to the thread. When you respond to a thread you become a watcher and receive emails for any correspondence on the thread.