I got a new problem while using vb6 dll in my Web Services. When using dll, the object instance is created fine but when I start calling it's method from my service I got this exception:
Server was unable to process request. ---> Unable to cast COM object
of type 'WS_Resevat_DLL.WS_ResevatCLClass' to interface type
'WS_Resevat_DLL._WS_ResevatCL'. This operation failed because the
QueryInterface call on the COM component for the interface with IID
'{69F1DA59-56D1-47CE-94A4-D681ABECDF80}' failed due to the following
error: No such interface supported (Exception from HRESULT: 0x80004002
(E_NOINTERFACE)).
The whole system runs fine when I test it on my computer IIS (I have Windows 7 with IIS 7). The problem starts when I publish it on server (Windows Server 2003 with IIS 6). I'm using asp.net 3.5 web services with SOAP 1.1. The VB dll is from the third part and I sadly can't debug it (the only thing I checked with dll creator is that binary compatability is enabled, I don't know VB at all), but when it runs outside the service (on Win Server 2003) it works fine.
Some explanation bout the types (WS_ResevatCLClass and WS_ResevatCL). In origin the dll has only one type: WS_ResevatCl. But when I look at the dll in component explorer in Visual Studio I see strange things - there is a class called WS_ReservatCLClass and 4 different interfaces: _WS_ResevatCL, WS_ResevatCL, WS_ResevarCL_v0 and WS ResevatCL_v1. And the most strange thing is that I can create instance of one them (WS_ResevatCL) and it drives exactly like an instance of the class.
Are there any significant differences between Win7 and WinServer2003 that can cause the crash with such exception?
Related
Can anybody tell how to debug the Com Dll in IIS 7.0 using VB 6.0 in Windows Server 2008 R2.
I am able to hit break point in VB 6.0 accessed from Console Application using interop dlll.Through ASPX pages in IIS 7.0 I am getting the following Exception
Unable to cast COM object of type 'XCreateUser.XAcctUserProfileClass'
to interface type 'XCreateUser._XAcctUserProfile'. This operation
failed because the QueryInterface call on the COM component for the
interface with IID '{7A48FABA-CCC8-4FA6-94E8-803F6CF121F2}' failed due
to the following error: Error loading type library/DLL. (Exception
from HRESULT: 0x80029C4A
Already DLL built and registered and com interop dll generated.
Please somebody show some light on this
Already DLL built and registered
"Registered" is the problem here, it wasn't correctly registered. This is an exception message that's generated by the CLR when it tries to locate the proxy for a .NET component that is [ComVisible]. A proxy is required to make a call to a COM component from a worker thread that doesn't do anything to help make the call thread-safe. A thread that's in the MTA, usually a thread-pool thread.
A .NET component is registered with Regasm.exe. You forgot to use the /tlb argument.
Should be simple to fix. If you still have trouble then SysInternals' Process Monitor is the weapon of choice.
I generally debug these things as you say through a console or windows forms application. You can always add logging to your web app to see what parameters are being passed to it.
Generally errors like the above are setup issues when running on a 64 bit platform and when utilizing 32 bit dlls. One thing to make sure of is that your application pool allows 32 bit applications. In IIS Manager right click on the application pool your website is running under and go to Advanced Settings->Enable 32 bit Applications. Set that to True.
You'll also need to make sure that your 32 bit dll is registered in the 32 bit registry hive. C:\Windows\syswow64\regsvr32 is the version you'll need to use to register this dll.
I have an asp.net 4.0 project that uses a combination of Bouncy Castle and the .Net framework to create an X509 certificate.
It runs properly on my W7 dev machine but when installed on W2008 (32 bit, not r2) this bit of code:
CX509CertificateRequestPkcs10 csr = new CX509CertificateRequestPkcs10();
throws this exception:
Unable to cast COM object of type 'System.__ComObject' to interface type 'CERTENROLLLib.CX509CertificateRequestPkcs10'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{728AB35B-217D-11DA-B2A4-000E7BBB2B09}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
Initially I thought it might be a 64-bit server issue since COM is only 32-bit compatible but the server is 32 bit.
The app is built using Framework 4.0 and the IIS AppPool assigned is running 4.0, Integrated mode, with an Identity of "Network Service" - all exactly as on my dev machine, as the the client browser used (IE8 32).
Does W2008-32 (Standard) not implement CERTENROLLLib out of the box? Does anyone know how to make it behave in this circumstance?
Thanks for any suggestions!
When you instantiate CX509CertificateRequestPkcs10 object specify explicitly what interface you want to use (by ProgID). In Win2008 R2 Microsoft overwrote the interface.
Instead of:
CX509CertificateRequestPkcs10 objPkcs10 = new CX509CertificateRequestPkcs10();
use:
IX509CertificateRequestPkcs10 objPkcs10 = (IX509CertificateRequestPkcs10)Activator.CreateInstance(Type.GetTypeFromProgID("X509Enrollment.CX509CertificateRequestPkcs10"));
Since in Win2008 R2 Microsoft overwrote the interface, if the code is written in Win2008 R2 the run time is looking for the new interface GUID and in regular Win2008 it can't be found because Win2008 R2 interface GUID differs from Win2008 interface Guid.
So, object can't be created, and as the result exception is thrown.
Accessing the interface by ProgID solves the issue.
See: TechNet Answer - on W2008-32 one has to specify the Interface GUID when creating the Pkcs10 object, since R2 overwrote the old "standard" interfaces.
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
I am basically a .NET guy.I don't have much knowledge in VB (COM components). Now,I come across a project where i need to expose a COM dll as a webservice and consume the same in my Asp.NET application.I hosted the webservice on my local development machine and consumed it in a test application.It works just fine.But When i host it on my production server(Server 2003).
It throws 500 internal sever error.When i looked at the stack trace,came to know that Inoke method is throwing error at the below line.
object[] results = this.Invoke("Addition", new object[] {
parameter1,parameter2});
return ((short)(results[0]));
I have registered (example.dll) using command prompt utility as below
regsvr32 c:\windows\system32\example.dll
So,Can anyone suggest me the cause for the following error?
Thanks in advance,
If you are registering a .NET dll that exposes COM interfaces you should be using REGASM instead of REGSRV32.
I am having an issue related to executing a .Net dll from a classic asp application on a 64 Bit Windows Server 2008 server running IIS7. The situation is as follows:
I have written a .Net C# assembly to perform some encryption tasks. This assembly has been made available to the classic ASP environment via inheriting from ServicedComponent, ensuring the assemblyinfo file has the ComVisible(true) attribute, and it has been installed using the "regsvcs" command line.
When testing on my own desktop (XP running IIS6) everything worked fine. When moving to IIS 7, Windows Server 2008 I get the infamous "ASP 0177 Server.CreateObject failed".
I have tried the following to no avail:
Ensuring the ASP and Script Extension features were installed on the server, as this is not the default for IIS7. This allowed me to execute simple ASP commands, but not server.createobject for the .net assembly.
Enabled 32 Bit application support for the app pool supporting the classic asp site
Used NetworkService as the identity for the app pool supporting the classic asp site
Tried registering dll using regsvr32, which failed
I am able to create other objects such as "scripting.filesystemobject"
Moving dll's to the wow64 directory and then using regsvcs to register them.
And yes when I have been executing the regsvcs commands they have been from a command line launched with "RunAs" Administrator. The regsvcs commands have registred successfully
from both the 64 and 32 bit versions. However, when used from the classic asp application, it fails.
This question is closely related to this one. However, I think this question was more related to using tools on the server as opposed to a programatic problem similiar to mine.
Anyone have any more ideas to try?
After a lot of help here and some more research, we finally came across the answer. To solve our issue we did the following:
No longer inherit from ServiceComponent (This is ok, since we are not actually leveraging any specific COM+ features)
Utilized the following commands to install the component, which must be done in order:
gacutil /i "C:\Inetpub\wwwroot\ASPTest*name of dll*"
regasm /tlb "C:\Inetpub\wwwroot\ASPTest*name of dll*"
This process eliminated the original errors and also had the added benefit of being able to replace the dll while IIS is running.
Try this
Component Services -> Computers -> My Computer -> COM+ Applications
Open a COM+ Application object.
Open Components.
Right-click on a class and select Properties.
Under "Advanced" there is a check box for "Allow IIS intrinsic properties".
It works for me
Create a vbs test file and try to create your COM object there. If you can't (i.e. you get the same error) then your component is not registered correctly.
If you can - then it was installed correctly and the problem is with the lack of permissions for the account your application is executed under in IIS.