[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Named Pipes across VS6 and .Net

=?Utf-8?B?cm9kY2hhcg==?=

7/23/2004 7:36:00 AM

Hi
Can anyone suggest a work around for using named pipes to
send data from a dev studio 6 app to a .net app, where the
dev studio app is the server using CreateNamedPipe() and
ConnectNamedPipe() methods and the .Net app is the client,
using something other than inter process connection
techniques as the two methods across a network are
incompatible.

Thanks
Natasha
5 Answers

Jay B. Harlow [MVP - Outlook]

7/23/2004 2:36:00 PM

0

Natasha,
Are you having a problem with named pipes? Or are you trying to avoid named
pipes?

If you are trying to avoid named pipes:
- You could use web services & the SOAP toolkit.
- You could use sockets with TCP/IP
- You could use MSMQ

To name just a few alternatives.

Hope this helps
Jay


"Natasha" <anonymous@discussions.microsoft.com> wrote in message
news:2a3601c47087$c057c550$a501280a@phx.gbl...
> Hi
> Can anyone suggest a work around for using named pipes to
> send data from a dev studio 6 app to a .net app, where the
> dev studio app is the server using CreateNamedPipe() and
> ConnectNamedPipe() methods and the .Net app is the client,
> using something other than inter process connection
> techniques as the two methods across a network are
> incompatible.
>
> Thanks
> Natasha
>

=?Utf-8?B?cm9kY2hhcg==?=

7/26/2004 12:38:00 PM

0

Hi
I am trying to use named pipes, trying avoid the
alternatives really, but thanks anyway. The problem is
occuring becuase I am trying to use named pipes across 2
different platforms have different implementations for
named pipes, i.e. dev studio 6 and .net, across a network
Natasha ;-)
>-----Original Message-----
>Natasha,
>Are you having a problem with named pipes? Or are you
trying to avoid named
>pipes?
>
>If you are trying to avoid named pipes:
>- You could use web services & the SOAP toolkit.
>- You could use sockets with TCP/IP
>- You could use MSMQ
>
>To name just a few alternatives.
>
>Hope this helps
>Jay
>
>
>"Natasha" <anonymous@discussions.microsoft.com> wrote in
message
>news:2a3601c47087$c057c550$a501280a@phx.gbl...
>> Hi
>> Can anyone suggest a work around for using named pipes
to
>> send data from a dev studio 6 app to a .net app, where
the
>> dev studio app is the server using CreateNamedPipe() and
>> ConnectNamedPipe() methods and the .Net app is the
client,
>> using something other than inter process connection
>> techniques as the two methods across a network are
>> incompatible.
>>
>> Thanks
>> Natasha
>>
>
>
>.
>

Jay B. Harlow [MVP - Outlook]

7/26/2004 2:05:00 PM

0

Natasha,
Having 2 implementations for named pipes is why I would use named pipes!

Unfortunately I have not used named pipes yet...

This newsgroup is really for questions on .NET remoting, you may have better
luck "down the hall" in the microsoft.public.dotnet.framework.interop
newsgroup, as using named pipes will require interop. And you need to make
sure you have valid VB6 declares, valid VB.NET declares (they are different
as the size of Integer change from VB6 to VB.NET). Then you need to be
certain you write the information in a compatible format, I would consider
XML, however as I stated I have not used named pipes yet.

I would probably create a VB6 program that read & wrote data to the named
pipes to make sure it works, first on a single machine, then on two
machines. Next I would create a VB.NET program that read & wrote data to the
named pipes to make sure it works, again first on a single machine, then on
two machines. Finally I would try VB6 to VB.NET over named pipes, first on a
single machine then on two machines... Just to limit the variables on
getting things to work.

I did a quick search I did not see any obvious samples...

I'm not sure if VS.NET 2005 (Whidbey, due out in 2005) will have support for
Named Pipes or not. I not seeing anything obvious at
http://lab.msdn.microsoft.c...

Hope this helps
Jay



"Natasha" <anonymous@discussions.microsoft.com> wrote in message
news:400301c4730d$6506cc90$a601280a@phx.gbl...
> Hi
> I am trying to use named pipes, trying avoid the
> alternatives really, but thanks anyway. The problem is
> occuring becuase I am trying to use named pipes across 2
> different platforms have different implementations for
> named pipes, i.e. dev studio 6 and .net, across a network
> Natasha ;-)
> >-----Original Message-----
> >Natasha,
> >Are you having a problem with named pipes? Or are you
> trying to avoid named
> >pipes?
> >
> >If you are trying to avoid named pipes:
> >- You could use web services & the SOAP toolkit.
> >- You could use sockets with TCP/IP
> >- You could use MSMQ
> >
> >To name just a few alternatives.
> >
> >Hope this helps
> >Jay
> >
> >
> >"Natasha" <anonymous@discussions.microsoft.com> wrote in
> message
> >news:2a3601c47087$c057c550$a501280a@phx.gbl...
> >> Hi
> >> Can anyone suggest a work around for using named pipes
> to
> >> send data from a dev studio 6 app to a .net app, where
> the
> >> dev studio app is the server using CreateNamedPipe() and
> >> ConnectNamedPipe() methods and the .Net app is the
> client,
> >> using something other than inter process connection
> >> techniques as the two methods across a network are
> >> incompatible.
> >>
> >> Thanks
> >> Natasha
> >>
> >
> >
> >.
> >

=?Utf-8?B?cm9kY2hhcg==?=

7/26/2004 2:48:00 PM

0

Hi
Thanks very much for your help, but I am writing in C++
not VB, I don't know VB.
Thanks,
I'll try it in C++ anyhow.
caio
Natasha
>-----Original Message-----
>Natasha,
>Having 2 implementations for named pipes is why I would
use named pipes!
>
>Unfortunately I have not used named pipes yet...
>
>This newsgroup is really for questions on .NET remoting,
you may have better
>luck "down the hall" in the
microsoft.public.dotnet.framework.interop
>newsgroup, as using named pipes will require interop. And
you need to make
>sure you have valid VB6 declares, valid VB.NET declares
(they are different
>as the size of Integer change from VB6 to VB.NET). Then
you need to be
>certain you write the information in a compatible format,
I would consider
>XML, however as I stated I have not used named pipes yet.
>
>I would probably create a VB6 program that read & wrote
data to the named
>pipes to make sure it works, first on a single machine,
then on two
>machines. Next I would create a VB.NET program that read
& wrote data to the
>named pipes to make sure it works, again first on a
single machine, then on
>two machines. Finally I would try VB6 to VB.NET over
named pipes, first on a
>single machine then on two machines... Just to limit the
variables on
>getting things to work.
>
>I did a quick search I did not see any obvious samples...
>
>I'm not sure if VS.NET 2005 (Whidbey, due out in 2005)
will have support for
>Named Pipes or not. I not seeing anything obvious at
>http://lab.msdn.microsoft.c...
>
>Hope this helps
>Jay
>
>
>
>"Natasha" <anonymous@discussions.microsoft.com> wrote in
message
>news:400301c4730d$6506cc90$a601280a@phx.gbl...
>> Hi
>> I am trying to use named pipes, trying avoid the
>> alternatives really, but thanks anyway. The problem is
>> occuring becuase I am trying to use named pipes across 2
>> different platforms have different implementations for
>> named pipes, i.e. dev studio 6 and .net, across a
network
>> Natasha ;-)
>> >-----Original Message-----
>> >Natasha,
>> >Are you having a problem with named pipes? Or are you
>> trying to avoid named
>> >pipes?
>> >
>> >If you are trying to avoid named pipes:
>> >- You could use web services & the SOAP toolkit.
>> >- You could use sockets with TCP/IP
>> >- You could use MSMQ
>> >
>> >To name just a few alternatives.
>> >
>> >Hope this helps
>> >Jay
>> >
>> >
>> >"Natasha" <anonymous@discussions.microsoft.com> wrote
in
>> message
>> >news:2a3601c47087$c057c550$a501280a@phx.gbl...
>> >> Hi
>> >> Can anyone suggest a work around for using named
pipes
>> to
>> >> send data from a dev studio 6 app to a .net app,
where
>> the
>> >> dev studio app is the server using CreateNamedPipe()
and
>> >> ConnectNamedPipe() methods and the .Net app is the
>> client,
>> >> using something other than inter process connection
>> >> techniques as the two methods across a network are
>> >> incompatible.
>> >>
>> >> Thanks
>> >> Natasha
>> >>
>> >
>> >
>> >.
>> >
>
>
>.
>

Jay B. Harlow [MVP - Outlook]

7/26/2004 3:15:00 PM

0

Natasha,
Doh! I miss read VS6 for VB6.

Are you doing Managed C++ or Unmanaged C++?

Not that it matters as how you use the Named Pipes in C++ is going to remain
the same, as there is no Managed Named Pipes yet.

Your VS6 C++, Managed C++ & Unmanaged C++ code should be identical for named
pipes, as they are all Win32 API calls.

In addition (or possible instead of)
microsoft.public.dotnet.framework.interop, you may want to consider the
microsoft.public.dotnet.languages.vc newsgroup.

Hope this helps
Jay

"Natasha" <anonymous@discussions.microsoft.com> wrote in message
news:41ee01c4731f$86c7d4c0$a601280a@phx.gbl...
> Hi
> Thanks very much for your help, but I am writing in C++
> not VB, I don't know VB.
> Thanks,
> I'll try it in C++ anyhow.
> caio
> Natasha
> >-----Original Message-----
> >Natasha,
> >Having 2 implementations for named pipes is why I would
> use named pipes!
> >
> >Unfortunately I have not used named pipes yet...
> >
> >This newsgroup is really for questions on .NET remoting,
> you may have better
> >luck "down the hall" in the
> microsoft.public.dotnet.framework.interop
> >newsgroup, as using named pipes will require interop. And
> you need to make
> >sure you have valid VB6 declares, valid VB.NET declares
> (they are different
> >as the size of Integer change from VB6 to VB.NET). Then
> you need to be
> >certain you write the information in a compatible format,
> I would consider
> >XML, however as I stated I have not used named pipes yet.
> >
> >I would probably create a VB6 program that read & wrote
> data to the named
> >pipes to make sure it works, first on a single machine,
> then on two
> >machines. Next I would create a VB.NET program that read
> & wrote data to the
> >named pipes to make sure it works, again first on a
> single machine, then on
> >two machines. Finally I would try VB6 to VB.NET over
> named pipes, first on a
> >single machine then on two machines... Just to limit the
> variables on
> >getting things to work.
> >
> >I did a quick search I did not see any obvious samples...
> >
> >I'm not sure if VS.NET 2005 (Whidbey, due out in 2005)
> will have support for
> >Named Pipes or not. I not seeing anything obvious at
> >http://lab.msdn.microsoft.c...
> >
> >Hope this helps
> >Jay
> >
> >
> >
> >"Natasha" <anonymous@discussions.microsoft.com> wrote in
> message
> >news:400301c4730d$6506cc90$a601280a@phx.gbl...
> >> Hi
> >> I am trying to use named pipes, trying avoid the
> >> alternatives really, but thanks anyway. The problem is
> >> occuring becuase I am trying to use named pipes across 2
> >> different platforms have different implementations for
> >> named pipes, i.e. dev studio 6 and .net, across a
> network
> >> Natasha ;-)
> >> >-----Original Message-----
> >> >Natasha,
> >> >Are you having a problem with named pipes? Or are you
> >> trying to avoid named
> >> >pipes?
> >> >
> >> >If you are trying to avoid named pipes:
> >> >- You could use web services & the SOAP toolkit.
> >> >- You could use sockets with TCP/IP
> >> >- You could use MSMQ
> >> >
> >> >To name just a few alternatives.
> >> >
> >> >Hope this helps
> >> >Jay
> >> >
> >> >
> >> >"Natasha" <anonymous@discussions.microsoft.com> wrote
> in
> >> message
> >> >news:2a3601c47087$c057c550$a501280a@phx.gbl...
> >> >> Hi
> >> >> Can anyone suggest a work around for using named
> pipes
> >> to
> >> >> send data from a dev studio 6 app to a .net app,
> where
> >> the
> >> >> dev studio app is the server using CreateNamedPipe()
> and
> >> >> ConnectNamedPipe() methods and the .Net app is the
> >> client,
> >> >> using something other than inter process connection
> >> >> techniques as the two methods across a network are
> >> >> incompatible.
> >> >>
> >> >> Thanks
> >> >> Natasha
> >> >>
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >