Stand Alone EXE

[David Pendrey]

I was wondering if it is at all posible to write a stand alone .EXE program
in Visual Studio .NET. Hopefully in VB.NET but if not another language would
be ok. Thanks for the assistance

 

[Michael A. Covington]

I was wondering if it is at all posible to write a stand alone .EXE program
in Visual Studio .NET. Hopefully in VB.NET but if not another language
would be ok. Thanks for the assistance

Yes. Visual Studio programs (VB, C#, etc.) normally compile to a single
..EXE file. This file will only run on computers that have .NET Framework
installed, but it's a single .EXE file.

 

[Jim Hubbard]

Yes. Visual Studio programs (VB, C#, etc.) normally compile to a single
.EXE file. This file will only run on computers that have .NET Framework
installed, but it's a single .EXE file.

Or, you can use Thinstall to wrap the exe and only the portions of the .Net
framework that it uses into a single executable that can be run on any
computer - with or without the .Net framework installed.

Jim Hubbard

 

[David Pendrey]

Thank you very much Jim! Would you be able to give me some direction on how
to use this application to wrap my applications into working? Preferably I
would like to just release a single .EXE program simply because its such a
small program it doesn't warrant a whole 20 meg package to get it working.
Thank you so much fo ryour assistance

 

[J L]

Hi Jim,
Have you used Thinstall? If so, how much did it cost? And what is your
opinion of it?

TIA,
John

 

[Jim Hubbard]

Thank you very much Jim! Would you be able to give me some direction on
how to use this application to wrap my applications into working?
Preferably I would like to just release a single .EXE program simply
because its such a small program it doesn't warrant a whole 20 meg package
to get it working. Thank you so much fo ryour assistance

After you create your application, you run Thinstall and point it to your
exe. Thinstall then finds all related files and portions of the .Net
framework that your EXE needs and wraps the whole thing into a single EXE
that can be run without installation. This helps in a couple of ways....

First, you never have your application's files overwritten (i.e. DLL Hell).
Second, your users don't need administrative rights to run the application.
Third, your users don't need the .Net framework installed.

Thinstall even creates a virtual registry on-the-fly that your application
uses so that there are no changes to the users registry.

Of course Thinstall can be programmed to make permanent registry entries and
even to leave files on the users system (such as database files or image
files that your app may create). Thinstall also handles licensing for you.
It's really all up to you.

Thinstall is used by a huge host of companies (like Quickbooks), government
agencies and every branch of the armed forces.

I haven't talked to Jonathon Clark (President of Thinstall) in a few weeks.
The last time we talked, he had mentioned that they were working on a new
pricing scheme to be more flexible for small companies and large. So, I am
not sure what the pricing structure is right now.

Whatever it is, you can get an extra 5% off by mentioning jim__hubbard @
hotmail . com . Tell Jonathon I sent you. He's a great guy and his staff
are very helpful. www.thinstall.com

Hope this helps......

 

[Jim Hubbard]

Hi Jim,
Have you used Thinstall? If so, how much did it cost? And what is your
opinion of it?

The pricing structure has changed. You'd have to contact Thinstall
(www.thinstall.com) for current pricing. But, you can get an extra 5% off
if you mention code jim__hubbard @ hotmail . com (remove the sp@ces).

I definitely use it. It's great! No worries about distributing the .Net
framework.

Actually.....distributing the .Net framework is more of a bandwidth thing
than a real problem. The problem comes in when the user tries to install
the .Net framework. Unless you are on a completely clean PC, installing the
..Net framework can be problematic. Then your customers are calling you for
support with a Microsoft product and that just sucks.

With the Thinstall EXE, all they have to do is double click it and they are
off and running (unless you configure Thinstall to handle licensing - in
which case they need to enter the appropriate keys to register the
software).

It is the coolest, (somewhat unknown) application out there for developers.

I wouldn't distribute .Net apps without it.

One more thing.......Net applications in a Thinstall EXE are safe against
ildasm (disassembling) and don't need obfuscators to keep your code
fromprying eyes. This is what originally sold me on Thinstall.

I wrote some about it a while back on my blog at
http://poderthis.blogspot.com/.

Hope this helps!

Jim Hubbard

 

[Cor Ligthert]

Jim,

The problem comes in when the user tries to install the .Net framework.
Unless you are on a completely clean PC, installing the .Net framework can
be problematic. Then your customers are calling you for support with a
Microsoft product and that just sucks.

I can me not remember that I ever heard about what you wrote above in any
newsgroup I am active in..

Can you give some samples for situations where you have got those.

Cor

 

[Cor Ligthert]

David,

What you ask now is endless asked times before in these newsgroups.

Be aware that the Net framework is in fact nothing more than a
servicepack/extension over the OS, what could be made by any vendor of
operating systems to let the programs made with the ILS language run and
provide with that extra's as by instance better memorymanagement.

A lot of us have had in past more than once problems with different runtimes
for more versions of a language.

That is gone with NET

When you want a real small program, than there is in Visual Studio Net the
C++ unmanaged code part for things as drivers etc.

I hope this helps,

Cor

 

[David Pendrey]

Cor,

It is a shame that they did not think it was an important part of
programming. For large, complicated programs then a package distribution
such as that is the way to go, but for small programs (i.e. notepad) there
should be the option to compile a stand alone .EXE file. However I have
recently learnt of a 3rd party application ('Thinstall') which will perform
this task for you. Thanks for your help

 

[Cor Ligthert]

David,

I think that you did not read my message. When that is not enough, read the
concept of the Net. It is not something of one minute thinking. There is as
well done things as I wrote to overcome all things from runtimes with
different versions.

When you add something as ThinInstall, than that is not a single running
Exe. Which in fact don't exist since the time of windows for screen
operations. It only still exist for things as commandline and driver
operations on Win32 systems.

A program that uses a window (form) can never be a small exe when there is
not something used as now a OS extension as Net or a runtime.

The ones who insert in those programs direct handling of the window, do
remind me on those people who in the beginning of MS-Dos were using direct
screen handling by the OS (pseudo mem) addresses for that. That has given
the most problems when Windows started to keep those programs running and
where the first programs from which was told that they would not go anymore.

The reason for the developers of that was that than they could keep the
programs small and that those were faster. They found themselves very clever
guys. But professionals (than and now most) called those guys fools.

It is a shame that some developers do only one minute thinking.

Cor

 

[David Pendrey]

If it is not possible to have a small EXE program which includes a form then
how is notepad only 68kb? It includes several forms and depends only on the
windows system behind it. There is a difference between 'minute thingking'
and weighing the possabilities.

For small, simple programs it is often worth while to add a little bit extra
size onto the file and have it take a little bit longer to load to keep it a
stand alone. After all, its still a small program, and still loads in what
is a very usable time frame.

You can't just optimise all the time at the expense of usability and
distribution. If people had to download the 22 meg .NET framework to
download a program to read RTF files they would not get it. But if the
program takes a few extra seconds to load ands takes up an extra meg on
their hard drive it is much more user friendly.

From what I can understand the THInstall program simply moves the API
functions calls from the .NET framework into your EXE program. The program
maintains its functionality on Windows 98 and above irrespective of if the
..NET framework is installed and if so which version.

 

[Alejandro Lapeyre]

Cor..

You used...?

mov ah,09
int 21h

or...

mov ah,..
int 10h

or
mov es,video_segment
mov di,
....

The speed differences where abismal!

Of course it caused problems for windows (At least with 8086 and 80286), but
the OS should have provided a decent video output routine! Anyway, text
based output was so fast that a complete screen redraw would only take
4kbytes, so even for windows that wasnt a big deal.

Regards,
Alejandro Lapeyre

 

[Herfried K. Wagner [MVP]]

Yes. Visual Studio programs (VB, C#, etc.) normally compile to a single
.EXE file. This file will only run on computers that have .NET Framework
installed, but it's a single .EXE file.

Note that all components used by the application must be available on the
target machine too.

 

[Jim Hubbard]

If it is not possible to have a small EXE program which includes a form
then how is notepad only 68kb? It includes several forms and depends only
on the windows system behind it. There is a difference between 'minute
thingking' and weighing the possabilities.

For small, simple programs it is often worth while to add a little bit
extra size onto the file and have it take a little bit longer to load to
keep it a stand alone. After all, its still a small program, and still
loads in what is a very usable time frame.

You can't just optimise all the time at the expense of usability and
distribution. If people had to download the 22 meg .NET framework to
download a program to read RTF files they would not get it.

And, presently they may have to download the .Net Framework up to 3 times
(1.0, 1.1 and 2.0) to run all .Net applications because none of the
frameworks are backwards compatible with it's siblings! We have simply
swapped DLL Hell for .Net Framework Hell.

Since you cannot know what version of .Net your user may have (if any) you
must ship the .Net runtime with all of your applications (or use Thinstall
to wrap them).

It simply amazes me that Microsoft did not make .Net exes automatically
download only the portions of the .Net runtime they need (from Microsoft) to
run. A program written in .Net and stored on an internet server will do
this. It only downloads the DLLs it requires for the functionality that the
user is attempting to use. So why not have it do the same for the whole
damned framework?

A second thing that just boggles my mind is why the .Net framework is not a
"Critical" update for XP+. If Microsoft is moving to this platform, then it
is needed on every Windows desktop. Why don't they make it a critical
update and force it onto the desktops?

Then we could ship very tiny applications because we would not need to ship
the runtimes. And, that whole XCOPY thing they were so high on might
actually work. As it stands you cannot rely on Xcopy to distribute an
application because you cannot rely on the correct (if any) .Net framework
to be on the end user's PC.

But if the program takes a few extra seconds to load ands takes up an extra
meg on their hard drive it is much more user friendly.

Thinstall apps are still a lot larger than a simple exe output from .Net. I
did an experiment with Washington University's .Net rewrite of the classic
Paint program. If you downloaded the .Net framework and the code needed to
run Paint 2.0 it added up to over 27 MB. The same application compiled with
Thinstall was just over 14 MB and needed no installation, needed no
administrator privikeges, and will never have its files overwritten or
corrupted because they are all inside the Thinstall EXE.

Why didn't Microsoft think of this? They have seen and used Thinstall, and
even spoke well of it.

 

[Jim Hubbard]

Note that all components used by the application must be available on the
target machine too.

Thinstall takes care of this too.

With Thinstall this is not an issue.

Jim Hubbard

 

[Steve McLellan]

Notepad requires a runtime of sorts, and probably a load of libraries. Hook
a debugger up to it and see how many libraries load. The overhead is hidden
because they're generally already present, as will be the case with the .NET
framework at some point in the future. Things like Thinstall do definitely
have advantages, but if a bug crops up in a .NET component, how do you patch
it? You need to tell your users (it becomes a problem in YOUR code, rather
than the framework) rather than letting them just get updates via Windows
Update etc.

Steve

 

[David Pendrey]

Notepad uses windows components, which if they don't exist almost no
programs will work, so they can be taken as written as a part of windows. So
if notepad only uses windows components, it doesnt count as a required
library as its a part of the OS.

 

[Cor Ligthert]

David,

Notepad uses windows components, which if they don't exist almost no
programs will work, so they can be taken as written as a part of windows.
So if notepad only uses windows components, it doesn't count as a required
library as its a part of the OS.

Exactly as I wrote already is the Microsoft Net framework an extension to
the Windows OS, in the same way as that can be with another vendors OS. It
is as I wrote a kind of servicepack not a stand alone solution (reread my
first answer for that).

You have given with this message a good sample why using the Net is better
than all kind of separated runtimes or other of this kind of solutions.

Cor

 

[Michael A. Covington]

First, you never have your application's files overwritten (i.e. DLL
Hell). Second, your users don't need administrative rights to run the
application. Third, your users don't need the .Net framework installed.

Only the third of these is different from normal life with .NET Framework,
as far as I can tell...

But it sounds useful.