Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Visual Studio.NET / Setup / June 2007

Tip: Looking for answers? Try searching our database.

Deleting a custom action file after it has run

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
David Jackson - 22 Jun 2007 22:59 GMT
Hello,

Scenario: a WinForms app written in VS.NET 2005 (C#) and installed via a
Setup and Deployment project.

This is an upgrade of an old VB6 app which used the Registry to persist
certain data, but the C# app doesn't use the Registry - it uses the
Properties Settings.settings functionality instead.

Because I couldn't find any way in the standard Setup & Deployment project
to read values from the Registry and then copy them into the new
Settings.settings file, I wrote a small C# executable to do this instead,
which I set as a Custom Action in the Setup & Deployment project.

This is working correctly. The whole thing is packaged as an MSI. When it
runs, the upgrade executable is deployed along with the main app's files,
and is run at the end of the installation process. The resulting folder
looks something like this:

<MyApp>
   MyApp.exe
   MyApp.exe.config
   MyApp.ico
   MyApp_Upgrade.exe

What I would like to do now is have the MSI delete the MyApp_Upgrade.exe
file after it has run it, but there doesn't seem to be any way of doing this
in the Setup & Deployment project.

Curiously, if I delete it manually (or even have the main app delete it), it
gets recreated every time the app is run if the MSI is still on the machine!
I'm presuming there's some sort of setting for this which I have missed?

I should point out (in case anyone wonders) that the only reason I have for
wanting to do this is purely cosmetic / aesthetic... Leaving the
MyApp_Upgrade.exe in the application's installation folder causes no
problems whatsoever. But I would like to delete it because it's no longer
required.

Does anyone know of any way to do this?

Thanks,

DJ
Phil Wilson - 23 Jun 2007 21:12 GMT
Auto repair when you remove files is a default feature of MSI setups.
There's no setting in the IDE to rurn it off.

Does Visual Studio allow you to right-click Exclude on the executable in
solution explorer? If so, that runs it out of a temp location and is removed
afterwards.

Signature

Phil Wilson
[Microsoft MVP-Windows Installer]

> Hello,
>
[quoted text clipped - 41 lines]
>
> DJ
David Jackson - 25 Jun 2007 13:24 GMT
Hi Phil,

Thanks for the reply.

> Auto repair when you remove files is a default feature of MSI setups.
> There's no setting in the IDE to rurn it off.

Ah - that would explain it!

> Does Visual Studio allow you to right-click Exclude on the executable in
> solution explorer?

Yes it does.

> If so, that runs it out of a temp location and is removed afterwards.

I tried that, but now the installer gives an error that it cannot find
Interop.IWshRuntimeLibrary...

The executable uses this library to search for unused icons on the target
machine's desktop and remove them if it finds any...

Thanks,

DJ

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.