Can a .NET Web Service be accessed from a VB6 Client?

  • Thread starter Thread starter John Kotuby
  • Start date Start date
J

John Kotuby

I am expecting the answer to be, "of course not" or " are you kidding?", but
maybe (hopefully) I am wrong and somebody can point me to an ingenious
example of how the impossible just takes a little more work.

TIA
 
John,

Just to clarify adm answer for others who are looking to your question: I
wanted to write, "have a look at SOAP on MSDN", but adm is providing you the
link to that.

Cor
 
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems with it
to deploy it to my end users so in the end
i used the post and get methods of the webservice instead of soap

wich in the end turned out to be a much cleaner solution

also remebre that you can only use so called "simple" data types

regards

Michel Posseth [MCP]
 
Thanks Michael,
I appreciate the warning about the soap toolkit approach. I will look into
the HTTP Get and Post methods for eliciting a Web Service response.

Michel Posseth said:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems with it
to deploy it to my end users so in the end
i used the post and get methods of the webservice instead of soap

wich in the end turned out to be a much cleaner solution

also remebre that you can only use so called "simple" data types

regards

Michel Posseth [MCP]


John Kotuby said:
I am expecting the answer to be, "of course not" or " are you kidding?",
but maybe (hopefully) I am wrong and somebody can point me to an ingenious
example of how the impossible just takes a little more work.

TIA
 
Michel said:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems with it
to deploy it to my end users so in the end

i could be entirely wrong about this, but I think you MIGHT be able to
build a client app without deploying the SOAP toolkit to your end
users. I used the Office 2003 SOAP Toolkit to create a proxy class in
an Access ADP, then ran that ADP on a computer with a fresh install of
Windows XP SP2 and MSXML 6 (i think), and it was able to access the Web
Service just fine, without the toolkit being installed (as far as I
know). Not sure if this will similarly work in VB6, but it might, and
it's definitely worth testing.
also remember that you can only use so called "simple" data types

True, but you can serialize a complex data type to a "simple" data type
of an XML string, and then return that string, and do various things
with it on the client side. Using this method, I've reconstructed ADO
recordsets on the client side from XML strings, which although a bit
slow, is something you can try when it's your only option for getting
what would otherwise be complex data types back to a "legacy" client.

-adm
 
Thanks adm,

I used this code from a web example that you pointed me to:
------------------------------------------------------------
Private Sub Form_Load()

Dim objWebSvcClient As New MSSOAPLib30.SoapClient30
Dim dTemp As Double

objWebSvcClient.MSSoapInit _
"http://localhost/TempConvert1/TempConvert1.asmx?wsdl"

dTemp = objWebSvcClient.ConvertTemperature(212)
MsgBox dTemp
Unload Me

End Sub
-----------------------------------------------------------

It refers to a small Web Service that I wrote and it runs fine from my Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and got
the runtime 429 message "Can't create object". I'm not sure how to create
the proxy class in VB6 (unless that is what reference to the WSDL actually
did).

I created an MSI with the required merge modules and editied it with Orca.
However, when I tried to install it on another XP machine, I was propmpted
to shut down MS Outlook 2003 so that files could be updated. At that point I
bailed from the install fearing a corruption of Outlook.

When editing with Orca I noticed that all 3 custom actions for the
winhttp.dll were included in the InstallExecuteSequence table. I made sure
that the sequence numbers were between 1500 and 1525.
 
John said:
It refers to a small Web Service that I wrote and it runs fine from my Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and got
the runtime 429 message "Can't create object". I'm not sure how to create
the proxy class in VB6 (unless that is what reference to the WSDL actually
did).

The proxy class gets created when you add a web reference to the
project (in Office 2003). If you can copy that class into your VB6
project and compile it, I wonder if it would work without the SOAP
toolkit installed on the client machine. Not trying to push the
issue...just wondering if you can get it to work. Good luck!
 
..just wondering if you can get it to work.

Here's a funny thread from a few years ago that discusses the matter:
http://tinyurl.com/gqplb

He was trying to create the proxy class in VB6, but it looks like he
never got anywhere.

It's strange to me that the Office Web Services Toolkit could create a
proxy class but the SOAP Toolkit won't. Can anyone confirm this is
true?

adm


John said:
It refers to a small Web Service that I wrote and it runs fine from my Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and got
the runtime 429 message "Can't create object". I'm not sure how to create
the proxy class in VB6 (unless that is what reference to the WSDL actually
did).

The proxy class gets created when you add a web reference to the
project (in Office 2003). If you can copy that class into your VB6
project and compile it, I wonder if it would work without the SOAP
toolkit installed on the client machine. Not trying to push the
issue...just wondering if you can get it to work. Good luck!


I created an MSI with the required merge modules and editied it with Orca.
However, when I tried to install it on another XP machine, I was propmpted
to shut down MS Outlook 2003 so that files could be updated. At that point I
bailed from the install fearing a corruption of Outlook.

When editing with Orca I noticed that all 3 custom actions for the
winhttp.dll were included in the InstallExecuteSequence table. I made sure
that the sequence numbers were between 1500 and 1525.

adm said:
Michel Posseth [MCP] wrote:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems with
it
to deploy it to my end users so in the end

i could be entirely wrong about this, but I think you MIGHT be able to
build a client app without deploying the SOAP toolkit to your end
users. I used the Office 2003 SOAP Toolkit to create a proxy class in
an Access ADP, then ran that ADP on a computer with a fresh install of
Windows XP SP2 and MSXML 6 (i think), and it was able to access the Web
Service just fine, without the toolkit being installed (as far as I
know). Not sure if this will similarly work in VB6, but it might, and
it's definitely worth testing.

also remember that you can only use so called "simple" data types

True, but you can serialize a complex data type to a "simple" data type
of an XML string, and then return that string, and do various things
with it on the client side. Using this method, I've reconstructed ADO
recordsets on the client side from XML strings, which although a bit
slow, is something you can try when it's your only option for getting
what would otherwise be complex data types back to a "legacy" client.

-adm


"John Kotuby" <johnk@powerlist.com> schreef in bericht
I am expecting the answer to be, "of course not" or " are you kidding?",
but maybe (hopefully) I am wrong and somebody can point me to an
ingenious
example of how the impossible just takes a little more work.

TIA
 
AFAIK you can,,,, however then your users need to have office installed

This was exactly my problem ,,,, to get it to work i needed dependencies
deployed with my app that were not a reall option
the soap toolkit turned out to be a buggy dependency to deploy ( with
testing on multiple systems we run in a lot of unpredictable errors ,
however when it worked it worked great , having a few thousand users of our
product we just couldn`t take the risk )

In the end i just used the VB6 internet transfer control ,,,,,( Msinet.OCX )
and parsed the return data myself wich worked fine

regards '

Michel Posseth [MCP]


adm said:
John said:
It refers to a small Web Service that I wrote and it runs fine from my
Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and
got
the runtime 429 message "Can't create object". I'm not sure how to create
the proxy class in VB6 (unless that is what reference to the WSDL
actually
did).

The proxy class gets created when you add a web reference to the
project (in Office 2003). If you can copy that class into your VB6
project and compile it, I wonder if it would work without the SOAP
toolkit installed on the client machine. Not trying to push the
issue...just wondering if you can get it to work. Good luck!


I created an MSI with the required merge modules and editied it with
Orca.
However, when I tried to install it on another XP machine, I was
propmpted
to shut down MS Outlook 2003 so that files could be updated. At that
point I
bailed from the install fearing a corruption of Outlook.

When editing with Orca I noticed that all 3 custom actions for the
winhttp.dll were included in the InstallExecuteSequence table. I made
sure
that the sequence numbers were between 1500 and 1525.

adm said:
Michel Posseth [MCP] wrote:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems
with
it
to deploy it to my end users so in the end

i could be entirely wrong about this, but I think you MIGHT be able to
build a client app without deploying the SOAP toolkit to your end
users. I used the Office 2003 SOAP Toolkit to create a proxy class in
an Access ADP, then ran that ADP on a computer with a fresh install of
Windows XP SP2 and MSXML 6 (i think), and it was able to access the Web
Service just fine, without the toolkit being installed (as far as I
know). Not sure if this will similarly work in VB6, but it might, and
it's definitely worth testing.

also remember that you can only use so called "simple" data types

True, but you can serialize a complex data type to a "simple" data type
of an XML string, and then return that string, and do various things
with it on the client side. Using this method, I've reconstructed ADO
recordsets on the client side from XML strings, which although a bit
slow, is something you can try when it's your only option for getting
what would otherwise be complex data types back to a "legacy" client.

-adm


"John Kotuby" <johnk@powerlist.com> schreef in bericht
I am expecting the answer to be, "of course not" or " are you
kidding?",
but maybe (hopefully) I am wrong and somebody can point me to an
ingenious
example of how the impossible just takes a little more work.

TIA
 
Michel,

With what SOAP toolkit did you do that, I once was busy (I thought) with 1.0
and after that never used it again.

Therefore is your expirience with 3.0 including updates as was showed by
adm.

http://www.microsoft.com/downloads/...DD-CEEC-4088-9753-86F052EC8450&displaylang=en

Cor

Michel Posseth said:
AFAIK you can,,,, however then your users need to have office installed

This was exactly my problem ,,,, to get it to work i needed dependencies
deployed with my app that were not a reall option
the soap toolkit turned out to be a buggy dependency to deploy ( with
testing on multiple systems we run in a lot of unpredictable errors ,
however when it worked it worked great , having a few thousand users of
our product we just couldn`t take the risk )

In the end i just used the VB6 internet transfer control ,,,,,(
Msinet.OCX ) and parsed the return data myself wich worked fine

regards '

Michel Posseth [MCP]


adm said:
John said:
It refers to a small Web Service that I wrote and it runs fine from my
Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and
got
the runtime 429 message "Can't create object". I'm not sure how to
create
the proxy class in VB6 (unless that is what reference to the WSDL
actually
did).

The proxy class gets created when you add a web reference to the
project (in Office 2003). If you can copy that class into your VB6
project and compile it, I wonder if it would work without the SOAP
toolkit installed on the client machine. Not trying to push the
issue...just wondering if you can get it to work. Good luck!


I created an MSI with the required merge modules and editied it with
Orca.
However, when I tried to install it on another XP machine, I was
propmpted
to shut down MS Outlook 2003 so that files could be updated. At that
point I
bailed from the install fearing a corruption of Outlook.

When editing with Orca I noticed that all 3 custom actions for the
winhttp.dll were included in the InstallExecuteSequence table. I made
sure
that the sequence numbers were between 1500 and 1525.

Michel Posseth [MCP] wrote:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems
with
it
to deploy it to my end users so in the end

i could be entirely wrong about this, but I think you MIGHT be able to
build a client app without deploying the SOAP toolkit to your end
users. I used the Office 2003 SOAP Toolkit to create a proxy class in
an Access ADP, then ran that ADP on a computer with a fresh install of
Windows XP SP2 and MSXML 6 (i think), and it was able to access the
Web
Service just fine, without the toolkit being installed (as far as I
know). Not sure if this will similarly work in VB6, but it might, and
it's definitely worth testing.

also remember that you can only use so called "simple" data types

True, but you can serialize a complex data type to a "simple" data
type
of an XML string, and then return that string, and do various things
with it on the client side. Using this method, I've reconstructed ADO
recordsets on the client side from XML strings, which although a bit
slow, is something you can try when it's your only option for getting
what would otherwise be complex data types back to a "legacy" client.

-adm


"John Kotuby" <johnk@powerlist.com> schreef in bericht
I am expecting the answer to be, "of course not" or " are you
kidding?",
but maybe (hopefully) I am wrong and somebody can point me to an
ingenious
example of how the impossible just takes a little more work.

TIA
 
Hi Cor ,


The project i talked about was last revisioned somewhere in the midle of
2004 for my previous employer
http://abs-bv.netserver2.net/page.asp?lIntMenuId=192&lStrEntityId=<EN>brakediscdocu
i see that the current deploy package of the soap redistributable is from
8/13/2003 so it must have been the same version as i always try to use the
lastest technology availlable


regards

Michel Posseth [MCP]

Cor Ligthert said:
Michel,

With what SOAP toolkit did you do that, I once was busy (I thought) with
1.0 and after that never used it again.

Therefore is your expirience with 3.0 including updates as was showed by
adm.

http://www.microsoft.com/downloads/...DD-CEEC-4088-9753-86F052EC8450&displaylang=en

Cor

Michel Posseth said:
AFAIK you can,,,, however then your users need to have office installed

This was exactly my problem ,,,, to get it to work i needed dependencies
deployed with my app that were not a reall option
the soap toolkit turned out to be a buggy dependency to deploy ( with
testing on multiple systems we run in a lot of unpredictable errors ,
however when it worked it worked great , having a few thousand users of
our product we just couldn`t take the risk )

In the end i just used the VB6 internet transfer control ,,,,,(
Msinet.OCX ) and parsed the return data myself wich worked fine

regards '

Michel Posseth [MCP]


adm said:
John Kotuby wrote:

It refers to a small Web Service that I wrote and it runs fine from my
Dev
machine (as expected).
However, trying to run it on an XP machine after installing MSXML 6 and
got
the runtime 429 message "Can't create object". I'm not sure how to
create
the proxy class in VB6 (unless that is what reference to the WSDL
actually
did).

The proxy class gets created when you add a web reference to the
project (in Office 2003). If you can copy that class into your VB6
project and compile it, I wonder if it would work without the SOAP
toolkit installed on the client machine. Not trying to push the
issue...just wondering if you can get it to work. Good luck!




I created an MSI with the required merge modules and editied it with
Orca.
However, when I tried to install it on another XP machine, I was
propmpted
to shut down MS Outlook 2003 so that files could be updated. At that
point I
bailed from the install fearing a corruption of Outlook.

When editing with Orca I noticed that all 3 custom actions for the
winhttp.dll were included in the InstallExecuteSequence table. I made
sure
that the sequence numbers were between 1500 and 1525.

Michel Posseth [MCP] wrote:
Hi John

yes you can with the "ugly"soap toolkit ,,, i had lots of problems
with
it
to deploy it to my end users so in the end

i could be entirely wrong about this, but I think you MIGHT be able
to
build a client app without deploying the SOAP toolkit to your end
users. I used the Office 2003 SOAP Toolkit to create a proxy class in
an Access ADP, then ran that ADP on a computer with a fresh install
of
Windows XP SP2 and MSXML 6 (i think), and it was able to access the
Web
Service just fine, without the toolkit being installed (as far as I
know). Not sure if this will similarly work in VB6, but it might, and
it's definitely worth testing.

also remember that you can only use so called "simple" data types

True, but you can serialize a complex data type to a "simple" data
type
of an XML string, and then return that string, and do various things
with it on the client side. Using this method, I've reconstructed ADO
recordsets on the client side from XML strings, which although a bit
slow, is something you can try when it's your only option for getting
what would otherwise be complex data types back to a "legacy" client.

-adm


"John Kotuby" <johnk@powerlist.com> schreef in bericht
I am expecting the answer to be, "of course not" or " are you
kidding?",
but maybe (hopefully) I am wrong and somebody can point me to an
ingenious
example of how the impossible just takes a little more work.

TIA
 
Back
Top