Hi All
I have a task that I'm thinking about attacking in two different ways
but don't know enough about Windows Services.
First:
We have a server application written in VB.net that acts as a
middleman between various Fortan DLL's (the calculation engines) and
various front end client applications (one in Java and two in
VB.net). The front ends check to see if the server application is
running when they need some calculations and if it's not running they
start it up. Simple enough and works great.
Well, now the powers that be have decided that the server application
should be a Windows Service (and always be running), rather than a
standalone executable.
I thought that I had correctly converted the project to a service. It
compiles and installs just fine. And it seems to run with no
problems. However, when I actually make a call to the service I keep
getting errors back (from Fortran) telling me that various
configuration files are missing (these are text files and binary files
containing engineering data needed by the Fortran code). They are in
the same location that they have always been (the same folder as the
windows service EXE), but for some reason now they can't be found,
where as before there was no issue. Having a difficult time
determining whether this is a Fortran or a VB.net problem, especially
since the debugging is trickier for Windows Services than just for
straight executables.
Is there a special location on the drive when all support files for
any Windows Service need to be located?
Second:
Another idea I had is rather than integrate all of the code from the
server application into a new Windows service, I'd possibly keep the
same executable and have the service just act as a wrapper, always
monitoring whether or not the server application executable is running
and restarting it whenever it stops (for whatever reason). This would
seem to be much simpler and would leave open the option of returning
to the old method should we decide that the windows service route
isn't for us (we all know that management tends to change their minds
often). I had originally pursued this path but was unsure how to do
this with only the service OnStart and OnStop methods available.
Thanks in advance for any assistance.
I have a task that I'm thinking about attacking in two different ways
but don't know enough about Windows Services.
First:
We have a server application written in VB.net that acts as a
middleman between various Fortan DLL's (the calculation engines) and
various front end client applications (one in Java and two in
VB.net). The front ends check to see if the server application is
running when they need some calculations and if it's not running they
start it up. Simple enough and works great.
Well, now the powers that be have decided that the server application
should be a Windows Service (and always be running), rather than a
standalone executable.
I thought that I had correctly converted the project to a service. It
compiles and installs just fine. And it seems to run with no
problems. However, when I actually make a call to the service I keep
getting errors back (from Fortran) telling me that various
configuration files are missing (these are text files and binary files
containing engineering data needed by the Fortran code). They are in
the same location that they have always been (the same folder as the
windows service EXE), but for some reason now they can't be found,
where as before there was no issue. Having a difficult time
determining whether this is a Fortran or a VB.net problem, especially
since the debugging is trickier for Windows Services than just for
straight executables.
Is there a special location on the drive when all support files for
any Windows Service need to be located?
Second:
Another idea I had is rather than integrate all of the code from the
server application into a new Windows service, I'd possibly keep the
same executable and have the service just act as a wrapper, always
monitoring whether or not the server application executable is running
and restarting it whenever it stops (for whatever reason). This would
seem to be much simpler and would leave open the option of returning
to the old method should we decide that the windows service route
isn't for us (we all know that management tends to change their minds
often). I had originally pursued this path but was unsure how to do
this with only the service OnStart and OnStop methods available.
Thanks in advance for any assistance.
Comment