Leveraging RPC IDL file

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Folks,

For our RPC server, is there some method, tool that will allow me to
take the RPC Server IDL to create .NET assembly or equivalent "IDL"?

Of course, the MIDL create rpc client stub files. Anything that will
create .NET client stubs?

thx

---
 
Hi Mike,
For our RPC server, is there some method, tool that will allow me to
take the RPC Server IDL to create .NET assembly or equivalent "IDL"?

Of course, the MIDL create rpc client stub files. Anything that will
create .NET client stubs?
Click to expand...

You can use midl to create a tlb file from your idl and then use
tlbimp to create a .net wrapper or just use "Add Reference" from
Visual Studio and browse for the tlb file.
 
SvenC said:
Hi Mike,


You can use midl to create a tlb file from your idl and then use
tlbimp to create a .net wrapper or just use "Add Reference" from
Visual Studio and browse for the tlb file.
Click to expand...

You kidding? Going to have to try this.

Thanks

--
 
Mike said:
You kidding? Going to have to try this.
Click to expand...


....assuming that it's really a {D}COM interface and not a true RPC
interface, and that the interfaces are automation compatible, then yes, the
above procedure should work.

If either of the above is not the case, then your best bet to get a .NET
client might be to write a COM-callable wrapper for your RPC interface that
is in fact automation compatible so that you can then use tlbimp on those
COM interface to expose it to .NET.

Alternatively, you may be able to compile the rpc client stub files into a
DLL and then use P-Invoke to call into that DLL from .NET.

Yet another alternative, write a C++/CLI wrapper that exposes a managed
interface and calls through your compiled RPC client library.

-cd
 
Carl said:
...assuming that it's really a {D}COM interface and not a true RPC
interface, and that the interfaces are automation compatible, then yes, the
above procedure should work.
Click to expand...

Figured that was the case (SvenC was probably thinking DCOM).

No, this is a real old school DCE RPC interface.
If either of the above is not the case, then your best bet to get a .NET
client might be to write a COM-callable wrapper for your RPC interface that
is in fact automation compatible so that you can then use tlbimp on those
COM interface to expose it to .NET.

Alternatively, you may be able to compile the rpc client stub files into a
DLL and then use P-Invoke to call into that DLL from .NET.

Yet another alternative, write a C++/CLI wrapper that exposes a managed
interface and calls through your compiled RPC client library.
Click to expand...

Yes, I have this. A 3rd party VB developer wrote the .NET modules.
(http://www.winserver.com/public/wcsdk)

I'm just getting into .NET. Over 250+ functions, but a number of them
is not straight forward interop mapping. For true RPC it is, not
for .NET though. I'm currently working on a class wrapper to handle
the more complex functional interface.

Anyway, I was thinking, more out of curiosity, if this was not already
done - A RPC IDL to .NET helper conversion tool. I guess I can write
one by reading the IDL/APC files and auto creating .NET DLLImport
statements. Just surprise this wasn't done or why this need isn't
more common.

Thanks Craig.

--
 
Hi Mike, Hi Daniel

Mike said:
Figured that was the case (SvenC was probably thinking DCOM).

No, this is a real old school DCE RPC interface.
Click to expand...

Correct, I was only thinking about (D)COM idl files.
Sorry for the confusion.
 
Mike said:
Anyway, I was thinking, more out of curiosity, if this was not already
done - A RPC IDL to .NET helper conversion tool. I guess I can write
one by reading the IDL/APC files and auto creating .NET DLLImport
statements. Just surprise this wasn't done or why this need isn't
more common.
Click to expand...

I suspect it's because old-school RPC is a pretty rare beast these days, at
least on Windows. Your helper tool idea sounds cool - maybe something you
could put up on codeplex (or code sharing site of your choice). Surely
there must be others with RPC servers looking to write managed clients.

-cd
 
Carl said:
I suspect it's because old-school RPC is a pretty rare beast these days, at
least on Windows. Your helper tool idea sounds cool - maybe something you
could put up on codeplex (or code sharing site of your choice). Surely
there must be others with RPC servers looking to write managed clients.
Click to expand...

Right, I should of said "why this need *WASN'T* more common" i.e. at
least back when .NET first came out (2003?) where they would be more
of the older RPC servers still in play. Ours was just very stable,
predated DCOM, started as a "Interactive NET Server" with it own
embedded language, its own discovery concept itself and with several
thousand critical mission installations, there was never a critical
need to "change it" for the sake of "change." Plus it was uncertain
period for us, wasn't too sure if a major revamp would remain with
windows. That mid-life crisis is over now. :-) So we are late to .NET
:-) The move now is to better scale the system, leverage hardware and
OS technology (i.e, VSS), and add .NET support to the SDK.

I'll took a shot at converter tool.

Thanks.

--
 
Mike said:
Right, I should of said "why this need *WASN'T* more common" i.e. at
least back when .NET first came out (2003?) where they would be more
of the older RPC servers still in play. Ours was just very stable,
predated DCOM, started as a "Interactive NET Server" with it own
embedded language, its own discovery concept itself and with several
thousand critical mission installations, there was never a critical
need to "change it" for the sake of "change." Plus it was uncertain
period for us, wasn't too sure if a major revamp would remain with
windows. That mid-life crisis is over now. :-) So we are late to .NET
:-) The move now is to better scale the system, leverage hardware and
OS technology (i.e, VSS), and add .NET support to the SDK.

I'll took a shot at converter tool.
Click to expand...

By the way, if you're not opposed to writing managed code for the convertor
tool, you might look into the "Common Compiler Infrastructure" projects on
Codeplex. They provide a lot of "compiler guts" based on work from
Microsoft Reseach. You might also look into "M" - the "Modelling language"
that's part of "Oslo". Without getting into what "Oslo" may or may not be
good for, "M" looks like it could be a decent language for writing parsers -
at it's core, that's really what M appears to be.

-cd
 
Carl said:
I'll [take] a shot at converter tool.
Click to expand...

By the way, if you're not opposed to writing managed code for the convertor
tool, you might look into the "Common Compiler Infrastructure" projects on
Codeplex. They provide a lot of "compiler guts" based on work from
Microsoft Reseach. You might also look into "M" - the "Modelling language"
that's part of "Oslo". Without getting into what "Oslo" may or may not be
good for, "M" looks like it could be a decent language for writing parsers -
at it's core, that's really what M appears to be.
Click to expand...

Ok, thanks for the excellent info.

Looks like any good string parser tool can do the job. I never used
the MIDL /use_epv switch before which I just explored and it created a
good clean layout that one might easily parse too. I already other
CPP2[pick language].exe tools which takes our *.H files and creates
prototype files for the language The last one I did was for PHP and
this time around, it created a meta XML file and from there PHP
marshalling code. This is what triggered the idea if there wasn't a
predefined IDL meta file conversion/translater tool already so I don't
have to write a CPP2NET converter. :-)

But right now I am catching up and learning the marshalling
requirements for CLI. I learned how to use .NET delegate for
callbacks from unmanaged wire handling.

--
 
Back
Top