-
I instantiated a base object from a webservice, and, attempted to create some objects from this base object this way: $webservice = New - WebServiceProxy - Uri http : //www.test.com/myclass.asmx -Namespace Test When I create new objects from this I use this approach: $list = New - Object Test . List - Property @{ name = 'Test' ; item = 'something' ; } When I attempt to use this custom object in a method, I get an error: $webservice . GetList ( $list ) Cannot convert argument "list"
-
Thanks Don. I'll jump in over there and see if they can help me get my head around it. Much appreciated and hope you had a good trip. : )
-
Cross post to .NET forum: http://powershell.com/cs/forums/p/10454/17659.aspx#17659
-
I instantiated a base object from a webservice, and, attempted to create some objects from this base object this way: $webservice = New - WebServiceProxy - Uri http : //www.test.com/myclass.asmx -Namespace Test When I create new objects from this I use this approach: $list = New - Object Test . List - Property @{ name = 'Test' ; item = 'something' ; } When I attempt to use this custom object in a method, I get an error: $webservice . GetList ( $list ) Cannot convert argument "list"
-
There are some places where the { must be on the same line as the syntax element. Foreach specifically comes to mind. If you try this, dir | foreach { $_.name } it won't work, but, if you run this, dir | foreach { $_.name } it will work fine. I find it is useful to keep this in mind if you run into odd issues and your syntax is in question. As far as lines, I like using the opening { the line after my function signature because it makes code expansion easier in various ISE applications. Mainly
-
C# used to be that way, but, it seems, somewhere between .NET 2.0 and .NET 3.5 the standard shifted from this (the old way): if($true) { 1 } to this (the new way): if($true) { 1 } I was using the first way for a while, but, found some C# suggesting the second way was the new "right". As I mentioned, I like to use the { on the second line because it makes expanding/collapsing easier in PowerGUI for me. That's probably my biggest motivator. That and not getting harassed by the cool kids
-
As noted above, credentials cannot be securely stored unless you some form of asymmetric algorithm. http://www.exploit-monday.com/2012/05/extracting-hard-coded-credentials-using.html You can make it a little bit harder for folks to get the original script by using some unusual encoding, but, even that is not a real solution. How secure do you need your encoding/encryption to be?
-
Even while looking at the underlying class (CIM_Controller) it only shows two methods: Reset, SetPowerState. Perhaps exploring the properties on this class may help: Get-WmiObject -Class cim_Controller | select -first 1 | gm Note I am running v3.
-
Ok. I see what you're getting at. I'll work with the ref approach and see if I can get that going. Thanks for the idea.
-
I have a try/catch/finally approach I use in a lot of my scripts. To ensure I handle scenarios properly I use Write-Error when I encounter certain situations, but, in my error logging block I get the wrong line reference. Here is a sample script to demonstrate the issue: cls function Show-Error($val) { try { if($val -eq $false) { Write-Error "Line 8" } if($val -eq $true) { Write-Error 'fail' } } catch { "Error in $($_.InvocationInfo.ScriptName)." "---------------