During deployment I’m using the Get-Website cmdlet to work out whether the site has been created in IIS already or not. However, every time the tentacle runs the script I get this error:
ERROR: Get-Website : Could not load file or assembly ‘System.Security’ or one of its d
ERROR: ependencies. The system cannot find the file specified.
I’ve got the following at the top of my script, and if I run it manually everything works fine, it seems only to be an issue when run from the tentacle:
I’m deploying to Win2008R2 Standard x64. Any ideas what the problem might be - is there something I should add to my PS or is it a Tentacle issue? The Tentacle is running as a domain user with admin rights.
I run the PowerShell script within a custom PowerShell host, so there might be something I need to do to support assembly resolution. I’ll try your script and aim to get a new build out with a fix tonight.
I think I know what’s going on here. Octopus runs as a .NET Framework 4.0 process. However when you run PowerShell 2.0 from Windows, it actually runs under a .NET 2.0 runtime.
In PowerShell, when the LoadWithPartialName line runs, I get this output:
GAC Version Location
--- ------- --------
True v2.0.50727 C:\Windows\assembly\GAC_MSIL\System.Security...
However, when I run the same line within Tentacle, I get:
GAC Version Location
--- ------- --------
True v4.0.30319 C:\Windows\assembly\GAC_MSIL\System.Security....
When the script then runs Get-Website, it needs to resolve the .NET 2.0 version of System.Security, but the .NET 4.0 version is loaded into Tentacle - and only one version of an assembly can be loaded at once. That’s why you receive that error.
When I run the script in Tentacle, it appears the Assembly.Load… line isn’t actually needed - calling Import-Module followed by Get-Websites works for me. However if you do need to force load the assembly, you can do it by specifying the version:
Thanks for that info, but unfortunately this doesn’t appear to work for me. When I add the Assembly.Load Tentacle still outputs v4.0.30319, which seems odd? I’ve also tried moving where I load this, and where I do the Import-Module but continue to get the same issue. Any further ideas I could try? I’m on v0.8.398.2027.
I spent a lot of time tonight trying to reproduce this issue, but I am unable to. Version 4.0.30319 is loaded, but I can still call Get-Website without problems. I’ve tried this on Windows 7 x64, Windows Server 2008 R2 x64, and Windows Server 2008 R1 x32, running under a mix of local user (as admin) and Local System accounts.
Are you able to tell me:
The account your Tentacle service is running as (by default it is Local System)
The error message you get when you call Get-Website after Assembly.Load
The error message you get if you do not call Assembly.Load
A full copy of the script would be very valuable.
Can you also remote into the machine running Tentacle, and send me the output of this command?
Attached are my scripts and the output from the given commands. I was running the Tentacle as a domain user who is a member of the domain admin group, I’ve since tried it with Local System and got more or less the same results (errors I got were because Local System didn’t have permission to access the SAN, but that was expected behaviour).
The error I get from PS when hitting Get-Website is “Could not load file or assembly ‘System.Security’ or one of its dependencies. The system cannot find the file specified.”, and I get this whether or not I do the Assembly.Load.
The domains’ admin group is a member of the local machines Administrators group.
I can now see what’s happening here, but not quite sure how to get around it (yet!). It would seem that if I use Get-Website in the predeploy.ps1 file itself it works perfectly - however, when it’s called it in a dot sourced include (as I am) this fails!
After restarting the Tentacle service, re-deploy your package, and let me know how it goes. Since WebAdministration uses System.Security v2, I believe this setting will make it accept v4 as an acceptable version.
I’m still unable to reproduce this issue locally but if this doesn’t solve it I will set up a test package using your scripts as-is on a fresh Server 2008 R2 machine to see how I go.
I’ve worked around my issue by moving the get-website in to the parent script, so deployments are currently working. This is not the end of the world at the moment so perhaps can be marked for later investigation, but it would definitely seem to be related to the dot include mechanism.
FYI, a colleague has pointed me at an alternative way of doing get-website because of a WOW64 issue, and this DOES work in PoshConsole, I’ve not had chance to try it in my script yet though:
Glad you worked around it. I’d be curious to know whether the new approach works in Octopus too. Sorry I’ve been unable to reproduce this one - I’m going to put some thought into finding ways to reproduce stuff like this more reliably. There may be some differences in our OS/script configurations that I’m just not aware of.