Deployment with Visual Studio 2005 C++

[tharris]

I am new learning how to use Visual Studio 2005 to program in C++. I
have been having trouble deploying my applications onto another
computer. I also use the Bloodshed Dev C++ compilier and when I
compile my program it creates a exe that I can simply copy onto
another computer and it will run. However, with Visual Studio I must
create a setup project. I have tried using the help system and it
didn't give me simple enough steps for me to complete my setup
project. I am wriing win32 console applications (I just completed an
introduction to C++ course) and according to the help I need to use
the MS Installer to deploy this type of program. What should I use
when I start creating Windows forms applications?

Is there anyone that has been able to create a setup project that
actually works? I could use some advice.

 

[Victor Bazarov]

I am new learning how to use Visual Studio 2005 to program in C++. I
have been having trouble deploying my applications onto another
computer. [..]
Is there anyone that has been able to create a setup project that
actually works? I could use some advice.

I am pretty sure that there is plenty of people who have successfully
created a setup project. Only this newsgroup is not the right place
to discuss it. Please turn to microsoft.public.vc.* newsgroups (on
'msnews.microsoft.com' server if your ISP doesn't carry them).

V

 

[Andre Kostur]

@w5g2000hsg.googlegroups.com:

[snip VC++-specific stuff]

Is there anyone that has been able to create a setup project that
actually works? I could use some advice.

You're asking in the wrong place. comp.lang.c++ discusses the Standard C++
language. You want to ask in a Microsoft-specific newsgroup.

 

[Michael]

I am new learning how to use Visual Studio 2005 to program in C++. I
have been having trouble deploying my applications onto another
computer. I also use the Bloodshed Dev C++ compilier and when I
compile my program it creates a exe that I can simply copy onto
another computer and it will run. However, with Visual Studio I must
create a setup project.

VS will create an EXE for you. No setup project required. Just
create a Console App project, put your files in, and compile. The EXE
will be in the debug/ or release/ directory (you'll probably want to
run the release build for your actual release).

Michael

 

[James Kanze]

VS will create an EXE for you. No setup project required. Just
create a Console App project, put your files in, and compile.

I don't think it has to be a Console App project. On the other
hand, you will have to ensure that any libraries that are not
bundled with the system are statically linked. This seems to be
a universal problem with C++. On the systems I work on---all
Unix---the C libraries are bundled with the system, and you can
just compile and link with the standard options, and the
resulting executable runs everywhere. The C++ libraries,
however, are NOT bundled (except generally with Linux), and by
default, you will probably end up with them being dynamically
linked. And the program not running on systems where C++ is not
installed.

The EXE
will be in the debug/ or release/ directory (you'll probably want to
run the release build for your actual release).

You probably won't. In practice, you'll probably want to
develop your own list of options, which does something sensible.
The debug options that VS uses aren't really that bad, but the
release options turns off assert's, which means that you
definitly don't want to use them as is in code you deliver.

 

[Michael]

VS will create an EXE for you. No setup project required. Just

I don't think it has to be a Console App project.

Indeed not, but since the OP specified that he was making console
apps, it should be. But yes, if he were making some other kind of
app, that would work too, as long as it were statically linked.

You probably won't. In practice, you'll probably want to
develop your own list of options, which does something sensible.
The debug options that VS uses aren't really that bad, but the
release options turns off assert's, which means that you
definitly don't want to use them as is in code you deliver.

Clearly you don't get the concept of asserts. The whole point is that
you can put in all sorts of anal checks that are useful for you in
developing, but you never want the client to see.

For one thing, you may put in things that slow the program down a
lot. For example, I read that Excel has a version of its
recalculation engine that is really dog slow (several minutes to
recalculate), but is so simple it works every time, and their
production version uses all kinds of fancy algorithms to save time by
doing minimal recalculations (< 1 sec recalc time, typically). They
have various asserts where they run the dog slow version and the
production version and compare that the results match - you wouldn't
want to do that in the shipping version.

For another thing, if an assert fails, the program crashes in a
particularly hideous way. That is not at all appropriate for
production code - at a minimum you should crash cleanly and give the
user a cryptic error message ("An error of type 123 occurred. Click
OK.") Of course, there are even better ways to handle this. See Alan
Cooper's books for details.

Michael

 

[James Kanze]

Clearly you don't get the concept of asserts. The whole point is that
you can put in all sorts of anal checks that are useful for you in
developing, but you never want the client to see.

Clearly YOU don't get the concept of asserts. They're like a
life jacket on a boot. Do you wear a life jacket when the
boot's in the harbor, and take it off when you go to sea.

For one thing, you may put in things that slow the program down a
lot. For example, I read that Excel has a version of its
recalculation engine that is really dog slow (several minutes to
recalculate), but is so simple it works every time, and their
production version uses all kinds of fancy algorithms to save time by
doing minimal recalculations (< 1 sec recalc time, typically). They
have various asserts where they run the dog slow version and the
production version and compare that the results match - you wouldn't
want to do that in the shipping version.

That's a rather extreme case. Especially given that an assert
must be a single expression, without side effects. Still, there
are times when the profiler says you can't. In which cases, you
do something like:

#ifdef PRODUCTION
#define NDEBUG
#include <assert.h>
// critical section...
#undef NDEBUG
#include <assert.h>

The assert.h header was carefully designed intentionally for
this, so that you could just remove the asserts from a single
function, without removing them from the rest of code.

For another thing, if an assert fails, the program crashes in a
particularly hideous way.

And if the condition occurs, and the assert isn't there? The
program crashes sometime later, in just a hideous way. Or
worse, it doesn't crash, and the user doesn't realize that the
results are wrong.

That is not at all appropriate for
production code - at a minimum you should crash cleanly and give the
user a cryptic error message ("An error of type 123 occurred. Click
OK.")

The usual solution here is to wrap the program in a small
script, which captures the error message AND the core dump, and
informs the user in whatever way is appropriate that the error
has occured. For the type of applications I work on, the script
usually restarts the program.