Web service in EXE

Re: Web service in EXE

Jeremy Chapman wrote:
[color=blue]
> I've seen apps where if a windows exe form is running, it publishes a
> web service. There is no IIS folders or virtual directories required.
> Does anyone have information on how to do this?[/color]

Yup. First you need to get yourself WSE2.0[1]. Next, write a web service
class that derives from SoapService, like so:

<codeSnippet language="C#">
public sealed class MyService : SoapService
{
[SoapMethod("MyS oapAction")]
public void MyWebMethod()
{
// TODO: do something here
}
}
</codeSnippet>

Finally, to host this service in your WinForms app all you need to do is
the following:

<codeSnippet language="C#">
protected override void OnLoad(EventArg s args)
{
SoapReceivers.A dd(new EndpointReferen ce(new Uri("http://" + Dns.GetHostName ()
+ "/MyService")), typeof(MyServic e));

base.OnLoad(arg s);
}
</codeSnippet>

That's all there is to it. You could host it with the lower level soap TCP
protocol if you just change "http:" to "soap.tcp:" . Read all about this process
here[2].

HTH,
Drew

[1] http://msdn.microsoft.com/webservices/building/wse/
[2] http://msdn.microsoft.com/library/de....asp?frame=tru

Re: Web service in EXE

Brilliant! I'll try this.


"Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
news:8516763237 3431863593750@m snews.microsoft .com...[color=blue]
> Jeremy Chapman wrote:
>[color=green]
> > I've seen apps where if a windows exe form is running, it publishes a
> > web service. There is no IIS folders or virtual directories required.
> > Does anyone have information on how to do this?[/color]
>
> Yup. First you need to get yourself WSE2.0[1]. Next, write a web service
> class that derives from SoapService, like so:
>
> <codeSnippet language="C#">
> public sealed class MyService : SoapService
> {
> [SoapMethod("MyS oapAction")]
> public void MyWebMethod()
> {
> // TODO: do something here
> }
> }
> </codeSnippet>
>
> Finally, to host this service in your WinForms app all you need to do is
> the following:
>
> <codeSnippet language="C#">
> protected override void OnLoad(EventArg s args)
> {
> SoapReceivers.A dd(new EndpointReferen ce(new Uri("http://" +[/color]
Dns.GetHostName ()[color=blue]
> + "/MyService")), typeof(MyServic e));
>
> base.OnLoad(arg s);
> }
> </codeSnippet>
>
> That's all there is to it. You could host it with the lower level soap TCP
> protocol if you just change "http:" to "soap.tcp:" . Read all about this[/color]
process[color=blue]
> here[2].
>
> HTH,
> Drew
>
> [1] http://msdn.microsoft.com/webservices/building/wse/
> [2][/color]
http://msdn.microsoft.com/library/de...asp?frame=true[color=blue]
>[/color]

Re: Web service in EXE

I'm running into a bit of a snag,

On the SoapReceivers.A dd method, An exception gets raised with the message
WSE803: A valid HttpContext is required for Active HTTP Listening.

Is this a configuration issue? Neither the help or google return anything
on WSE803


"Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
news:8516763237 3431863593750@m snews.microsoft .com...[color=blue]
> Jeremy Chapman wrote:
>[color=green]
> > I've seen apps where if a windows exe form is running, it publishes a
> > web service. There is no IIS folders or virtual directories required.
> > Does anyone have information on how to do this?[/color]
>
> Yup. First you need to get yourself WSE2.0[1]. Next, write a web service
> class that derives from SoapService, like so:
>
> <codeSnippet language="C#">
> public sealed class MyService : SoapService
> {
> [SoapMethod("MyS oapAction")]
> public void MyWebMethod()
> {
> // TODO: do something here
> }
> }
> </codeSnippet>
>
> Finally, to host this service in your WinForms app all you need to do is
> the following:
>
> <codeSnippet language="C#">
> protected override void OnLoad(EventArg s args)
> {
> SoapReceivers.A dd(new EndpointReferen ce(new Uri("http://" +[/color]
Dns.GetHostName ()[color=blue]
> + "/MyService")), typeof(MyServic e));
>
> base.OnLoad(arg s);
> }
> </codeSnippet>
>
> That's all there is to it. You could host it with the lower level soap TCP
> protocol if you just change "http:" to "soap.tcp:" . Read all about this[/color]
process[color=blue]
> here[2].
>
> HTH,
> Drew
>
> [1] http://msdn.microsoft.com/webservices/building/wse/
> [2][/color]
http://msdn.microsoft.com/library/de...asp?frame=true[color=blue]
>[/color]

Re: Web service in EXE

Jeremy Chapman wrote:
[color=blue]
> I'm running into a bit of a snag,
>
> On the SoapReceivers.A dd method, An exception gets raised with the
> message WSE803: A valid HttpContext is required for Active HTTP
> Listening.
>
> Is this a configuration issue? Neither the help or google return
> anything on WSE803[/color]

Ack! Sorry Jeremy. I actually gave some bad advice there. I was unfortunately
thinking in the mindset of Indigo where this will be very possible and very
easy to do.

Unfortunately for WSE2.0, it looks to me like you can only setup SoapReceivers
dynamically with the soap.tcp protocol in a WinForms/Console/Service application
right now[1]. Therefore, the only way to host HTTP based SoapReceivers with
WSE2.0 is to use ASP.NET itself and configure a web application according
to the instructions that I gave you the URL for before under the header "To
register a SoapReceiver class by using the HTTP protocol".

Sorry 'bout that,
Drew

[1] That is of course, unless you host the ASP.NET runtime in your Windows
application yourself with the System.Web.Host ing APIs, but I doubt that's
supported or even recommended. If you *really* want to try going this route
I suggest you search google for custom hosting ASP.NET

Re: Web service in EXE

On 29/11/2004, around 09:32, Drew Marsh wrote:

DM> Yup. First you need to get yourself WSE2.0[1]. Next, write a web service
DM> class that derives from SoapService, like so:
[Snip]
Blimey, today's turning in to a real school day for me!

--
Stuart
See headers for PGP Key.
"Very funny, Scotty. Now beam down my clothes."

Re: Web service in EXE

Ok thanks. I've seen this done before, maybe not in .net, bit it can be
done I'm sure so I'll have to continue hunting for a solution.


"Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
news:8566363237 3540149062500@m snews.microsoft .com...[color=blue]
> Jeremy Chapman wrote:
>[color=green]
> > I'm running into a bit of a snag,
> >
> > On the SoapReceivers.A dd method, An exception gets raised with the
> > message WSE803: A valid HttpContext is required for Active HTTP
> > Listening.
> >
> > Is this a configuration issue? Neither the help or google return
> > anything on WSE803[/color]
>
> Ack! Sorry Jeremy. I actually gave some bad advice there. I was[/color]
unfortunately[color=blue]
> thinking in the mindset of Indigo where this will be very possible and[/color]
very[color=blue]
> easy to do.
>
> Unfortunately for WSE2.0, it looks to me like you can only setup[/color]
SoapReceivers[color=blue]
> dynamically with the soap.tcp protocol in a WinForms/Console/Service[/color]
application[color=blue]
> right now[1]. Therefore, the only way to host HTTP based SoapReceivers[/color]
with[color=blue]
> WSE2.0 is to use ASP.NET itself and configure a web application according
> to the instructions that I gave you the URL for before under the header[/color]
"To[color=blue]
> register a SoapReceiver class by using the HTTP protocol".
>
> Sorry 'bout that,
> Drew
>
> [1] That is of course, unless you host the ASP.NET runtime in your Windows
> application yourself with the System.Web.Host ing APIs, but I doubt that's
> supported or even recommended. If you *really* want to try going this[/color]
route[color=blue]
> I suggest you search google for custom hosting ASP.NET.
>[/color]

Re: Web service in EXE

Jeremy Chapman wrote:
[color=blue]
> Ok thanks. I've seen this done before, maybe not in .net, bit it can
> be done I'm sure so I'll have to continue hunting for a solution.[/color]

Yeah absolutely, it's not like it's impossible or anything. Even with WSE
you could do it if you wanted to get your hands dirty. However there is no
"out of the box" support for this hosting scenario.

The question I have though is: do you really need it to use the HTTP protocol
if it's a Windows client application? Are you really acting for a host to
random HTTP clients via the internet at that point? Or are you just looking
to use the services for some kind of inter-process communication? If the
latter is the case, then the soap.tcp protocol is probably the better choice
for this problem anyway.

Good luck,
Dre

Re: Web service in EXE

We have an application that sits on a server doing various tasks (this app
must run in a logged in user session). I wanted to build in functionality
so that various users could view the status of the application and well as
control the app in various ways, without needing to log on to the server.
Doing it through a web interface seemed like a very intuitive way to do it.

"Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
news:8711563237 4134267812500@m snews.microsoft .com...[color=blue]
> Jeremy Chapman wrote:
>[color=green]
> > Ok thanks. I've seen this done before, maybe not in .net, bit it can
> > be done I'm sure so I'll have to continue hunting for a solution.[/color]
>
> Yeah absolutely, it's not like it's impossible or anything. Even with WSE
> you could do it if you wanted to get your hands dirty. However there is no
> "out of the box" support for this hosting scenario.
>
> The question I have though is: do you really need it to use the HTTP[/color]
protocol[color=blue]
> if it's a Windows client application? Are you really acting for a host to
> random HTTP clients via the internet at that point? Or are you just[/color]
looking[color=blue]
> to use the services for some kind of inter-process communication? If the
> latter is the case, then the soap.tcp protocol is probably the better[/color]
choice[color=blue]
> for this problem anyway.
>
> Good luck,
> Drew
>[/color]

Re: Web service in EXE

> [1] That is of course, unless you host the ASP.NET runtime in your Windows[color=blue]
> application yourself with the System.Web.Host ing APIs, but I doubt that's
> supported or even recommended. If you *really* want to try going this[/color]
route[color=blue]
> I suggest you search google for custom hosting ASP.NET.[/color]

What Jeremy is after is a fairly common scenario for client-side apps.

Hosting ASP.NET is supported. Microsoft publishes a sample app that does
this - it is called Cassini. It is a WinForms app that serves ASPX and ASMX
content over HTTP. Check for it on www.asp.net . It does not use WSE, but
I believe you can extend it to use WSE if you need the security features of
WSE.

[color=blue]
>We have an application that sits on a server doing various tasks (this app[/color]
must run in a logged in user session). I wanted to build in functionality
so that various users could view the status of the application and well as
control the app in various ways, without needing to log on to the server.
Doing it through a web interface seemed like a very intuitive way to do it.


Oooh, now wait a minute. The original request was for a winforms app that
exposes an HTTP endpoint. Now you've reversed it - you want a server app
that shows a GUI. I cannot recommend the "Cassini" approach to do this.

Why not build the server app as a hosted service (or whatever model you
choose - maybe it is an ASMX running in IIS), and then build a winForms GUI
that pings the service periodically and updates its screen? Why bundle the
server and GUI functions?

--D


"Jeremy Chapman" <NoSpam@Please. com> wrote in message
news:%23Gk2sGx1 EHA.2016@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> We have an application that sits on a server doing various tasks (this app
> must run in a logged in user session). I wanted to build in functionality
> so that various users could view the status of the application and well as
> control the app in various ways, without needing to log on to the server.
> Doing it through a web interface seemed like a very intuitive way to do
> it.
>
> "Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
> news:8711563237 4134267812500@m snews.microsoft .com...[color=green]
>> Jeremy Chapman wrote:
>>[color=darkred]
>> > Ok thanks. I've seen this done before, maybe not in .net, bit it can
>> > be done I'm sure so I'll have to continue hunting for a solution.[/color]
>>
>> Yeah absolutely, it's not like it's impossible or anything. Even with WSE
>> you could do it if you wanted to get your hands dirty. However there is
>> no
>> "out of the box" support for this hosting scenario.
>>
>> The question I have though is: do you really need it to use the HTTP[/color]
> protocol[color=green]
>> if it's a Windows client application? Are you really acting for a host to
>> random HTTP clients via the internet at that point? Or are you just[/color]
> looking[color=green]
>> to use the services for some kind of inter-process communication? If the
>> latter is the case, then the soap.tcp protocol is probably the better[/color]
> choice[color=green]
>> for this problem anyway.
>>
>> Good luck,
>> Drew
>>[/color]
>
>[/color]

Re: Web service in EXE

Dino Chiesa [Microsoft] wrote:
[color=blue]
> What Jeremy is after is a fairly common scenario for client-side apps.
>
> Hosting ASP.NET is supported. Microsoft publishes a sample app that
> does this - it is called Cassini. It is a WinForms app that serves
> ASPX and ASMX content over HTTP. Check for it on www.asp.net . It
> does not use WSE, but I believe you can extend it to use WSE if you
> need the security features of WSE.[/color]

Yeah, that's what I recommended originally after realizing I made the mistake:

<snip>
That is of course, unless you host the ASP.NET runtime in your Windows application
yourself with the System.Web.Host ing APIs, but I doubt that's supported or
even recommended. If you *really* want to try going this route I suggest
you search google for custom hosting ASP.NET.
</snip>
[color=blue]
> Oooh, now wait a minute. The original request was for a winforms app
> that exposes an HTTP endpoint. Now you've reversed it - you want a
> server app that shows a GUI. I cannot recommend the "Cassini"
> approach to do this.
>
> Why not build the server app as a hosted service (or whatever model
> you choose - maybe it is an ASMX running in IIS), and then build a
> winForms GUI that pings the service periodically and updates its
> screen? Why bundle the server and GUI functions?[/color]

I don't think he really needs to be showing UI on the server for any particular
reason. His whole problem actually seems to be that he needs to run the host
application in user mode for some reason, as he stated here:

<snip>
We have an application that sits on a server doing various tasks (this app
must run in a logged in user session).
</snip>

Perhaps I'm wrong, but my guess after reading that was that he's probably
using some legacy components that can't be used in a service for whatever
reasons. Jeremy can you give us any more detail so that we might be able
to recommend better solutions?

Side note: I was personally hoping WSE 2.0 SP2 would contain an SoapHttpSysTran sport
that hooked up to the HTTP.SYS APIs (as Indigo will) to provide the exact
same support as WSE does for soap.tcp.

Later,
Dre

Re: Web service in EXE

For all intents and purpose, the 'server' app is no different that any other
client app such as word pad, with the exception that it runs on a server.
In our environment we have a server that always has a user logged on. The
app runs in this session. It must be constantly running, and it must be
running in a user session.

I have successfully referenced the casini dll in my app and it is able to
serve web pages. Although I don't want it to server web pages generically
this is a good start. I have also built test web services and of course it
will serve them up as well by putting the web service dll in my applications
bin directory.

I have two questions:

1) is there any way to eliminate the need for the bin directory? ie, can I
put the casini.dll and my web service dll in the same directory as my
winform application?

2) The web service is a dll that has a public class that inherits from
System.Web.Serv ices.WebService . Is it possible to put this class in my
winforms exe so that I do not require the dll for my web service. I want
all my web service code to be in my winform app. I have tried to do this,
and modified the asmx page so the class tag points to the class in my
winform, but when I try to browse to the asmx page I get a .net error saying
asp.net can't find the class. Can this be done? Essentially I want to
encapsulate all the functionality i need in webservices in my winforms exe


"Dino Chiesa [Microsoft]" <dinoch@online. microsoft.com> wrote in message
news:el5TOw11EH A.412@TK2MSFTNG P14.phx.gbl...[color=blue][color=green]
> > [1] That is of course, unless you host the ASP.NET runtime in your[/color][/color]
Windows[color=blue][color=green]
> > application yourself with the System.Web.Host ing APIs, but I doubt[/color][/color]
that's[color=blue][color=green]
> > supported or even recommended. If you *really* want to try going this[/color]
> route[color=green]
> > I suggest you search google for custom hosting ASP.NET.[/color]
>
> What Jeremy is after is a fairly common scenario for client-side apps.
>
> Hosting ASP.NET is supported. Microsoft publishes a sample app that does
> this - it is called Cassini. It is a WinForms app that serves ASPX and[/color]
ASMX[color=blue]
> content over HTTP. Check for it on www.asp.net . It does not use WSE,[/color]
but[color=blue]
> I believe you can extend it to use WSE if you need the security features[/color]
of[color=blue]
> WSE.
>
>[color=green]
> >We have an application that sits on a server doing various tasks (this[/color][/color]
app[color=blue]
> must run in a logged in user session). I wanted to build in functionality
> so that various users could view the status of the application and well as
> control the app in various ways, without needing to log on to the server.
> Doing it through a web interface seemed like a very intuitive way to do[/color]
it.[color=blue]
>
>
> Oooh, now wait a minute. The original request was for a winforms app that
> exposes an HTTP endpoint. Now you've reversed it - you want a server app
> that shows a GUI. I cannot recommend the "Cassini" approach to do this.
>
> Why not build the server app as a hosted service (or whatever model you
> choose - maybe it is an ASMX running in IIS), and then build a winForms[/color]
GUI[color=blue]
> that pings the service periodically and updates its screen? Why bundle[/color]
the[color=blue]
> server and GUI functions?
>
> --D
>
>
> "Jeremy Chapman" <NoSpam@Please. com> wrote in message
> news:%23Gk2sGx1 EHA.2016@TK2MSF TNGP15.phx.gbl. ..[color=green]
> > We have an application that sits on a server doing various tasks (this[/color][/color]
app[color=blue][color=green]
> > must run in a logged in user session). I wanted to build in[/color][/color]
functionality[color=blue][color=green]
> > so that various users could view the status of the application and well[/color][/color]
as[color=blue][color=green]
> > control the app in various ways, without needing to log on to the[/color][/color]
server.[color=blue][color=green]
> > Doing it through a web interface seemed like a very intuitive way to do
> > it.
> >
> > "Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
> > news:8711563237 4134267812500@m snews.microsoft .com...[color=darkred]
> >> Jeremy Chapman wrote:
> >>
> >> > Ok thanks. I've seen this done before, maybe not in .net, bit it can
> >> > be done I'm sure so I'll have to continue hunting for a solution.
> >>
> >> Yeah absolutely, it's not like it's impossible or anything. Even with[/color][/color][/color]
WSE[color=blue][color=green][color=darkred]
> >> you could do it if you wanted to get your hands dirty. However there is
> >> no
> >> "out of the box" support for this hosting scenario.
> >>
> >> The question I have though is: do you really need it to use the HTTP[/color]
> > protocol[color=darkred]
> >> if it's a Windows client application? Are you really acting for a host[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >> random HTTP clients via the internet at that point? Or are you just[/color]
> > looking[color=darkred]
> >> to use the services for some kind of inter-process communication? If[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> >> latter is the case, then the soap.tcp protocol is probably the better[/color]
> > choice[color=darkred]
> >> for this problem anyway.
> >>
> >> Good luck,
> >> Drew
> >>[/color]
> >
> >[/color]
>
>[/color]

Re: Web service in EXE

Absolutely Drew, we've written this app around some legacy component which
will not function as a service. We have an account that we use to log on a
user session.
The app we've written is a gui because it allows, through menu items, a user
to stop, start and restart and it shows what it is currently processing.
The idea of it hosting a web service was because I was hoping to be able to
stop, start and restart it through a web app as well as query the app to see
what it is currently processing. A web app would mean zero deployment to
users.


"Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
news:8911863237 4543340000000@m snews.microsoft .com...[color=blue]
> Dino Chiesa [Microsoft] wrote:
>[color=green]
> > What Jeremy is after is a fairly common scenario for client-side apps.
> >
> > Hosting ASP.NET is supported. Microsoft publishes a sample app that
> > does this - it is called Cassini. It is a WinForms app that serves
> > ASPX and ASMX content over HTTP. Check for it on www.asp.net . It
> > does not use WSE, but I believe you can extend it to use WSE if you
> > need the security features of WSE.[/color]
>
> Yeah, that's what I recommended originally after realizing I made the[/color]
mistake:[color=blue]
>
> <snip>
> That is of course, unless you host the ASP.NET runtime in your Windows[/color]
application[color=blue]
> yourself with the System.Web.Host ing APIs, but I doubt that's supported or
> even recommended. If you *really* want to try going this route I suggest
> you search google for custom hosting ASP.NET.
> </snip>
>[color=green]
> > Oooh, now wait a minute. The original request was for a winforms app
> > that exposes an HTTP endpoint. Now you've reversed it - you want a
> > server app that shows a GUI. I cannot recommend the "Cassini"
> > approach to do this.
> >
> > Why not build the server app as a hosted service (or whatever model
> > you choose - maybe it is an ASMX running in IIS), and then build a
> > winForms GUI that pings the service periodically and updates its
> > screen? Why bundle the server and GUI functions?[/color]
>
> I don't think he really needs to be showing UI on the server for any[/color]
particular[color=blue]
> reason. His whole problem actually seems to be that he needs to run the[/color]
host[color=blue]
> application in user mode for some reason, as he stated here:
>
> <snip>
> We have an application that sits on a server doing various tasks (this app
> must run in a logged in user session).
> </snip>
>
> Perhaps I'm wrong, but my guess after reading that was that he's probably
> using some legacy components that can't be used in a service for whatever
> reasons. Jeremy can you give us any more detail so that we might be able
> to recommend better solutions?
>
> Side note: I was personally hoping WSE 2.0 SP2 would contain an[/color]
SoapHttpSysTran sport[color=blue]
> that hooked up to the HTTP.SYS APIs (as Indigo will) to provide the exact
> same support as WSE does for soap.tcp.
>
> Later,
> Drew
>[/color]

Re: Web service in EXE

Have you considered writing a windows service? You could then run it under any user context that you want and it could be brought
up on the server without having to login a user. Then you can use remoting to connect to some methods on the server and raise
events to control it.

And then, you can also use the Services control panel to remotely connect to the machine and stop, start and restart the service.


"Jeremy Chapman" <NoSpam@Please. com> wrote in message news:uq0awh81EH A.3908@TK2MSFTN GP12.phx.gbl...[color=blue]
> Absolutely Drew, we've written this app around some legacy component which
> will not function as a service. We have an account that we use to log on a
> user session.
> The app we've written is a gui because it allows, through menu items, a user
> to stop, start and restart and it shows what it is currently processing.
> The idea of it hosting a web service was because I was hoping to be able to
> stop, start and restart it through a web app as well as query the app to see
> what it is currently processing. A web app would mean zero deployment to
> users.
>
>
> "Drew Marsh" <drub0y@hotmail .no.spamming.co m> wrote in message
> news:8911863237 4543340000000@m snews.microsoft .com...[color=green]
>> Dino Chiesa [Microsoft] wrote:
>>[color=darkred]
>> > What Jeremy is after is a fairly common scenario for client-side apps.
>> >
>> > Hosting ASP.NET is supported. Microsoft publishes a sample app that
>> > does this - it is called Cassini. It is a WinForms app that serves
>> > ASPX and ASMX content over HTTP. Check for it on www.asp.net . It
>> > does not use WSE, but I believe you can extend it to use WSE if you
>> > need the security features of WSE.[/color]
>>
>> Yeah, that's what I recommended originally after realizing I made the[/color]
> mistake:[color=green]
>>
>> <snip>
>> That is of course, unless you host the ASP.NET runtime in your Windows[/color]
> application[color=green]
>> yourself with the System.Web.Host ing APIs, but I doubt that's supported or
>> even recommended. If you *really* want to try going this route I suggest
>> you search google for custom hosting ASP.NET.
>> </snip>
>>[color=darkred]
>> > Oooh, now wait a minute. The original request was for a winforms app
>> > that exposes an HTTP endpoint. Now you've reversed it - you want a
>> > server app that shows a GUI. I cannot recommend the "Cassini"
>> > approach to do this.
>> >
>> > Why not build the server app as a hosted service (or whatever model
>> > you choose - maybe it is an ASMX running in IIS), and then build a
>> > winForms GUI that pings the service periodically and updates its
>> > screen? Why bundle the server and GUI functions?[/color]
>>
>> I don't think he really needs to be showing UI on the server for any[/color]
> particular[color=green]
>> reason. His whole problem actually seems to be that he needs to run the[/color]
> host[color=green]
>> application in user mode for some reason, as he stated here:
>>
>> <snip>
>> We have an application that sits on a server doing various tasks (this app
>> must run in a logged in user session).
>> </snip>
>>
>> Perhaps I'm wrong, but my guess after reading that was that he's probably
>> using some legacy components that can't be used in a service for whatever
>> reasons. Jeremy can you give us any more detail so that we might be able
>> to recommend better solutions?
>>
>> Side note: I was personally hoping WSE 2.0 SP2 would contain an[/color]
> SoapHttpSysTran sport[color=green]
>> that hooked up to the HTTP.SYS APIs (as Indigo will) to provide the exact
>> same support as WSE does for soap.tcp.
>>
>> Later,
>> Drew
>>[/color]
>
>[/color]

Re: Web service in EXE

Scott Meddows wrote:
[color=blue]
> Have you considered writing a windows service? You could then run it
> under any user context that you want and it could be brought up on the
> server without having to login a user. Then you can use remoting to
> connect to some methods on the server and raise events to control it.
>
> And then, you can also use the Services control panel to remotely
> connect to the machine and stop, start and restart the service.[/color]

Running as a service, even though it would solve the identity issue, will
not give you 100% the same environment as being logged into an interactive
window station. If he could run as a service he'd just be better off hosting
the service in ASP.NET anyway since it's going to provide all the HTTP plumbing
for him. All he'd need to do is set the <identity> up in the web.config of
the service application.

His whole problem is that he's using some legacy components that require
him to be logged into an interactive window station. I've encountered one
of these recently and it's absolutely annoying as hell that they are written
so poorly that they require this, but unfortunately they are out there. :(

-Dre