What's the Best Startup Scenario for Unattended Server Execution?

[steveeisen]

I'm a long-time VB6 programmer in a shop that is mostly moving to VB
..NET 2005. And I'm confused about coding the start of solutions for
unattended operations.

Much of what I write is old-time batch. Such programs are started from
a scheduler and run on a server, cycling through a mass of data,
without human intervention. No form should show on the server monitor,
although an invisible one may be needed to support the Winsock or other
control.

In VB6, I usually have a Main routine in a standard module as the
startup. But in a VB 2005 Windows Application, the startup has to be a
form, even if you don't have any intrinsic need for one.

I briefly looked into console applications, but never need a DOS-type
window. And console applications seem out of the question because they
require giving up ApplicationEvents.

Code like this does work to turn a Windows Application into what I am
used to:

Public Class MyUselessForm
Private Sub MyUselessForm_Load(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles MyBase.Load
Main()
End Sub
Sub Main()
' do the real processing starting from here
End
End Sub
End Class

However, there must be something slicker. Before I start using the
above many times, does someone have a better idea? And, no, going back
to COBOL won't be better

Steve Eisenberg Pennsylvania U.S.A.

 

[CT]

Steve,

You don't actually have to set a Form in a Windows application to be the
startup object. In the properties for a project, you can set the startup
object to be Sub Main and place that in a Module. In VS 2005, you need to
clear the Enable application framework checkbox to select Sub Main in the
Startup object list.

 

[Cor Ligthert [MVP]]

Steve,

In addition to Carsten, Jay has somewhere in this newsgroup once showed all
the possibilities to start-up a VBNet application. It are definitely more
than that "one" in Cobol (I thought eleven).

Be aware that although Carsten writes it completely correct, we probably all
had problems finding that the first time for version 2005 (it is easier in
2002/2003), so don't hesitate to reply if you do not find it or that it does
not work.



Cor

 

[steveeisen]

In addition to Carsten, Jay has somewhere in this newsgroup once showed all
the possibilities to start-up a VBNet application.

My Googling skills failed in trying to find that. The OP question is
one I do find asked a few times before, but it never has quite been
given the slick answer I thought might be possible.

I thank Carsten for his method, but it loses the ApplicationEvents. If
you are used to going without them, that's no problem, but as soon as I
saw that feature, I wanted it.

I now have an alternate method that is maybe just slightly less clunky
than the one in the OP, but it still requires having a non-functioning
form. In the Startup ApplicationEvent, I launch a procedure which is
the starting point for the true application, like this:

Private Sub MyApplication_Startup(ByVal sender As Object, _
ByVal e As _
Microsoft.VisualBasic.ApplicationServices.StartupEventArgs) _
Handles Me.Startup
StartupProc()
End Sub

StartupProc in this example is a Friend Sub in a standard module. By
the way, what I call StartUpProc cannot be called Main. Just about
anything else is fine.

Then, in the Load routine of the otherwise unused form, I have this:

Me.Close()

In this scheme, all the processing is acutally occurring during the
Startup event, and the startup form never finishes loading. Thinking
there could be a problem getting to other applications events when you
were still technically in the Startup ApplicationEvent, I tested
StartupNextInstance and UnhandledException successfully. I assume that
NetworkAvailabilityChanged will work as well. So there is no
functional or maintainability problem, just that it doesn't seem right
for someone looking at your code to see a form requiring an
explanation.

Thanks for all ideas, or for pointing out something obvious that I'm
missing.

Steve Eisenberg Pennsylvania, U.S.A.