Application Center Usage - Error distributing a vb com+ object with soap toolkit reference

Author

Error distributing a vb com+ object with soap toolkit reference

newsgroup user

2004-02-08, 8:45 am

AC Fails whe it tries to distribute a vb object registered in COM+.
The object implements IHeaderHandler from the soap toolkit dll (MSSOAP1.dll version 1.2.813.0).
No problem installing the dll on the staging server or destination server manually.

The error is:
__CLASS:
MicrosoftAC_Replication_Session_DriverEv
ents_Complus_Object
error_Event
__SERVER: ServerName
ServerGUID: {DB2BEE7C-85BC-4E27-8684-6238CE70E24F}
Category: Replication
DriverID: COM
EventId: 5154
GUID: {416009F7-1AEE-44D5-B532-C2AD545EC192}
key: C:\AppPath\MSSOAP1.dll
Path: C:\AppPath\MSSOAP1.dll
ReplicationID: 14:05:29 01/15/04
ReplicationJobID: StagingServerNameX1074171964X462935X13a1
bd8
Status: 0x80110425
StatusMessage: The DLL could not be loaded
SubCategory: Session
TimeGenerated: 1/15/2004 1:16:02 PM
Type: 1
DisplayName: Replication Session DriverEvents
ComplusObjectError

The problem seems to be that the soap dll is searched in the application path and not the installation one (the default C:\Program Files\Common Files\MSSoap\Binaries\MSSOAP1.dll)

We have ACSP2 installed on windows2000 advanced serversp4.

Thanks in advance for any help
Carlo Folini

WenJun Zhang[msft]

2004-02-08, 8:45 am

Hi Carlo,

I simply created a new COM+ app, installed this MSSOAP1.dll in it and
then replicate this COM+ app. This succeeded in reproducing the error
you met:
"
1/19/2004 3:57:09 PM APPCENT2 5154

Application Center
Source: Replication Session

An object level error occurred while accessing COM+ catalog for path
C:\Program Files\Common Files\MSSoap\Binaries\MSSOAP1.dll. Session:
COMReplicationTEST02 15:54:51 01/19/04, Job:
APPCENT1X1074498916X555370X4af918, Status: 0x80110425 The DLL could
not be loaded
"

Please note the path in my situation is correct. This means the error
probably isn't caused by invalid path but the MSSOAP1.dll cannot be
packaged in a .msi and installed individually. Although the
replication task was failed, I noticed a SOAPISAP.dll had already
been copied to the destination path: My node2's \Program Files\Common
Files\MSSoap\Binaries . Also, manually regsvr32 MSSOAP1.dll on a
clear system and I got "A dynamic link library (DLL) initialization
routine failed" error.

So I think the problem is still mostly like that the MSSOAP1.dll has
some dependent DLLs need to be previously registered.

For further troubleshooting, maybe we can launch Dependency Walker in
VS 6.0 to check this SOAPISAP.dll and find all its dependences. After
that, add these DLLs to your COM+ App and test the replication again.
However, I personally think installing SOAP Toolkit on every nodes
might be a more recommended and convenient solution on this issue
because it isn't a custom DLL. What's your thought of this?

Let me know if you have any concerns. It's always our pleasure to be
of assistance.

Have a nice day,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

newsgroup user

2004-02-08, 8:45 am

Hi,
we already installed the soap toolkit directly on each node.
We look in the dependency walker (ver 1.0), but it seems that the reference we added to "Microsoft Soap Type Library" isn't listed by the tool (also on my developing machine).
We have also other references (with which we had no problem) that aren't listed in dependency walker (for example "COM+ Services Type Library" COMSVCS.DLL)

Thanks for your help
CArlo

WenJun Zhang[msft]

2004-02-08, 8:45 am

Hi Carlo,

Has this MSSOAP1.dll still been included in your VB com+ package?
Since the Toolkit has been manually installed on every node, these
refered DLLs should have been properly registered, removing them from
this COM+ package and only replicating your VB components, would this
work?

I've met such kind of situation that DLL isn't showed in dependency
walker but is refered in the process of component register. Using
filemon to trace 'regsvr32 MSSOAP1.dll' and I found it had ever
accessed \MSSoap\Binaries\Resources\1033\MSSOAPR.dll , which means
MSSOAPR is MSSOAP1's linked dll.

I then copy the MSSOAP1.dll and Resources\1033\MSSOAPR.dll to a clear
installed system. Regsvr32 MSSOAP1.dll directly and succeeded.(It
will go to Resources\1033 folder to find MSSOAPR.dll)

Regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

Steve Miller

2004-02-08, 8:45 am

msdn@gcv.com <anonymous@discussions.microsoft.com> wrote in message news:<5E59E0B7-526A-410C-AC4B-845A57632BA8@microsoft.com>...
> Hi,
> we already installed the soap toolkit directly on each node.
> We look in the dependency walker (ver 1.0), but it seems that the reference we added to "Microsoft Soap Type Library" isn't listed by the tool (also on my developing machine).

You have added a dynamic dependency. They don't show up in the import
table and therefore Dependency Walker 1.0 will not see them.
Dependency Walker 2.0 and beyond will detect these if you use its
"profile" feature. You can find the latest at...

http://www.dependencywalker.com

- Steve

newsgroup user

2004-02-08, 8:45 am

Hi,
also with dependency walker 2.1 I still can't see mssoap1.dll reference.

Carlo

newsgroup user

2004-02-08, 8:45 am

Hi,
no MSSOAP1.dll is only referenced by the vb project (same as COMSVCS.DLL).
What I do in the vb program is only to implement the IHeaderHandler ot this dll.

The MSSAOP1.dll is correctly registered by the toolkit installation program.
Infact registering my dll manually in com+ works fine, only the ac replication fails.

Carlo

Steve Miller

2004-02-08, 8:45 am

"msdn@gcv.it" <anonymous@discussions.microsoft.com> wrote in message news:<E24A9E60-3BDF-490B-B0AD-4FB45505F8BC@microsoft.com>...
> Hi,
> also with dependency walker 2.1 I still can't see mssoap1.dll reference.
>
> Carlo

Did you profile your application in Dependency Walker? Choose "Start
Profiling" from the "Profile" menu. Profiling runs your applications
and catches every module it loads. It guarantees to catch everything
that loads, so if mssoap1.dll doesn't show up, then mssoap1.dll did
not load. It doesn't mean that mssoap1.dll is not a dependency or
would never load during a future run, but it does guarantee that if
mssoap1.dll had loaded, it would have caught it.

The Dependency Walker help file has lots of help about profiling and
type of dependencies.

newsgroup user

2004-02-08, 8:46 am

Hi,
the profile menu entries aren't enabled, maybe because I'm working on a dll.
To profile the application there should be some "Wait for components to be created"

Carlo