views:

15

answers:

1

We have a requirement for a C drive or D drive installation for one of our programs. What I need the installation to do is if the installation detect a D drive that has a certain folder structure like so:

D:\AppData

If it finds it, it will install it there. If it doesn't find it, it will install it here:

C:\AppData

I am using VS 2008

A: 

It is a violation of windows installer best practices to hard code an installer to any specific drive. This is why we use things like [WindowsVolume] and [ProgramFilesFolder].

That said, it's ok for a custom action to provide an override conditionally at install time provided that if the custom action can't find a specific override it'll go back to the standard best practices.

Forexample

Respect command line defualts as a first priority. Try set D:\AppData Try set C:\AppData Else Default [WindowsVolume]\AppData ( not done by custom action, built into directory table )

Then later provide a dialog to allow user to interactively overrride

When I say "Try" I mean write some code to see if a fixed disk of that letter exists

Now the problem for you is going to be it sounds like you are using Visual Studio Deployment Projects and frankly this tool won't give you the flexibility you need (without some clever post build proccessing ) to insert the custom action the way you need it. Assuming you're tools will support what you need, write a custom action that:

Scheduled before Cost Initialize in both the UI and Execute Sequence ( to support silent installs )

Condition it to not run if the property is already set ( to respect command lines ) and if the product is Not Installed ( you can't change the directory during a repair or maint operation; it is fixed )

Schedule it to only run once ( so that the CA won't override any changes the dialog made )

Christopher Painter
All custom actions seem to be "after" it installs not before.
friendlyProgrammer
Correct, the problem is Visual Studio Deployment Projects don't expose the types of scheduling options that you need. It only gives you an abstraction of rollback, install, commit and uninstall which are all in the execute sequence way after where you need to schedule.If you want to be able to accomplish what you are trying to do you will have to either 1) dump vdrpoj 2) get good at tweaking built msi-s as postbuild steps or 3) encapsulate the behavior in a merge module using a tool other then vdrpoj and then consume the module with vdproj.
Christopher Painter
Thanks for your reply.
friendlyProgrammer