But, with Inno (which is a really good installer), it is only compressed
until it is installed.  With Thinstall or Xenocode the single exe is always
compressed and no install is needed to run the app - just copy the single
exe to the PC or any media installed in the PC (like a USB drive) and run
it.  Nothing to install.  Nothing to uninstall.

But, you must do this via control panel applets etc., right?  Most people
don't know how to do this.  That is why Microsoft's click and run stuff
never took off.

With Thinstall (not sure about Xenocode) you don't have any trust issues.
The executables simply run.

Thinstall and Xenocode create virtual registry entries and virtual
directories that your app uses to run.  These virtual objects are destroyed
when the app closes.

I haven't used Xenocode, but as for Thinstall - Thinstall does not affect
the functionality of your application at all.  If you want to enforce
security using the .Net classes in your app you can.

I'm telling you....Thinstall-capability is the answer to distribution
issues, DLL/version hell issues, permission issues, setup issues and even
helps maintain security on the desktop.  Why nobody is making an affordable
version for the masses, or has taken this on as an open source project is
beyond me.

The benefits are so great that NOT including this technology in .Net studio
is simply negligent.

jim

It was the same thing with COM and shared DLLs.

Microsoft thought that (due in part to the expense of hard drive space at
the time) that sharing DLLs would be an answer to the hard drive space issue
and would save RAM by allowinf several applications to share the same DLLs.

It wasn't a bad theory, it just didn't work well in reality due to DLL
versioning issues.  As a matter of fact, the simple answer to DLL Hell for
Visual Basic (and I suspect C++) apps was simply to place a copy of the
needed DLLs in the same directory as your executable.  The way Windows works
is to look in the executable's directory for a needed DLL  BEFORE using the
registry to find one EVEN IF THE REFERENCED DLL IS REGISTERED ON THE PC
RUNNING THE APPLICATION THAT NEED IT.

You didn't have to change one line of code or alter the method of
registering your DLLS.  Just drop them in the EXE directory and, BAM, no
more DLL Hell.  But, that was way too simple a solution - so we got .Net.

.Net has now gone back to keeping it's files in the same directory AND using
the registry to share .Net framework files.

So, now we are wasting drive space (not that it's that expensive anymore)
AND having to contend with a bloated 25MB+ framework and possible
application failures due to some developers using hotfixes to patch .Net
while others code around the issues found.

Eventually we will get back to the days of a single, linked and compiled
EXE - and it will be all new and shiny again.

!!!!  WARNING!  The following paragraphs may be offensive to Microsoft
Groupies!  Read at your own risk!  I will niether be responsible for your
overreactions nor will I respond to them.  This is simply an observation and
remarking on another author's observatiuons.  !!!!

That reminds me of an article I read the other day about how MS changed the
way apps used to work when they developed Windows.  In the old Xerox and
Apple OS's that Gates observed before and while developing Windows, there
used to be something called time sharing (I think thats what it was called)
where all applications were placed in their own workspace and could not
access each other's memory or workspace.  It kept applications from screwing
each other up.

Then, according to the author, Microsoft did away with this time
sharing/application segregation because they wanted the applications to look
and be more integrated with Windows in order to sell more software (like
Word, Works, Office, etc.).  The author claims that all of this was done to
increase the market share of Windows apps and to increase revenue for the
investors (which, again, is what a corporation is good for).

Now, with the .Net framework, it seems we are getting back to the 1970's
idea of time sharing and application isolation.

I find it quite funny myself.  Next, we'll be back to linked compiled
executables and praising it as another Microsoft breakthrough.

jim

My apologies to the Microsoft MVP community as a whole.  But, the majority
of MVPs that "contribute" to threads seem to be adverse to actually reading
about or trying to understand the topic that they are responding to.

This majority of responders makes the MVP community as a whole look quite
foolish.

jim

We haven't seen that many true failures- maybe a few dozen. We've seens lots
of "Took a reallllly long time. Wireless networke died after 40 minutes. Had
to restart. You product sucks. FOAD." In nearly all these cases (the ones
we've been able to analyze) the culprit has been the very long .Net
framework install.

The problem is when the install fails, we hear all about it, as people
quickly get very vocal. Then it's on forms that get archived and indexed by
search engines, and the next thing you know the top hits for the product are
all "Unable to installed.", "Broken", "Sucks".

Everything seems to install quite well on fresh computers. But on computers
that have been around a while (and are often infected with stuff), or are
running strange virus / malware scanners, or have had beta versions of stuff
installed, it seems to fail the most.

On the other hand, it's... very frustrating.

I personally have had to rebuild 2 dev workstations due to .Net install
failures. These involve beta versions of the .Net 3 & 3.5 frameworks that
failed to uninstall properly. I expect some of this given that they're beta,
but it's very frustrating how fragile the installers are..

--
Chris Mullins