Hi Sam,

Thanks for your posting. As for the COBOL dll you mentioned, is it a pure
Managed dll( CLS compatible) or a unmanaged one( win32 or COM dll)?

If it's a unmanaged dll, we need to call it via InteropService. If this is
a COM dll, we can generate the managed Wrapper class for it( through VS.NET
or the tlbimp.exe tool). The wrapper class (just the RCW ) is pure managed
classes which can be called as strong-typed component in .net code.

Please feel free to let me know if you have any further concerns.
Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Hi all.

I have a Web Service that I'm writing that needs to reference a VB.NET dll.
The catch is that the VB.NET dll has a dependency on a COBOL dll which I
can't load in my development environment (not a COBOL programmer), so when I
try to build a setup project for the Web Service I run into problems because
all the dependencies can't be imported.

Does anyone have suggestions on how I might get around this?

I was wondering if there is a way to use Interfaces (although I don't want
to use remoting, as dll dependencies will be on the same machine after
deployment), can Runtime Callable Wrappers be used? I don't necessarily want
to use the late binding CreateObject as that would be a bit of a hack and
I'm sure there's a way to do this.

Any help appreciated.

Sam.

Hi Sam,

Thanks for your response. OK, I see that your COBOL components are located
on a remote machine and your webservice is developed( also deploy) at
another machine which dosn't have COBOL enviorment. Then, I think we could
only use some remote method invoking mechanism since your develop or deploy
machine for the webservice won't have the COBOL runtime. In .net , there're
serveral approachs:

1. Use .net remoting

2. Still use a webservice to expose the remote COBOL component

3. Configure the COBOL component as a COM+ component and use the
ServicedComponent to access the COM+ on the COBOL machine.

Anyway, the 1,2 still need us to define some common interface classes
which the COBOL wrapper implement so that your webservice application can
compile with the interface classes.
As for the COM+ approach, we need to install the COM+ client proxy exposed
by the COBOL machine when generate the COM+ components. And .net 's
ServicedComponent provide simplified interfaces for calling COM+ components.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Hi Steven. The problem isn't so much me calling the COBOL dll, but that I
can't reference a VB.NET dll that has it as a dependency. We have a
subsidiary company that uses COBOL and in order to call into their
applications we've had them write a VB.NET wrapper around several of their
business functions. When I try to reference the VB.NET dll in my Web Service
it tries to pull the COBOL dependencies in to my project, but obviously
can't find them as they can't run on my non-COBOL development machine.
Ideally what I want to do is perhaps reference some kind of interface that I
can compile against, that at runtime knows to hook into the VB.NET dll on
the destination server. Can this be done without remoting?

In the short term I'm sending them the code to the Web Service to compile in
their development environment that contains all relevant dependencies and
have them bundle it up and deploy, but in the future I would like to be able
to maintain and extend the Web Service from my end without all these
referencing issues.

Regards,

Sam.


[quoted text, click to view]