"Plumer" <(E-Mail Removed)> wrote in message
news:85EAC657-9856-46FE-BD6E-(E-Mail Removed)...
> Good afternoon Daniel
>
> Many thanks for your encouraging reply.
>
> Your reply suggests that I need to install the Runtime on all machines
> that
> implement the app I'm supplying. You are quite correct that 100MB is much
> better than 2 Gigs but it's still a little hard to swallow.
It is certainly a pain at times. Everyone has this issue now and then.
Hopefully at some point the framework's installation base will grow, but
right now it isn't as broad as windows itself is.
> But I'm puzzled: The C++ compiler that was married to MFC produced
> genuinely
> 'stand alone' apps that could be distributed without anything other than
> the
> .exe file that the Release compiler generated. I have to note that this
> isn't
> true in the strictest sense since there were frequently standard system
> DLLs
> that were also required. But those DLLs were part of the operating systems
> that the apps were written for and so there was no need to install
> anything
> other than the exe file on the target machine. This appears not to be the
> case with the .NET Runtime. Does the .NET runtime have to also be
> installed
> on the target machine? I'm assuming that the answer is yes.
>
There is a fundamental difference in MFC and the .NET framework. Most
specifically C\C++ allows static linking. The framework does not.
C\C++ also allowed for linking only the pieces needed(within library
boundries of course), while the .NET framework is an atomic unit. There are
reasons for this, mind you.
One is that it guarentees and environment. C++\MFC used the system directly
and generate alot of code. The .NET framework installs a collection of base
libraries which in some ways wraps existing code, and in others replaces it
outright.
When you think about it, eventually the larger MFC applications with little
to no runtime are going to outweigh the framework. It is more a matter of
when the download occurs.
For exmaple, how many copies of msvcrt.dll do you have on your system? I
appear to have 13, about 6 different versions of such, at 3.95 megs. 21
msvcr71.dll for 7.48 megs, and so on(ironically, msvcr71.dll appears to be
contained in the .NET framework as well,

). And how many executables do
you have that has statically linked libraries in them, adding 300-500k? It
really is the size of the individual bite, not how much space it takes up.
Also, for alot of applications, partial distribution simply won't work. For
applications that use plugins or apps that use alot of reflection, it is
difficult or impossible to determine which components are nessecery(its not
terribly easy even with a static app).
There have been a few ideas floated, but nothing I think ever took flight.
It may hold a research project or two in it, but I doubt anything will
become mainstream any time soon.
> I'm a relatively new convert to C# having wrestled with C++ for years and
> I
> was greatly relieved to leave the obscure and arcane C++ behind when C#
> appeared BUT -- and it's a big but -- if C# cannot generate a standalone
> app
> that can be installed and run without carrying large ancillary files with
> it,
> it will really seriously call into question whether I can continue to use
> it.
> This is a serious issue for me and I need to resolve this one way or
> another
> as soon as possible.
Unfortunatly, there is no standalone support in the framework itself. There
is a product..salamander linker I believe it is called, which can generate
a, much larger, standalone executable. However I can't advise using it
because(this is a bit of a disclaimer as well)
1) I don't think its the right way to do things,
2) I can't speak for its legality and don't want to advise something that is
illegal(I don't know one way or the other, I'm not a lawyer, just someone
who doesn't want to cause trouble,

.
However, I will mention it. It might fit your needs, it might not. That is
for you to decide.