Testing Setup project on single dev machine

[Mitch Gallant]

I have VS 2005 installed on XP Pro sp2 machine. I have built fairly basic
console applications, compiled using /MD so they require the MSVCR80.dll
at runtime.

I use *two* different approaches:
(1) add the necessary dependencies (Microsoft_VC80_CRT_x86.msm)
to my Setup Project which will ensure that 3 dlls that comprise that
side-by-side assembly, are installed in the target native assembly
cache %windir%\SxS\ ...
(2) remove the necessary dependency above in the project, but add a Prerequisite
to the Setup Project, requiring "Visual C++ Runtime Libraries (x86) which
if I understand correctly, essentially adds the bootstraper vcredist_x86.exe to
the setup file. This installs the CRT as well as MFC and ATL dlls.

I only have one machine, the dev machine with XP Pro sp2 and VS 2005.

I'd like to see the XP end user install experience, for the two different scenarios
above (generating the WinSxs\ .. folders and installing the side-by-side assemblies)
as described here:
http://msdn2.microsoft.com/en-us/library/ms235317.aspx
How should I do this (on the same machine)? Can I rename the existing WinSxS folder
(generated by VS 2005) and see the installer regenerate it (with limited contents) ?
I'd like my VS 2005 machine to appear to the installer as if it doesn't have the dependencies
required. (I don't need .NET 2 installed .. for native C++ app installer I'm testing).

Thanks,
- Mitch Gallant
MVP Security

[Mitch Gallant]

It is not possible to rename the SxS native assembly cache folder in XP
.. a message indicates it is in use by the system.

I tried the 2nd approach below (add Prerequisite of "Visual C++ Runtime.." and
when the Setup project is compiled, it simply puts a new directory vcredist_x86
containing, of course, vcredist_x86.exe, in the project output directory along
with the compiled application exe.
Interestingly, when I ran the setup.exe on this dev machine (with VS 2005 installed),
the FIRST time it was run, it actually runs the vcredist_x86.exe! Why does
this happen the first time? I thought the msi would have picked up my
VS 2005 install already and the existing WinSxS? Subsequent executions (after
removal of the application) of setup.exe do NOT execute the vcredist_x86.exe as expected.

- Mitch

"Mitch Gallant" <jens...@community.nospam> wrote in message news:ejYth6r...@TK2MSFTNGP12.phx.gbl...

[Kevin Yu [MSFT]]

Hi Mitch,

We have reviewed this issue and are currently researching on it. We will
update you ASAP. Thanks for your patience!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Steve Barnett]

Have you thought about trying Virtual PC?
http://www.microsoft.com/windows/virtualpc/default.mspx

I'm considering it for my install testing as it'll give me the chance to
create a "basic" machine configuration that I can quickly clone and restore
once the install test has been completed. The only thing stopping me at the
moment is trying to determine whether my laptop has the resources necessary
to run the guest operating system.

Steve

"Mitch Gallant" <jens...@community.nospam> wrote in message
news:ejYth6r...@TK2MSFTNGP12.phx.gbl...

[Gary Chang[MSFT]]

Hi Mitch,

>Interestingly, when I ran the setup.exe on this dev machine

>the FIRST time it was run, it actually runs the vcredist_x86.exe!
>Why does this happen the first time? I thought the msi would
>have picked up my VS 2005 install already and the existing
>WinSxS?

Such a behavior is as expected. This is because your dev machine hadn't
installed the Visual C++ 2005 Runtime Libraries redistributable product
before.

The VC2005 runtime libraries of your dev machine are installed by the
VS2005 product. So when you specify the Visual C++ Runtime Libraries
redistributable as your installation package's prerequisites, its
bootstrapper(setup.exe) will check whether the VC2005 Runtime Libraries has
been installed in the target system instead of checking the corresponding
VC2005 runtime libraries.

Thanks!

Best regards,

Gary Chang
Microsoft Community Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD will be updated at 9:00
AM PST, February 14, 2006. Please complete a re-registration process by
entering the secure code mmpng06 when prompted. Once you have entered the
secure code mmpng06, you will be able to update your profile and access the
partner newsgroups.
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from this issue.
======================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

======================================================

[Mitch Gallant]

OK that sounds reasonable. But apart from version issues, doesn't
VC2005 install all of the libraries and more of course (say in WinSxS\..)
that Visual C++ Runtime Libraries redistributable installs?

Apart from the product versiononing tracking and product install/removal,
does the current Visual C++ Runtime Libraries (x86) installer install
any files on the target system that are not ALREADY there from the
VC2005 installation?

Thanks,
- Mitch

""Gary Chang[MSFT]"" <v-ga...@online.microsoft.com> wrote in message news:fR%23WUyAS...@TK2MSFTNGXA03.phx.gbl...

[Mitch Gallant]

What about REMOVING the Visual C++ Runtime Libraries (x86)
using Add/Remove? Does that clobber/remove any of the shared
assemblies that VS 2005 installs (say under ...WinSxS\ ?
- Mitch

"Mitch Gallant" <jens...@community.nospam> wrote in message news:O%23r7xFDS...@TK2MSFTNGP12.phx.gbl...