Deploying C++

Ben wrote:

Hi,

I have a project that uses the c runtime libraries a bit of opengl and
nothing else. If I build the .exe for release using Visual Studio 6 I
can copy the .exe onto Win98,NT and 2K/XP and run it with no probs.

If I build the same .exe using Visual Studio.NET and drop the .exe
onto the above windows platforms I get prompted with errors
complaining that the .exe can't find MSVCP70...dll.

Am I doing something wrong or do I now have to use the deployment
wizard to package up dependencies that didn't exist before?

No, you're not doing anything wrong - it just happens that the VC6 runtime
DLLs are already present on the machines you've targeted, while the VS7 DLLs
are not.

You need to deploy those VC7 runtime DLLs that your app depends on. Using a
deployment project is probably the easiest way to get them installed
properly, but you're free to use any install tool of your choice. There are
merge modules (Windows Installer) for all of the VC7 runtime libraries that
are installed along with Visual Studio. They get installed into
%bootdrive%\Program Files\Common Files\Merge Modules by default.

-cd

"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote in message news:<Ot*************@TK2MSFTNGP09.phx.gbl>...

Ben wrote:

Hi,

I have a project that uses the c runtime libraries a bit of opengl and
nothing else. If I build the .exe for release using Visual Studio 6 I
can copy the .exe onto Win98,NT and 2K/XP and run it with no probs.

If I build the same .exe using Visual Studio.NET and drop the .exe
onto the above windows platforms I get prompted with errors
complaining that the .exe can't find MSVCP70...dll.

Am I doing something wrong or do I now have to use the deployment
wizard to package up dependencies that didn't exist before?

No, you're not doing anything wrong - it just happens that the VC6 runtime
DLLs are already present on the machines you've targeted, while the VS7 DLLs
are not.

You need to deploy those VC7 runtime DLLs that your app depends on. Using a
deployment project is probably the easiest way to get them installed
properly, but you're free to use any install tool of your choice. There are
merge modules (Windows Installer) for all of the VC7 runtime libraries that
are installed along with Visual Studio. They get installed into
%bootdrive%\Program Files\Common Files\Merge Modules by default.

-cd

If you do not want to be dependent on the compiler dll, link your
project with static lib
By default project uses runtime in DLL, but this can be change in the
project property.

Danderson

Cheers for the reply Carl - it's a shame I can't choose to link to the
old c runtime libs - my installation's dependency list is unecessarily
large for what I want to do.

"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote in message news:<Ot*************@TK2MSFTNGP09.phx.gbl>...

Ben wrote:

Hi,

I have a project that uses the c runtime libraries a bit of opengl and
nothing else. If I build the .exe for release using Visual Studio 6 I
can copy the .exe onto Win98,NT and 2K/XP and run it with no probs.

If I build the same .exe using Visual Studio.NET and drop the .exe
onto the above windows platforms I get prompted with errors
complaining that the .exe can't find MSVCP70...dll.

Am I doing something wrong or do I now have to use the deployment
wizard to package up dependencies that didn't exist before?

No, you're not doing anything wrong - it just happens that the VC6 runtime
DLLs are already present on the machines you've targeted, while the VS7 DLLs
are not.

You need to deploy those VC7 runtime DLLs that your app depends on. Using a
deployment project is probably the easiest way to get them installed
properly, but you're free to use any install tool of your choice. There are
merge modules (Windows Installer) for all of the VC7 runtime libraries that
are installed along with Visual Studio. They get installed into
%bootdrive%\Program Files\Common Files\Merge Modules by default.

-cd

Daniel - thanks for the reply - I tried linking my .dll to the c
runtime libs statically (using the /MD switch) but using process
viewer from sysinternals - when I launch my .exe - it launches my .dll
- it still launches MSVCP70..dll's - do you mean I should link my .dll
project into my.exe statically?

Thanks in advance,
Ben.

da*******@opmr.com (Daniel Anderson) wrote in message news:<ae**************************@posting.google. com>...

"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote in message news:<Ot*************@TK2MSFTNGP09.phx.gbl>...

Ben wrote:

Hi,

I have a project that uses the c runtime libraries a bit of opengl and
nothing else. If I build the .exe for release using Visual Studio 6 I
can copy the .exe onto Win98,NT and 2K/XP and run it with no probs.

If I build the same .exe using Visual Studio.NET and drop the .exe
onto the above windows platforms I get prompted with errors
complaining that the .exe can't find MSVCP70...dll.

Am I doing something wrong or do I now have to use the deployment
wizard to package up dependencies that didn't exist before?

No, you're not doing anything wrong - it just happens that the VC6 runtime
DLLs are already present on the machines you've targeted, while the VS7 DLLs
are not.

You need to deploy those VC7 runtime DLLs that your app depends on. Using a
deployment project is probably the easiest way to get them installed
properly, but you're free to use any install tool of your choice. There are
merge modules (Windows Installer) for all of the VC7 runtime libraries that
are installed along with Visual Studio. They get installed into
%bootdrive%\Program Files\Common Files\Merge Modules by default.

-cd

If you do not want to be dependent on the compiler dll, link your
project with static lib
By default project uses runtime in DLL, but this can be change in the
project property.

Danderson