Bug in New-WebServiceProxy cmdlet when using -Namespace?

Question

So I ran into this exact problem: http://www.vistax64.com/powershell/273120-bug-when-using-namespace-parameter-new-webserviceproxy.html

The gist of the issue is that when using the New-WebServiceProxy cmdlet AND the -Namspace parameter then you can't execute a method on the proxy with an argument of an autogenerated type.

Something like this:

// In the service
public void DoSomething(DoSomethingRequest request) { ... }


$proxy = New-WebServiceProxy -Uri "http://something.com/MyService.svc" 
          -Namespace ns 
$req = New-Object ns.DoSomethingRequest
$proxy.DoSomething($req)

This throws an exception along the lines of Cannot convert argument "0" of type "ns.DoSomething" to type "ns.DoSomething"

As is explained in the link, by removing the -Namespace parameter and utilizing the autogenerated namespace everything works fine. However, I'd really like to use the -Namespace....

I can't find anything related to a "fix" or the correct way to utilize the -Namespace in this scenario. Can anyone shed some light on this for me?

Answer 1

Actually you're seeing something a notch more subtle. With -Namespace, you cannot execute an argument of the type in the namespace twice

I suspect you're creating New-WebServiceProxy a lot, like, in the process block of a function, or inside of a command that's called repeatedly. Every time you call it, it tries to regenerate, and, with -Namespace, this leaves little collisions with associated types in the AppDomain. There end up being several of them, and you get this error.

There are two ways around this:

• Make sure it's imported once and only once per AppDomain. In something like PowerGUI or the ISE this might be harder than it sounds, because not only are there the runspaces you think about (like open tabs), but there are the runspaces you don't (like those fired up by add ons, or in-process jobs)
• The far "easier", but significantly more cryptic looking workaround is to simple create types relative to a particular namespace.

This is far easier to show than tell.

I had this problem with a module I have for Office365 / Exchange Web Services, and, beneath the covers, it has something like:

$createItemType = 
   New-Object "$script:ExchangeWebServiceNamespace.CreateItemType" 
-Property @{
 MessageDisposition = $messageDisposition
 MessageDispositionSpecified  = $true
 Items = 
    New-Object "$script:ExchangeWebServiceNamespace.NonEmptyArrayOfAllItemsType"
}

This is obviously a little cryptic, but, well, so is Exchange Web Services. And so are many web services that are built directly from complex object models.

Unfortunately, that is the vast majority of web services that New-WebServiceProxy works with.

Bear in mind, it's still good practice to cache the web service object you create in your module (using $script:variablename like above), but this weird trick to reference web service parts by the proxy object has saved me more times than I'd like.

Hope this Helps

Answer 2

Are you running your code in some editor? I had similar problem when running script from PowerGUI editor, but it is working fine for me when I run it from console. Try close all your powershell related stuff and open it again