By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,830 Members | 1,758 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,830 IT Pros & Developers. It's quick & easy.

Simple XCOPY operation as part of VS7 Setup project?

P: n/a
I am busy packaging our product as a standard Setup project in VS.NET that
uses
a bunch of merge modules (basically, a merge module for every key
infrastructure
component in our system).

Part of the installation needs to "dump" a bunch of files (third party
product's project
files) to the user's system. These files are transient in nature in that the
user may choose
to remove some of them over the lifetime of our application.

The problem I have is: If I put these files in a merge module like
everything else,
and the user removes one of the files after installation, Windows Installer
automatically
pops up and wants the user to point it to the original setup project so it
can "repair"
the installation, since files it installed are no longer present.

Does anyone know a way I can facilitate a simple XCOPY-like deployment of
the set
of files, but as part of the bigger setup project? I do not wish the Windows
Installer
to monitor when these specific files go missing, but checking the rest of
the installation
is OK.

Regards
Ryno
Jul 21 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
How about writing a simple app to copy the files and
executing it from the install?

-----Original Message-----
I am busy packaging our product as a standard Setup project in VS.NET thatuses
a bunch of merge modules (basically, a merge module for every keyinfrastructure
component in our system).

Part of the installation needs to "dump" a bunch of files (third partyproduct's project
files) to the user's system. These files are transient in nature in that theuser may choose
to remove some of them over the lifetime of our application.
The problem I have is: If I put these files in a merge module likeeverything else,
and the user removes one of the files after installation, Windows Installerautomatically
pops up and wants the user to point it to the original setup project so itcan "repair"
the installation, since files it installed are no longer present.
Does anyone know a way I can facilitate a simple XCOPY- like deployment ofthe set
of files, but as part of the bigger setup project? I do not wish the WindowsInstaller
to monitor when these specific files go missing, but checking the rest ofthe installation
is OK.

Regards
Ryno
.

Jul 21 '05 #2

P: n/a
That's one option - but it would mean distributing the files in "raw" format
with the
distribution media, or archiving it into cab files (from where I am not too
sure
how to extract to a specified folder automatically without user
intervention)... it
would also complicate the build process unnecessarily. I was hoping for some
setting/twiddly bit thing somewhere that specifies that the installer should
not
care about the files after installation... ? If not, I suppose a manual
xcopy as a
custom action will have to do...

"AlexB" <an*******@discussions.microsoft.com> wrote in message
news:01****************************@phx.gbl...
How about writing a simple app to copy the files and
executing it from the install?

-----Original Message-----
I am busy packaging our product as a standard Setup

project in VS.NET that
uses
a bunch of merge modules (basically, a merge module for

every key
infrastructure
component in our system).

Part of the installation needs to "dump" a bunch of files

(third party
product's project
files) to the user's system. These files are transient in

nature in that the
user may choose
to remove some of them over the lifetime of our

application.

The problem I have is: If I put these files in a merge

module like
everything else,
and the user removes one of the files after installation,

Windows Installer
automatically
pops up and wants the user to point it to the original

setup project so it
can "repair"
the installation, since files it installed are no longer

present.

Does anyone know a way I can facilitate a simple XCOPY-

like deployment of
the set
of files, but as part of the bigger setup project? I do

not wish the Windows
Installer
to monitor when these specific files go missing, but

checking the rest of
the installation
is OK.

Regards
Ryno
.

Jul 21 '05 #3

P: n/a
This can be done by setting conditions on the files that you do not want reinstalled.
To do this select the files in the Merge Module Project that you do not wish to be reinstalled, set the Transitive property to be true (This will cause the
condition to be reevaluted on the system during a reinstall). Then set the condition to be something that will fail on reinstall (for example a registry key you
have created not existing).
This will work if you have created the Merge Modules yourself as your post led me to believe, there is a way to accomplish this with pre packaged merge
modules but it is slightly more complicated.

--------------------
Todd Derksen
This posting is provided "as is" with no warranties and confers no rights.
--------------------
| From: "Ryno Rijnsburger" <no****@hotmail.com>
| References: <#2**************@tk2msftngp13.phx.gbl> <01****************************@phx.gbl>
| Subject: Re: Simple XCOPY operation as part of VS7 Setup project?
| Date: Tue, 4 Nov 2003 13:36:53 +0200
| Lines: 68
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
| X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
| Message-ID: <Ov**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.general
| NNTP-Posting-Host: tbnb-109-87.telkomadsl.co.za 165.165.109.87
| Path: cpmsftngxa06.phx.gbl!cpmsftngxa09.phx.gbl!TK2MSFTN GP08.phx.gbl!TK2MSFTNGP12.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.general:114262
| X-Tomcat-NG: microsoft.public.dotnet.general
|
| That's one option - but it would mean distributing the files in "raw" format
| with the
| distribution media, or archiving it into cab files (from where I am not too
| sure
| how to extract to a specified folder automatically without user
| intervention)... it
| would also complicate the build process unnecessarily. I was hoping for some
| setting/twiddly bit thing somewhere that specifies that the installer should
| not
| care about the files after installation... ? If not, I suppose a manual
| xcopy as a
| custom action will have to do...
|
| "AlexB" <an*******@discussions.microsoft.com> wrote in message
| news:01****************************@phx.gbl...
| > How about writing a simple app to copy the files and
| > executing it from the install?
| >
| >
| > >-----Original Message-----
| > >I am busy packaging our product as a standard Setup
| > project in VS.NET that
| > >uses
| > >a bunch of merge modules (basically, a merge module for
| > every key
| > >infrastructure
| > >component in our system).
| > >
| > >Part of the installation needs to "dump" a bunch of files
| > (third party
| > >product's project
| > >files) to the user's system. These files are transient in
| > nature in that the
| > >user may choose
| > >to remove some of them over the lifetime of our
| > application.
| > >
| > >The problem I have is: If I put these files in a merge
| > module like
| > >everything else,
| > >and the user removes one of the files after installation,
| > Windows Installer
| > >automatically
| > >pops up and wants the user to point it to the original
| > setup project so it
| > >can "repair"
| > >the installation, since files it installed are no longer
| > present.
| > >
| > >Does anyone know a way I can facilitate a simple XCOPY-
| > like deployment of
| > >the set
| > >of files, but as part of the bigger setup project? I do
| > not wish the Windows
| > >Installer
| > >to monitor when these specific files go missing, but
| > checking the rest of
| > >the installation
| > >is OK.
| > >
| > >Regards
| > >Ryno
| > >
| > >
| > >.
| > >
|
|
|
Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.