(Not) Running Release version on target machine

[Plumer]

Good morning everyone,

I am having difficulty distributing a Release version of an application.

System info
C# DOTNET, MDE 2002, Version 7.0.9466
.Net Framework, version 1.0.3705

My Desktop Operating system (as reported by Control Panel.System) is:
Windows XP, Version 2002

My Laptop Operating system (as reported by Control Panel.System) is:
Windows XP, Version 2002, Service Pack 1

The only difference being the presence of SP1 on my laptop.

Client Laptop Operating system (as reported by Control Panel.System) is:
Windows XP, Version 2002

Apart from knowing that that client machine uses WinXP 2002, I am unable to
determine the presence or otherwise of SP1 (client and computer not in town…)

I have developed a simple application that is to be used by the client for a
simple, one-time-only test. The application compiles a release version which
runs fine on my desktop but it does not run on the client’s machine stopping
before it even starts with the message

“The application failed to initialize properly (0xc0000135). Click OK to
terminate the application.”

When I tired the same exe file on my laptop I got the same message.

To test this further I created a new solution with a single project called
TestApp. Having made no alterations whatsoever to the .Net generated code, I
compiled this to Release version. The exe file runs fine on my desktop buts
fails on my laptop with the same message shown above.

My understanding was that an exe file of this nature was stand-alone in the
release version and this note in the .Net Help:

The .NET Framework provides the following options for packaging applications:
• As a single assembly or as a collection of assemblies.
With this option, you simply use the .dll or .exe files as they were built.

Meant that the exe file on its own was all that is required. What am I
missing here? Is there an incompatibility between my version of C# DOTNET and
XP with SP1 installed? Or something else?

Regards,
Plumer

[Chris Dunaway]

Re: (Not) Running Release version on target machine

On Mon, 11 Oct 2004 17:37:02 -0700, Plumer wrote:
[color=blue]
> My understanding was that an exe file of this nature was stand-alone in the
> release version and this note in the .Net Help:[/color]

You must still have the .Net framework installed on your laptop.

Is the .Net Framework installed on your laptop? If so, which version? Is
the version of the framework on your desktop the same as the version on
your laptop?

--
Chris

dunawayc[AT]sbcglobal_lunch meat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

[Plumer]

Re: (Not) Running Release version on target machine

Good morning Chris

Many thanks for your prompt and helpful response.

No, the Framework is not on the laptop and I did wonder if that was the
problem. But when I checked in Control Panel I saw an entry for the framework
on the desktop for Framework Version 1.0.3705 that occupied 2079MB! And then
I thought "Does this mean I have to install that on every machine that I want
an app to run on?? Surely not..."

But presumably the answer is yes in one form or another so it would seem
that I end up with a 60KB 'stand-alone' app that requires 2GB of backup in
order to run it. I certainly hope this isn't the final word on this because
it is just plainly and simply is not a workable or acceptable option.

Once again, many thanks for your help.

Kia pai to haere, e hoa!
Plumer



"Chris Dunaway" <"dunawayc[[at]_lunchmeat" wrote:
[color=blue]
> On Mon, 11 Oct 2004 17:37:02 -0700, Plumer wrote:
>[color=green]
> > My understanding was that an exe file of this nature was stand-alone in the
> > release version and this note in the .Net Help:[/color]
>
> You must still have the .Net framework installed on your laptop.
>
> Is the .Net Framework installed on your laptop? If so, which version? Is
> the version of the framework on your desktop the same as the version on
> your laptop?
>
> --
> Chris
>
> dunawayc[AT]sbcglobal_lunch meat_[DOT]net
>
> To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
> replace certain words in my E-Mail address.
>[/color]

[Daniel O'Connell [C# MVP]]

Re: (Not) Running Release version on target machine


"Plumer" <Plumer@discuss ions.microsoft. com> wrote in message
news:5F7475E4-B21B-4D74-BAF9-80E373E625B4@mi crosoft.com...[color=blue]
> Good morning Chris
>
> Many thanks for your prompt and helpful response.
>
> No, the Framework is not on the laptop and I did wonder if that was the
> problem. But when I checked in Control Panel I saw an entry for the
> framework
> on the desktop for Framework Version 1.0.3705 that occupied 2079MB! And
> then
> I thought "Does this mean I have to install that on every machine that I
> want
> an app to run on?? Surely not..."
>[/color]

Most likely you are seeing the SDK, not the runtime itself. The SDK is
rather large and includes all of the help files and other documents you use
regularly for development.

The runtime installer is about 20meg(60 or 100 extracted, I think. Its been
awhile since I've looked), still not small but considerablly better than 2
gigs.

[Plumer]

Re: (Not) Running Release version on target machine

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.

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.

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.

I'm very grateful for your help and guidance. Many thanks!

Kia pai to haere, e hoa!

Plumer




"Daniel O'Connell [C# MVP]" wrote:
[color=blue]
>
> "Plumer" <Plumer@discuss ions.microsoft. com> wrote in message
> news:5F7475E4-B21B-4D74-BAF9-80E373E625B4@mi crosoft.com...[color=green]
> > Good morning Chris
> >
> > Many thanks for your prompt and helpful response.
> >
> > No, the Framework is not on the laptop and I did wonder if that was the
> > problem. But when I checked in Control Panel I saw an entry for the
> > framework
> > on the desktop for Framework Version 1.0.3705 that occupied 2079MB! And
> > then
> > I thought "Does this mean I have to install that on every machine that I
> > want
> > an app to run on?? Surely not..."
> >[/color]
>
> Most likely you are seeing the SDK, not the runtime itself. The SDK is
> rather large and includes all of the help files and other documents you use
> regularly for development.
>
> The runtime installer is about 20meg(60 or 100 extracted, I think. Its been
> awhile since I've looked), still not small but considerablly better than 2
> gigs.
>
>
>[/color]

[Daniel O'Connell [C# MVP]]

Re: (Not) Running Release version on target machine


"Plumer" <Plumer@discuss ions.microsoft. com> wrote in message
news:85EAC657-9856-46FE-BD6E-44A3D7620514@mi crosoft.com...[color=blue]
> 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.[/color]

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.

[color=blue]
> 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.
>[/color]

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.

[color=blue]
> 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.[/color]

Unfortunatly, there is no standalone support in the framework itself. There
is a product..salama nder 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.

[Plumer]

Re: (Not) Running Release version on target machine

Good morning Daniel

Since yesterday I’ve been pursuing some of the things that you highlited in
your very complete and useful response. Many thanks for taking the time to
write that out for me.

I now understand the issue reasonably clearly and it seems that my
expectations were a little unrealistic.

I tried to run a search on DLLs on my computer but it failed repeatedly and
I gave up but nevertheless I take your point about multiple copies of dlls
and static linkage.

As a consequence of some of your comments, I’ve been prowling around in the
C# help and can now see what needs to happen.

Thanks again. I appreciate your help

Kia pai to haere, e hoa!
Plumer