Can SUF7 read ini and write into itself at compile?

[tmcguire]

I'd like to have suf7 read an .ini file at compile time (generating .exe), and write a value into the .exe (version) rather than set it in suf7 itself.

Can it? This would be nice for maintaining a simple file (ini) for managing all projects' versions.

Pointers would be appreciated.

[Corey]

Hi. Yes, check out the INIFile group of actions. Each of them has a great description and examples in the help file.

[tmcguire]

re:Can SUF7 read ini and write into itself at compile? Reply to Thread

I didn't mean when the install started running on the end user's system.

I meant when I was compiling the project into a setup.exe.

As SU7 compiles the project, it reads an .ini file on my (C drive - and writes the version # (for instance) into the setup.exe file.

This, rather than including an .ini file on a CD (Internet version, for instance) or writing the value into the SU7 project file.

[Corey]

Hi. Sounds like a session variable might work better for that task, i.e. %ProductVer%. As far as I know using an .ini file in the way you describe isn't possible but it's definitely possible to achieve that same type of functionality, perhaps more efficiently, using Session Variables... Hope that helps.

[tmcguire]

...but it's definitely possible to achieve that same type of functionality, perhaps more efficiently, using Session Variables...

Type of functionality on the user's end, and I'm aware of that.

But I was hoping for something on the development end.

OK. I won't spin my wheels looking for it.

And thank you for the prompt reply.

[Corey]

You mean you wish to set your session variables dynamically from an .ini file during the design process?

It's as easy to type them into the app as an .ini file, and it's easy to save that as a blank project which can be opened to start new projects, i.e. you can have several blanks which contain all your typically used session variable sets. So it's very easy to achieve the same functionality you are seeking, but not specifically using an .ini file as far as I know. Session variables are a very efficient way to take care of data such as product version, etc.

As always though, feel free to add it to the suggestion forum along with a few words on why adding this would be helpful to you.

[tmcguire]

You mean you wish to set your session variables dynamically from an .ini file during the design process?

It's as easy to type them into the app as an .ini file

Design process? No, well kinda. At the time the setup.exe is created.

With the .ini file concept, I could manage (parts of) ALL of my projects in one place, rather than in each project. And for those cases where I cannot automatically include an external .ini file (download from Internet) this would be handy.

Again, thanks for replying.

[Corey]

Hi. That is design time. You would still need a seperate .ini for each set of unique session variables, so it's just as easy to create a blank project with each set of session variables. All your blank projects can be kept in one place. Takes only a couple minutes to set up a set of session variables and you can re-use it forever, with a single click... Very efficient. :yes

[Ted Sullivan]

To back up a couple of steps, Setup Factory 7.0 was actually designed with extensive unattended build options in mind so it fits right into your automated build processes.

Your first step is to check out Publish > Settings menu. That's where you can set up Build Configurations and Constants. You'll also find Pre/Post Build Steps as well.

Here is a link to the topic in the documentation:

http://www.indigorose.com/webhelp/suf70/Program_Reference/Build_Settings/Constants.htm

The next thing is to check out are Setup Factory 7.0 Command Line Options. In particular, the Unattended Build Options.

Here is the topic from the help file:

http://www.indigorose.com/webhelp/suf70/Program_Reference/Command_Line_Options.htm#Unattended_Build_Options

The following command line options are used supported by Setup Factory's design environment for an unattended build process:

Note: The unattended build returns 0 as a process return code if successful, or non-zero if not. You can use this return code to make your batch files respond to the success or failure of the Setup Factory build process.

/BUILD
Tells Setup Factory to build the project file passed in on the cmd line or from a batch file. For example:
"C:\Program Files\Setup Factory 7.0\SUF70Design.exe" /BUILD "C:\TestProj.sf7"

/CONFIG:<<ConfigName>>
Specifies the build configuration to use in the build. If not specified, the first build configuration found in the project is used. For example:

"C:\Program Files\Setup Factory 7.0\SUF70Design.exe" /BUILD "C:\TestProj.sf7" "/CONFIGebugConfig"

/LOG:<<log file path>>
Specifies a log file to output build status to. If the file exists, the output will be appended to it. If the file does not exist, it will be created. For example:

"C:\Program Files\Setup Factory 7.0\SUF70Design.exe" /BUILD "C:\TestProj.sf7" "/LOG:C:\output\Log.txt"

/STDOUT
Makes the build status go to the standard output device (console). For example:

"C:\Program Files\Setup Factory 7.0\SUF70Design.exe" /BUILD "C:\TestProj.sf7" "/STDOUT"

/CONST:<<ini file path>>
Lets you specify an INI file that contains design-time constants to override the ones in the project. You can define as many design-time constants as you want in the INI file, with each constant on a separate line beneath the [Constants] section. Each constant that is defined in the INI file must already be defined in the project file. For example:

[Constants]
#OUTPUTDIR#=C:\Output\Foobar 2002\Release
#SETUPNAME#=foobar2002setup.exe
#BUILD#=release

When you use the /CONST option along with /BUILD, the specified project file is loaded into Setup Factory, the constants described in the specified unattended-build INI file are set, and the setup executable is generated-all without any interaction.

For example:
"C:\Program Files\Setup Factory 7.0\SUF70Design.exe" /BUILD "C:\TestProj.sf7" "/CONST:C:\MyProj\Config.ini"

That should get you started!

[Corey]

Ahhh, very sorry about the misinformation tmcguire. I'm still not up on unattended builds, my bad. Glad Ted corrected everything.

[Brett]

Yeah, SUF70 is fantasic for unattended builds. Here is the way to do it:

1. If you have anything that is static but different between two builds out of the same project, use build configurations to set them up. Then when you build, just pass in the appropriate configuration. For example, building a demo version and commercial version out of one SUF7 project.

2. Put your version number in a design-time constant such as #VERSIONNUM#. Then use this variable wherever you want to referr to the version number in the setup.

3. At build time, have your batch file or build tool (I like Visual Build) write the version number out to an INI file like so:

[Constants]
#VERSIONNUM#=1.0.34.32

and then pass the INI file path into the command line (/CONST:...)

That will do the trick. If that does not give you enough to get going, post back and I will try and clarify further.

- Brett