Hello!
I’m having an issue calling New-WebServiceProxy in a script. I get the following error.
[7:37:49 PM] [ERR] Could not load file or assembly ‘file:///C:\Users\User\AppData\Local\Temp\yd0b2elx\yd0b2elx.dll’ or one of its dependencies. The system cannot find the file specified.
The “User” is the username of the same account as the application pool identity. I’ve set the user to full admin of the server as well, no change. Using IIS to host, I’ve tried in/out process. The script is one line.
Are you using Windows PowerShell or PS7? I know New-WebServiceProxy doesn’t exist in PS7 but just want to make sure it’s not doing some weird compatibility thing and trying to load the DLL into PS7 after running the command in WinPS.
You might be able to get a little more information from the exception by catching the error and digging into the exception and inner exceptions.
Thanks for getting back to me! PSU is awesome, btw.
Environment: 5.1.17763.1852
$_.Exception gave me:
File name: 'file:///C:\Users\User\AppData\Local\Temp\tfgow4hn\tfgow4hn.dll'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.Assembly.Load(AssemblyName assemblyRef, Evidence assemblySecurity)
at System.CodeDom.Compiler.CompilerResults.get_CompiledAssembly()
at Microsoft.PowerShell.Commands.NewWebServiceProxy.GenerateWebServiceProxyAssembly(String NameSpace, String ClassName)
at Microsoft.PowerShell.Commands.NewWebServiceProxy.BeginProcessing()
at System.Management.Automation.Cmdlet.DoBeginProcessing()
at System.Management.Automation.CommandProcessorBase.DoBegin()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
I guess it’s creating that file temporarily each time you execute the command. When I go to look for it, it really isn’t there (or anywhere else)
New-WebServiceProxy uses the System.Net.WebClient class. I tested the code below and that works just fine.
Yeah. My assumption is that it’s actually compiling a C# dll that create that proxy. For some reason, that DLL relies on some sort of dependency that isn’t being met within PSU.
I tested this using the straight exe with version 1.5.11, and it works. It’s something to do with either the newer version, or with running in IIS. Hope that helps
PS C:\Users\adamr> $URI = "http://www.dneonline.com/calculator.asmx?wsdl"
PS C:\Users\adamr> $calc = New-WebServiceProxy -Uri $URI -Namespace "WSProxy" -Class "Calculator"
New-WebServiceProxy : Could not load file or assembly 'file:///C:\Users\adamr\AppData\Local\Temp\jrrvvlar.dll' or one of its dependencies. The system cannot find the file specified.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-WebServiceProxy], FileNotFoundException
+ FullyQualifiedErrorId : System.IO.FileNotFoundException,Microsoft.PowerShell.Commands.NewWebServiceProxy
If I change this to remove the Namespace and Class, it works.
Can you try adjusting the Namespace and Class name to see if you have a similar experience?
My guess is that the types loaded in the assembly are failing due to conflicts (or something) but I have yet to get good info out of New-WebServiceProxy to find out why it thinks the DLL can’t be loaded.
With my testing in PSU + IIS I didn’t use Namespace or Class options. In a regular PS session I got the same error as you did with that code, seems it’s related to the URL itself. If I replace that URL with the one I used to test above (http://soapclient.com/xml/SQLDataSoap.WSDL), Class Calculator and Namespace WSProxy work in a local session.
The XML in that calulator link has an invalid targetnamespace of "xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/” targetNamespace="http://tempuri.org/">"
That might be why it’s acting weird - tempuri.org just redirets to bing.com? EDIT: I don’t think it’s related to that namespace URL - I tested some other soap URLs where that name also didn’t resolve and they seem to be ok with WSProxy and Calculator, huh.
PS C:\scripts> $URI = "http://www.dneonline.com/calculator.asmx?wsdl"
PS C:\scripts> $calc = New-WebServiceProxy -Uri $URI -Namespace "WSProxy" -Class "Calculator"
New-WebServiceProxy : Could not load file or assembly 'file:///C:\Users\User\AppData\Local\Temp\bxdh1ku1\bxdh1ku1.dll' or one of its dependencies. The system cannot find
the file specified.
At line:1 char:9
+ $calc = New-WebServiceProxy -Uri $URI -Namespace "WSProxy" -Class "Ca ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-WebServiceProxy], FileNotFoundException
+ FullyQualifiedErrorId : System.IO.FileNotFoundException,Microsoft.PowerShell.Commands.NewWebServiceProxy
Seems that guy had a similar issue with the namespace/class and it was related to the data returned by the service (but not that namespace URL). Not sure this is related to the PSU + IIS issue since everything works in PSU by itself but not behind IIS.
Only thing is, I ran this on my machine-no IIS install or service running-and I’m getting the same error. I did some tracing with procmon and it’s calling csc.exe which is producing the .dll in the $temp (C:\Users$user\appdata\local\temp) directory. It looks like it’s getting created just fine, though it is getting deleted almost right away. I’ve tried catching either the .out, .pdb, or the .dll files via a WMI event but the files are getting deleted faster than the event engine can act on them.
I didn’t see any other obvious errors in the trace, just the exit thread event from Powershell at the end. Still digging around though.
@mackposh You’re saying you got the error running in PSU without IIS / Service account? Or just in regular old powershell console.
Permissions were the first thing I assumed - application pool couldn’t access the temp directories. I set the application pool to run under a local machine admin account. Verified read/write/full control on \windows\temp, \temp, and \users\user\appdata\local\temp - none of which helped
I did another test run with assembly binding logging on - got a little more info.
File name: 'file:///C:\Users\User\AppData\Local\Temp\e3weakhk\e3weakhk.dll'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAss…Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Attempting download of new URL file:///C:/Users/User/AppData/Local/Temp/e3weakhk/e3weakhk.dll.
So I attached Visual Studio’s debugger to the Powershell process which revealed this extra tidbit:
The actual exception is getting thrown around this void Resolve() method: System.Web.Services.Discovery.DiscoveryDocumentReference.Resolve(String contentType, Stream stream)
Error details:
System.InvalidOperationException
HResult=0x80131509
Message=Discovery document at the URL http://www.dneonline.com/calculator.asmx?wsdl could not be found.
Source=System.Web.Services
StackTrace:
at System.Web.Services.Discovery.DiscoveryDocumentReference.Resolve(String contentType, Stream stream)
Inner Exception 1:
ArgumentException: The document format is not recognized.
I think I know what’s happening, although I have no idea why since Microsoft’s documentation doesn’t match the behavior. So, if remove namespace and class parameters and just run:
$calc = New-WebServiceProxy -Uri $uri
it works as previously noted. If I run $calc | gm here is the output. Notice the TypeName:
Now, if I run the following, specifying ‘Calculator2’ as the class, according to Microsoft documentation, I should expect the TypeName to reflect that, but it doesn’t:
$calc = New-WebServiceProxy -Uri $uri -Class 'Calculator2' -Namespace 'WSProxy'
$calc | gm
# According to docs, we should expect to see a TypeName of 'WSProxy.Calculator2' but we don't:
TypeName: WSProxy.Calculator
So, I think what’s happening here is a class name collision. At least in this specific instance. As you can also see from the example above, the Namespace isn’t the problem, it’s the defined Class parameter.
