Relative Paths?

[SBM]

I am currently in the middle of the most painful product evaluation cycle I have ever been involved in. I cannot believe the state of the Windows Installer authoring software: One big pile of copycat software that completely misses the point of the software engineering cycle.

InstallAware is a fresh approach and I give it high marks for hitting near the target.

For now, I have one question and one comment:

Comment: .NET assemblies are the future. Calling Installer classes in the assemblies ... also the future. Please don't make developers jump though hoops to accomplish this in a properly transactioned way.

Question: I want a single script/XML file/whatever that describes what files in my project tree belong where on the target machine. Project trees in professional organizations start with $, not c:. That is, the project tree is relative to the defined working directory for a given user/machine combination. Also, I would really like the same script to generate an install set off of either the debug or release output. Variables in source path names would be dandy (would blow all other products out of the water). In a pinch, pathnames that were relative to the script/XML file/whatever would make this possible. I have not been able to accomplish either in InstallAware. Can it be done?

[sinan]

Thanks for your feedback. Its great to have developers appreciate the vision behind InstallAware

Calling installer classes in assemblies in a properly transactioned way: Could you please, privately if necessary, provide an example of how this may be satisfactorily accomplished? We would provide it as a plug-in that can be directly tapped by the InstallAware engine (we cannot hard code it into the product because then all our installs would require the .NET FX to run).

About your question...I'm not sure I completely understand what you say, but I think the ideas below should get you started:

1) Use compiler variables. At build time, you set the values of compiler variables either on the command line or in the IDE, and these values are hard-coded into your script right before it gets compiled. Now there are two primary uses for compiler variables:
a) To selectively include/omit portions of code
b) To insert values into the script - such as variables for source path names!
2) In the IDE, you can use the Project->Refactor Paths tool to replace the currently hard-coded path values with other hard-coded path values, including of course, compiler variables.

3) The command line build tool (and the IDE, of course) can emit all three supported build types with the appropriate command line switches - CD, SFX, and Web.

Are these helpful? Please let me know if you need more information.

Code: Select all

Note that while variables are referenced as $VAR$, compiler variables are referenced as #VAR# in the script.

[SBM]

Cool! I couldn't find the #MYVAR# syntax in the help yesterday. Of course, today it jumps right out at me. And it does just exactly what I hoped it would.

You guys rock!

In re .NET Installer classes: I will think about it some more before I shoot my mouth off. There is another thread on this forum that is dealing with the issue; I will follow it while I complete my testing.

Thanks for the prompt response.