[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Accessing C# Singleton with VB6

Norvin Laudon

6/15/2004 6:31:00 PM

Hi,

I need to access a C# singleton object, from a VB6 application (to save
porting the entire VB6 app over to C#). The singleton object is hosted on a
remote server using the following code:

machineServer = new MachineServer();
RemotingServices.Marshal(machineServer, "MachineServerTarget");

As far as I understand, there are 2 ways I can go about this:

1. Create a C# managed DLL which uses remoting to access the singleton. The
VB6 client would then use the DLL to pass data back and forth between the
singleton. I believe this requires that I use regasm.exe to generate the
COM-compatible registry entries for the managed DLL. Sounds _ugly_ to
deploy.

2. Directly access the singleton with the VB6 client.

Provided I'm understanding everything correctly, are there any other
options? If not, I like option 2.

Anybody have simple examples of calling methods, returning values, on a
remoting singleton from VB6?

Thanks,
Norvin



3 Answers

Sunny

6/15/2004 7:39:00 PM

0

Hi,

my preference will be option 1, as it requires less changes at VB6 side.

The option 2: you will be able to do this, if you are using soap
formatter, but then you have to create and decode all the messages by
yourself.

If someone have created something like this, I would be surprised if it
is build in VB6 only, so most probably it will lead you somehow to
option 1.

And, there is an option 3. You may double expose your remote object -
remoting for your .net clients, and web services for all others. If I''m
not wrong, there is a SOAP API which can be used from VB6.

Sunny


In article <OGN0gbwUEHA.2692@TK2MSFTNGP09.phx.gbl>,
nospamnorvinll@molinospamenergy.com says...
> Hi,
>
> I need to access a C# singleton object, from a VB6 application (to save
> porting the entire VB6 app over to C#). The singleton object is hosted on a
> remote server using the following code:
>
> machineServer = new MachineServer();
> RemotingServices.Marshal(machineServer, "MachineServerTarget");
>
> As far as I understand, there are 2 ways I can go about this:
>
> 1. Create a C# managed DLL which uses remoting to access the singleton. The
> VB6 client would then use the DLL to pass data back and forth between the
> singleton. I believe this requires that I use regasm.exe to generate the
> COM-compatible registry entries for the managed DLL. Sounds _ugly_ to
> deploy.
>
> 2. Directly access the singleton with the VB6 client.
>
> Provided I''m understanding everything correctly, are there any other
> options? If not, I like option 2.
>
> Anybody have simple examples of calling methods, returning values, on a
> remoting singleton from VB6?
>
> Thanks,
> Norvin
>
>
>
>

Norvin Laudon

6/15/2004 9:06:00 PM

0

Hi Sunny,

I''d like to stay away from SOAP formatters, if possible. So I agree that
"Option 1", to have the VB6 program use a managed C# DLL which uses remoting
to access the singleton, might be best.

Given that, what is the easiest way to deploy a managed c# dll, and generate
the COM compatible registry entries so a VB app can use it?
Is there a way to automatically generate the registry entries? Without
having to manually use regasm.exe?

Thanks,
Norvin


"Sunny" <sunnyask@icebergwireless.com> wrote in message
news:eIehjBxUEHA.384@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> my preference will be option 1, as it requires less changes at VB6 side.
>
> The option 2: you will be able to do this, if you are using soap
> formatter, but then you have to create and decode all the messages by
> yourself.
>
> If someone have created something like this, I would be surprised if it
> is build in VB6 only, so most probably it will lead you somehow to
> option 1.
>
> And, there is an option 3. You may double expose your remote object -
> remoting for your .net clients, and web services for all others. If I''m
> not wrong, there is a SOAP API which can be used from VB6.
>
> Sunny
>
>
> In article <OGN0gbwUEHA.2692@TK2MSFTNGP09.phx.gbl>,
> nospamnorvinll@molinospamenergy.com says...
> > Hi,
> >
> > I need to access a C# singleton object, from a VB6 application (to save
> > porting the entire VB6 app over to C#). The singleton object is hosted
on a
> > remote server using the following code:
> >
> > machineServer = new MachineServer();
> > RemotingServices.Marshal(machineServer, "MachineServerTarget");
> >
> > As far as I understand, there are 2 ways I can go about this:
> >
> > 1. Create a C# managed DLL which uses remoting to access the singleton.
The
> > VB6 client would then use the DLL to pass data back and forth between
the
> > singleton. I believe this requires that I use regasm.exe to generate the
> > COM-compatible registry entries for the managed DLL. Sounds _ugly_ to
> > deploy.
> >
> > 2. Directly access the singleton with the VB6 client.
> >
> > Provided I''m understanding everything correctly, are there any other
> > options? If not, I like option 2.
> >
> > Anybody have simple examples of calling methods, returning values, on a
> > remoting singleton from VB6?
> >
> > Thanks,
> > Norvin
> >
> >
> >
> >


Sunny

6/15/2004 9:27:00 PM

0

You can use RegistrationServices class from any C#/VB.Net program. what
you need is to create a setup project in VS.Net and include it with your
setup. The steps to include custom actions are documented in MSDN.

Also, if you read MSDN topic "Registering Assemblies with COM" there are
details what is put in the registry.

Sunny


In article <ekg#OyxUEHA.2844@TK2MSFTNGP12.phx.gbl>,
nospamnorvinll@molinospamenergy.com says...
> Hi Sunny,
>
> I''d like to stay away from SOAP formatters, if possible. So I agree that
> "Option 1", to have the VB6 program use a managed C# DLL which uses remoting
> to access the singleton, might be best.
>
> Given that, what is the easiest way to deploy a managed c# dll, and generate
> the COM compatible registry entries so a VB app can use it?
> Is there a way to automatically generate the registry entries? Without
> having to manually use regasm.exe?
>
> Thanks,
> Norvin
>
>
> "Sunny" <sunnyask@icebergwireless.com> wrote in message
> news:eIehjBxUEHA.384@TK2MSFTNGP10.phx.gbl...
> > Hi,
> >
> > my preference will be option 1, as it requires less changes at VB6 side.
> >
> > The option 2: you will be able to do this, if you are using soap
> > formatter, but then you have to create and decode all the messages by
> > yourself.
> >
> > If someone have created something like this, I would be surprised if it
> > is build in VB6 only, so most probably it will lead you somehow to
> > option 1.
> >
> > And, there is an option 3. You may double expose your remote object -
> > remoting for your .net clients, and web services for all others. If I''m
> > not wrong, there is a SOAP API which can be used from VB6.
> >
> > Sunny
> >
> >
> > In article <OGN0gbwUEHA.2692@TK2MSFTNGP09.phx.gbl>,
> > nospamnorvinll@molinospamenergy.com says...
> > > Hi,
> > >
> > > I need to access a C# singleton object, from a VB6 application (to save
> > > porting the entire VB6 app over to C#). The singleton object is hosted
> on a
> > > remote server using the following code:
> > >
> > > machineServer = new MachineServer();
> > > RemotingServices.Marshal(machineServer, "MachineServerTarget");
> > >
> > > As far as I understand, there are 2 ways I can go about this:
> > >
> > > 1. Create a C# managed DLL which uses remoting to access the singleton.
> The
> > > VB6 client would then use the DLL to pass data back and forth between
> the
> > > singleton. I believe this requires that I use regasm.exe to generate the
> > > COM-compatible registry entries for the managed DLL. Sounds _ugly_ to
> > > deploy.
> > >
> > > 2. Directly access the singleton with the VB6 client.
> > >
> > > Provided I''m understanding everything correctly, are there any other
> > > options? If not, I like option 2.
> > >
> > > Anybody have simple examples of calling methods, returning values, on a
> > > remoting singleton from VB6?
> > >
> > > Thanks,
> > > Norvin
> > >
> > >
> > >
> > >
>
>
>