Creating a Project no form

[tshad]

If I am using ASP.Net 2008, and I want to create an executable which will
have no user interface and will only be run from the scheduler, what type of
project do I create.

Can I create an ASP.Net a Windows Forms Application even if not using the
form?

Thanks,

Tom

 

[Jeff Johnson]

If I am using ASP.Net 2008, and I want to create an executable which will
have no user interface and will only be run from the scheduler, what type
of project do I create.

Can I create an ASP.Net a Windows Forms Application even if not using the
form?

ASP.NET has nothing to do with what you're asking. You aren't using "ASP.NET
2008" to mean "Visual Web Developer Express 2008," are you?

Basically, you'd probably want to create a console application. However, if
this is to be run as a background task, I would really recommend creating a
Windows service and then having it use a timer to decide when to run as
opposed to using the task scheduler. I've always looked down on task
scheduler as a hack for programmers who didn't know how to make real
services.

 

[Peter Duniho]

If I am using ASP.Net 2008, and I want to create an executable which will
have no user interface and will only be run from the scheduler, what
type of
project do I create.

Can I create an ASP.Net a Windows Forms Application even if not using the
form?

I don't understand the question. ASP.NET and Windows Forms are two
completely different kinds of projects, for completely different
purposes. And a program with no UI would not use either type of project,
because both ASP.NET and Windows Forms are defined (at least in part) by
how the UI is built.

Depending on whether you want any output or not, you probably want to
build a console application, or a Windows Forms application in which
you've removed the default main form and associated calls in the
Program.Main() method (i.e. delete System.Windows.Forms from the project
references, and then delete any code that winds up with a compiler error
after you've removed that assembly reference).

Pete

 

[Peter Duniho]

[...]
Basically, you'd probably want to create a console application. However,
if
this is to be run as a background task, I would really recommend
creating a
Windows service and then having it use a timer to decide when to run as
opposed to using the task scheduler. I've always looked down on task
scheduler as a hack for programmers who didn't know how to make real
services.

IMHO your disdain is unjustified. The task scheduler is a perfectly
acceptable solution for a certain kind of problem. If one doesn't need
any of the behaviors specific to services, why go to the extra trouble of
writing a service when a simple program executable by the task scheduler
would suffice?

In fact, the task scheduler has features built into it that may be
required, and which adding to a service creates yet even more work than
that just associated with wrapping the program in a service. Maintaining
the proper schedule across system reboots, for example.

Pete

 

[tshad]

[...]
Basically, you'd probably want to create a console application. However,
if
this is to be run as a background task, I would really recommend
creating a
Windows service and then having it use a timer to decide when to run as
opposed to using the task scheduler. I've always looked down on task
scheduler as a hack for programmers who didn't know how to make real
services.

IMHO your disdain is unjustified. The task scheduler is a perfectly
acceptable solution for a certain kind of problem. If one doesn't need
any of the behaviors specific to services, why go to the extra trouble of
writing a service when a simple program executable by the task scheduler
would suffice?

In fact, the task scheduler has features built into it that may be
required, and which adding to a service creates yet even more work than
that just associated with wrapping the program in a service. Maintaining
the proper schedule across system reboots, for example.

I totally agree.

I can write this as a service but I am going to run this once a day at about
10:00pm. I am also going to allow the users to run it manually. There
would be no filtering (date ranges, for example).

This would have been perfect for a FileWatcher as I am going to grab
whatever is in a particular folder. But since it is going to happen just one
time (or manually - not very often) a day. The Task Scheduler seemed better
suited for the task.

So would a console application, as Jeff mentioned, be the best bet?

Thanks,

Tom

 

[Jeff Johnson]

IMHO your disdain is unjustified. The task scheduler is a perfectly
acceptable solution for a certain kind of problem. If one doesn't need
any of the behaviors specific to services, why go to the extra trouble of
writing a service when a simple program executable by the task scheduler
would suffice?

I guess it's because everything I've ever seen set up as a task scheduler
job would have been far better suited to a service. Now, granted, at home
sometimes I want my computer to be up for a while (large download, for
example) but shut off in the middle of the night. For that I have a
scheduled task which runs the shutdown command. THAT would be service
overkill, I agree. But it's also not a recurring thing. Again, my
perceptions are based on my experiences.

 

[tshad]

I don't understand the question. ASP.NET and Windows Forms are two
completely different kinds of projects, for completely different
purposes. And a program with no UI would not use either type of project,
because both ASP.NET and Windows Forms are defined (at least in part) by
how the UI is built.

You're right. What I should have said was .Net Windows Forms. I am also
going to have a web page but not for making changes to the tables, but this
app is only going to run once, read a bunch of csv files and update tables
based on what is in the files.

Depending on whether you want any output or not, you probably want to
build a console application, or a Windows Forms application in which
you've removed the default main form and associated calls in the
Program.Main() method (i.e. delete System.Windows.Forms from the project
references, and then delete any code that winds up with a compiler error
after you've removed that assembly reference).

So if I am going to use the Windows Forms Application, it starts like this:
********************************************************************
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace TestApp
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
*********************************************************************

I then take out the:

System.Windows.Forms From the references

using System.Windows.Forms; From program.cs

forms.cs delete from the project.

I then get errors on "Application",

Error 1 The name 'Application' does not exist in the current context
C:\Documents and Settings\tscheiderich\My Documents\Visual Studio
2008\Projects\TestApp\TestApp\Program.cs 15 13 TestApp

So I take out the 3 lines that start out with Application and add a call to
my starting method

Is that right?

What would be the difference between this and a console app?

Thanks,

Tom

 

[tshad]

What if I created a Service App. Could I run that as either a Windows
Service or an executable run by the Scheduler.

It might be nice to build it that so that if later the customer wants to run
the executable the service would be already set up with a few changes.

Thanks,

Tom

I don't understand the question. ASP.NET and Windows Forms are two
completely different kinds of projects, for completely different
purposes. And a program with no UI would not use either type of project,
because both ASP.NET and Windows Forms are defined (at least in part) by
how the UI is built.

You're right. What I should have said was .Net Windows Forms. I am also
going to have a web page but not for making changes to the tables, but
this app is only going to run once, read a bunch of csv files and update
tables based on what is in the files.

Depending on whether you want any output or not, you probably want to
build a console application, or a Windows Forms application in which
you've removed the default main form and associated calls in the
Program.Main() method (i.e. delete System.Windows.Forms from the project
references, and then delete any code that winds up with a compiler error
after you've removed that assembly reference).

So if I am going to use the Windows Forms Application, it starts like
this:
********************************************************************
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace TestApp
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
*********************************************************************

I then take out the:

System.Windows.Forms From the references

using System.Windows.Forms; From program.cs

forms.cs delete from the project.

I then get errors on "Application",

Error 1 The name 'Application' does not exist in the current context
C:\Documents and Settings\tscheiderich\My Documents\Visual Studio
2008\Projects\TestApp\TestApp\Program.cs 15 13 TestApp

So I take out the 3 lines that start out with Application and add a call
to my starting method

Is that right?

What would be the difference between this and a console app?

Thanks,

Tom

Pete

 

[Jesse Houwing]

* tshad wrote, On 8-9-2009 23:08:

What if I created a Service App. Could I run that as either a Windows
Service or an executable run by the Scheduler.

It might be nice to build it that so that if later the customer wants to run
the executable the service would be already set up with a few changes.

If you put all the real functionality in a Class Library, you can
reference this library from both a console app project and a windows
service project. That gives you the flexibility of both types of
applications and maximum reuse of your code.

While you're going to be loading a bunch of data into a Database (SQL
Server?) you might also want to consider using Sql Server Integration
Services combined with a Sql Agent Job. It's purposely built for DLT
jobs like the one you're programming.

JEsse

Thanks,

Tom

If I am using ASP.Net 2008, and I want to create an executable which
will
have no user interface and will only be run from the scheduler, what
type of
project do I create.

Can I create an ASP.Net a Windows Forms Application even if not using
the
form?

I don't understand the question. ASP.NET and Windows Forms are two
completely different kinds of projects, for completely different
purposes. And a program with no UI would not use either type of project,
because both ASP.NET and Windows Forms are defined (at least in part) by
how the UI is built.

You're right. What I should have said was .Net Windows Forms. I am also
going to have a web page but not for making changes to the tables, but
this app is only going to run once, read a bunch of csv files and update
tables based on what is in the files.

Depending on whether you want any output or not, you probably want to
build a console application, or a Windows Forms application in which
you've removed the default main form and associated calls in the
Program.Main() method (i.e. delete System.Windows.Forms from the project
references, and then delete any code that winds up with a compiler error
after you've removed that assembly reference).

So if I am going to use the Windows Forms Application, it starts like
this:
********************************************************************
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace TestApp
{
static class Program
{
///<summary>
/// The main entry point for the application.
///</summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
*********************************************************************

I then take out the:

System.Windows.Forms From the references

using System.Windows.Forms; From program.cs

forms.cs delete from the project.

I then get errors on "Application",

Error 1 The name 'Application' does not exist in the current context
C:\Documents and Settings\tscheiderich\My Documents\Visual Studio
2008\Projects\TestApp\TestApp\Program.cs 15 13 TestApp

So I take out the 3 lines that start out with Application and add a call
to my starting method

Is that right?

What would be the difference between this and a console app?

Thanks,

Tom

Pete

 

[Peter Duniho]

[...]
So would a console application, as Jeff mentioned, be the best bet?

Do you need console window to appear? If not, then no, I don't think so.
You should just do a plain Windows application, but simply one that has no
UI (i.e. as I suggested before, start with a Forms project but remove all
the references to the System.Windows.Forms assembly, namespace, and
classes).

Pete

 

[Peter Duniho]

[...]
Is that right?

Yup, that's right.

What would be the difference between this and a console app?

A console application has a different project setting, marking it as a
console application. When Windows starts a process using an executable
marked that way, it creates a console window to go along with the
application. Doing what you correctly interpreted as my suggestion, you
get a plain Windows application but one that just doesn't bother to create
any window. So, no console window created on your behalf, and no
application-created windows either. Just a raw Windows process that can
do stuff.

Pete

 

[Jeff Johnson]

What if I created a Service App. Could I run that as either a Windows
Service or an executable run by the Scheduler.

No, you cannot run a service with the task scheduler. Services must be
started via the Service Control Manager (SCM) in Windows. This is why it's
such a pain to debug a service from the IDE (compared to other types of
projects).

 

[tshad]

That makes sense.

I may leave the Form stuff in for the inital setup and testing, then take it
out.

Thanks,

Tom

[...]
So would a console application, as Jeff mentioned, be the best bet?

Do you need console window to appear? If not, then no, I don't think so.
You should just do a plain Windows application, but simply one that has no
UI (i.e. as I suggested before, start with a Forms project but remove all
the references to the System.Windows.Forms assembly, namespace, and
classes).

Pete

 

[tshad]

In the Process.cs, the program calls:

Application.Run(new frmMain());

frmMain just brings up a form with a button on it and I call the starting
point in my BusinessLayer.

How would I get Application.Run to call this same method?

I can't use a "new" to run it (can I?).

Thanks,

Tom

That makes sense.

I may leave the Form stuff in for the inital setup and testing, then take
it out.

Thanks,

Tom

[...]
So would a console application, as Jeff mentioned, be the best bet?

Do you need console window to appear? If not, then no, I don't think so.
You should just do a plain Windows application, but simply one that has
no UI (i.e. as I suggested before, start with a Forms project but remove
all the references to the System.Windows.Forms assembly, namespace, and
classes).

Pete

 

[Peter Duniho]

In the Process.cs, the program calls:

Application.Run(new frmMain());

Surely you mean "In Program.cs", right?

frmMain just brings up a form with a button on it and I call the starting
point in my BusinessLayer.

How would I get Application.Run to call this same method?

You don't. But you shouldn't need to. If you're removing the form and
making your app a console application, then you take out all the stuff
from the Program.Main() method (including the call to Application.Run()),
and replace it with the call to your business layer's entry point.

Pete

 

[tshad]

Surely you mean "In Program.cs", right?

Yup. My mistake.

You don't. But you shouldn't need to. If you're removing the form and
making your app a console application, then you take out all the stuff
from the Program.Main() method (including the call to Application.Run()),
and replace it with the call to your business layer's entry point.

This would then start up a console window, correct?

Not a problem, just curious.

I actually, created another project in my solution (console application), so
now I can run it either way.

If I run this from the schedular - would the console window cause a problem?

I am also running it from a web page.

the code is:

protected void Process_Click(object sender, EventArgs e)
{
try
{
Process p = new Process();
p.StartInfo.FileName =
"C:\\UPS\\UPS.Executable\\bin\\Debug\\UPS.Executable.exe";
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = false;
p.StartInfo.WindowStyle = ProcessWindowStyle.Maximized;
p.Start();
}
catch (Exception exp)
{
//txtResults.Text = exp.StackTrace;
}
}

Is there a way let the person on the web page know when the program has
stopped.

All the console applications does now is:

static void Main(string[] args)
{
Transform.XlateCSVToSql();
}

It runs for about 2 minutes process CSV files.

I would like to be able to tell the user when the program is done. He will
know when the Console window closes, but it would be nice to have the Web
page show him something about being done. It would also be nice to be able
to prevent him from doing anything on the page until the program is done.

Thanks,

Tom

 

[Peter Duniho]

[...]

You don't. But you shouldn't need to. If you're removing the form and
making your app a console application, then you take out all the stuff
from the Program.Main() method (including the call to
Application.Run()),
and replace it with the call to your business layer's entry point.

This would then start up a console window, correct?

Not unless you set the project type to be a console application.

Not a problem, just curious.

I actually, created another project in my solution (console
application), so
now I can run it either way.

If I run this from the schedular - would the console window cause a
problem?

That depends on your definition of "problem". It shouldn't prevent the
program from running, if that's what you're asking.

I am also running it from a web page.

the code is:

protected void Process_Click(object sender, EventArgs e)
{
try
{
Process p = new Process();
p.StartInfo.FileName =
"C:\\UPS\\UPS.Executable\\bin\\Debug\\UPS.Executable.exe";
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = false;
p.StartInfo.WindowStyle = ProcessWindowStyle.Maximized;
p.Start();
}
catch (Exception exp)
{
//txtResults.Text = exp.StackTrace;
}
}

There's nothing in that code that has anything to do with a web page.

Is there a way let the person on the web page know when the program has
stopped.

I'm sure there is. But without a good code example showing exactly what
you're doing, it's not possible to suggest what way would be useful and
practical in your own scenario.

Pete

 

[tshad]

[...]

How would I get Application.Run to call this same method?

You don't. But you shouldn't need to. If you're removing the form and
making your app a console application, then you take out all the stuff
from the Program.Main() method (including the call to
Application.Run()),
and replace it with the call to your business layer's entry point.

This would then start up a console window, correct?

Not unless you set the project type to be a console application.

Not a problem, just curious.

I actually, created another project in my solution (console
application), so
now I can run it either way.

If I run this from the schedular - would the console window cause a
problem?

That depends on your definition of "problem". It shouldn't prevent the
program from running, if that's what you're asking.

I am also running it from a web page.

the code is:

protected void Process_Click(object sender, EventArgs e)
{
try
{
Process p = new Process();
p.StartInfo.FileName =
"C:\\UPS\\UPS.Executable\\bin\\Debug\\UPS.Executable.exe";
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = false;
p.StartInfo.WindowStyle = ProcessWindowStyle.Maximized;
p.Start();
}
catch (Exception exp)
{
//txtResults.Text = exp.StackTrace;
}
}

There's nothing in that code that has anything to do with a web page.

The Process_Click is from a button on my Web page.

I'm sure there is. But without a good code example showing exactly what
you're doing, it's not possible to suggest what way would be useful and
practical in your own scenario.

I am not sure what else to show here.

All that is happening is that there is a button on our Web Page that says
"Process". If you push the button it will start another process to execute
a program that is normally handled by the schedular and run at night.

But we want to be able to periodically from our Web Page to start the
program manually.

This code starts the program on the server.

But the operator has no way of knowing when the program finishes as it is
running on the server.

Tom