basic console app without .net, is it possible in c#.

[soler]

need to write a simple app with console output and file i/o to be distributed
to other machines. Is it possbile in c# without .net overhead, not sure if
all machines Xp have .net installed.

probably suggest c/c++, which version.

any suggestions greatly appreciated.

 

[Willy Denoyette [MVP]]

need to write a simple app with console output and file i/o to be
distributed
to other machines. Is it possbile in c# without .net overhead, not sure if
all machines Xp have .net installed.

probably suggest c/c++, which version.

any suggestions greatly appreciated.

No, you can't run managed code (C#, vb, C++/CLI etc) without the runtime
installed.
Your only option is using an unmanaged language (C/C++, VB6, Delphi etc).
Not sure what your requirements are, but for simple console applications you
can even use a scripting language (VBScript, JScript, Perl etc...)

Willy.

 

[Peter Duniho]

need to write a simple app with console output and file i/o to be
distributed
to other machines. Is it possbile in c# without .net overhead, not sure
if
all machines Xp have .net installed.

AFAIK, C# only works in the context of .NET. I don't think you can write
an unmanaged program in C#, as the language specifically depends on the
..NET runtime.

probably suggest c/c++, which version.

Any version of C/C++ should work fine. Windows doesn't care what version
of the compiler you used. You do need an SDK that supports the Windows
APIs you intend to use, but if your application is truly simple, you could
probably use an obsolete SDK as well. But why would you? At worst, just
use the latest Visual Studio Express version.

Pete

 

[Rene]

Your only option is using an unmanaged language (C/C++, VB6, Delphi etc).

Hi Willy,

I am assuming that the original poster wanted to create an exe that would
work by simply copying the exe into any Windows machine and then have the
user double click it and go from there.

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having the VB
runtime framework to work.

I have no doubt that you already knew this but I am just replying so that
the original poster realizes this in case he is not aware of this.

Cheers

 

[Willy Denoyette [MVP]]

Hi Willy,

I am assuming that the original poster wanted to create an exe that would
work by simply copying the exe into any Windows machine and then have the
user double click it and go from there.

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having the VB
runtime framework to work.

IMO his requirement was no .NET runtime, and the VB runtime is a small
re-distributable.
Anyways, there is no real way to build *console* applications in VB6.

Willy.

 

[Scott Roberts]

Hi Willy,

I am assuming that the original poster wanted to create an exe that would
work by simply copying the exe into any Windows machine and then have the
user double click it and go from there.

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having the VB
runtime framework to work.

I have no doubt that you already knew this but I am just replying so that
the original poster realizes this in case he is not aware of this.

Cheers

For the record, Delphi definitely builds native Win32 apps that require no
run-time whatsoever.

 

[Arne Vajhøj]

need to write a simple app with console output and file i/o to be distributed
to other machines. Is it possbile in c# without .net overhead, not sure if
all machines Xp have .net installed.

probably suggest c/c++, which version.

Not possible with C# without .NET - you can use latest and
greatest MS VC++ to generate native code.

But do you really need to ? PC'es without .NET is an
endangered species. And you are allowed to redistribute
the runtime.

Arne

 

[Arne Vajhøj]

Anyways, there is no real way to build *console* applications in VB6.

Depends on your definition of real.

Use of FSO and link /edit /subsystem:console can
actually produce a console app.

Arne

 

[Rad [Visual C# MVP]]

Hi Willy,

I am assuming that the original poster wanted to create an exe that would
work by simply copying the exe into any Windows machine and then have the
user double click it and go from there.

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having the VB
runtime framework to work.

I have no doubt that you already knew this but I am just replying so that
the original poster realizes this in case he is not aware of this.

Cheers

I can vouch that Delphi does not require any runtime to build a console
application

 

[Rad [Visual C# MVP]]

[5 quoted lines suppressed]

Not possible with C# without .NET - you can use latest and
greatest MS VC++ to generate native code.

But do you really need to ? PC'es without .NET is an
endangered species. And you are allowed to redistribute
the runtime.

Arne

I suppose it depends on the circumstances. If it is a simple utility of a
couple of KB it might be an overkill to bundle that with a 25MB+ runtime,
especially if the utility is for download

 

[Willy Denoyette [MVP]]

Hi Willy,

I am assuming that the original poster wanted to create an exe that would
work by simply copying the exe into any Windows machine and then have the
user double click it and go from there.

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having the VB
runtime framework to work.

I have no doubt that you already knew this but I am just replying so that
the original poster realizes this in case he is not aware of this.

Cheers

For your info: the VB6 runtime is part of the OS, msvbvm60.dll is installed
in your system32 directory, even on Vista.

Willy.

 

[Willy Denoyette [MVP]]

Depends on your definition of real.

Use of FSO and link /edit /subsystem:console can
actually produce a console app.

Arne

Well, you are cheating , but this is not exactly my definition of a
console application.
My definition of a console application:
- does not depend on a GDI, that is, creates no Window and (obviously) does
not pump a Windows message queue.
- takes his user input from the keyboard (stdin) and sends it's output to a
command shell window (stdout).

I don't think that VB6 can create such an application, flipping the console
bit in the PE header doesn't help to achieve the above, isn't it?

Willy.

 

[Rudy Velthuis]

If that is the case, I don't think VB6 (or Delphi) will work for this
purpose since I am pretty sure that VB6 executables require having
the VB runtime framework to work.

But Delphi (for Win32) executables don't require any runtime to be
present. It is perfectly possible to write single-file applications,
and not only for the console.

 

[Willy Denoyette [MVP]]

But Delphi (for Win32) executables don't require any runtime to be
present. It is perfectly possible to write single-file applications,
and not only for the console.
--
Rudy Velthuis http://rvelthuis.de

"I have seen the future and it is just like the present, only
longer." -- Albran

The same is true for VB6.

Willy.

 

[Homer J. Simpson]

Not possible with C# without .NET - you can use latest and

greatest MS VC++ to generate native code.

But do you really need to ? PC'es without .NET is an
endangered species. And you are allowed to redistribute
the runtime.

Tell a potential customer with hundreds, or even thousands, of locked down
PCs to install the .NET framework and you've probably just lost a pretty
significant sale.

 

[Rudy Velthuis]

The same is true for VB6.

No doubt. I assume the runtime is part of the OS?

 

[Arne Vajhøj]

Well, you are cheating , but this is not exactly my definition of a
console application.
My definition of a console application:
- does not depend on a GDI, that is, creates no Window and (obviously)
does not pump a Windows message queue.
- takes his user input from the keyboard (stdin) and sends it's output
to a command shell window (stdout).

I don't think that VB6 can create such an application, flipping the
console bit in the PE header doesn't help to achieve the above, isn't it?

FSO and flipping the bit help.

Sub Main()
Dim fso As Scripting.FileSystemObject
Dim instm As Scripting.TextStream
Dim outstm As Scripting.TextStream
Dim s As String
Set fso = New Scripting.FileSystemObject
Set instm = fso.GetStandardStream(0)
Set outstm = fso.GetStandardStream(1)
outstm.Write "Enter something: "
s = instm.ReadLine
outstm.WriteLine "You entered: " & s
End Sub

sure quacks like a duck.

Arne

 

[Arne Vajhøj]

Tell a potential customer with hundreds, or even thousands, of locked down
PCs to install the .NET framework and you've probably just lost a pretty
significant sale.

There can be good reasons to go for native Win32.

My point is that today the logic should be "go with
..NET unless you are absolutely sure that you
need Win32" not "go with Win32 unless you are
absolutely sure that you need .NET".

The percentage of Windows machines with .NET installed
is increasing every day and will continue doing so.

Arne

 

[Willy Denoyette [MVP]]

FSO and flipping the bit help.

Sub Main()
Dim fso As Scripting.FileSystemObject
Dim instm As Scripting.TextStream
Dim outstm As Scripting.TextStream
Dim s As String
Set fso = New Scripting.FileSystemObject
Set instm = fso.GetStandardStream(0)
Set outstm = fso.GetStandardStream(1)
outstm.Write "Enter something: "
s = instm.ReadLine
outstm.WriteLine "You entered: " & s
End Sub

sure quacks like a duck.

Arne

I know that flipping the bit, enables the stdin/stdout in the process, so
you can redirect both handles to whatever you see fit. The problem is that
you can't get rid of the Form (the Window and it's message queue), or do you
have found a means to call Main before the window gets created?

Willy.

 

[Arne Vajhøj]

I know that flipping the bit, enables the stdin/stdout in the process,
so you can redirect both handles to whatever you see fit. The problem is
that you can't get rid of the Form (the Window and it's message queue),
or do you have found a means to call Main before the window gets created?

There is no visible window. I delete the form and change project
startup to Sub Main before building.

I don't know what is going on behind the scene. But from what
is visible it looks like a console app.

Arne