Changes to meaning of #APPPATH?

Nov 12, 2010 at 4:38 PM

I built a bootstrapper a few weeks ago, but today when I tried again with the latest 2.0 beta it failed saying it couldn't find the redistributables. It turns out that the meaning of #APPPATH seems to have changed.

During the build I'm running installerLinker as "dotNetInstaller 2.0\bin\installerLinker.exe" and #APPPATH used to be set to the bin directory, but now seems to be getting set to the current directory.  The only substantial thing I've changed in the config file is to move from using htmlInstaller.exe to dotNetInstaller.exe (I also updated the version number).  Which directory should #APPPATH be set to?

Nov 12, 2010 at 11:18 PM
Edited Nov 12, 2010 at 11:18 PM

This did change in rev. 20737. The old value was Path.GetDirectoryName(Path.GetFullPath(args.config)). This way one could specifiy a configuration.xml which could have relative paths to it. But it made little sense if you tried to embed files relative to your current location on the command-line, you'd say "/EmbedFile:Foo\Bar.txt" and that would look for Foo\Bar.txt under the folder where the configuration.xml is. I thought it was weird, if you specify a relative path, the common sense would be that it's relative to where you are, not to some file.

You can certainly argue with my assessment :)

In general, just set /apppath on the command line to be where you want it to be so that there's no ambiguity.

Nov 13, 2010 at 12:05 AM

Thanks - I do think the change makes more sense.

Mar 20, 2012 at 9:25 PM
Edited Mar 20, 2012 at 9:26 PM

That change doesn't make sense at all!

I'm new to dotnetinstaller so maybe I'm missing something, but  I need the ability to have a relative path instead of an absolute path. I need to create a configuration that will be saved to a source repository so that any member of my team can run it without having their repository files in a particular location or drive on their system.

Also, when I try to create an exe from the editor, #APPPATH always equals C:\Windows. #WINDOWSPATH already exists, so why do we need #APPPATH to point there as well?

Mar 21, 2012 at 12:04 AM

It can't be everything to everyone :) I still think it's confusing for tools to have a path relative to the config file.

@somna, just specify /apppath with a value to a location that you want, including relative to where you are.

Mar 21, 2012 at 2:22 AM

The editor opens up the config file as if it is a project. I don't see how it would be confusing to have the path relative to the bootstrapper project. So we have to use the command line instead of the editor then? I guess it's time to write a bat file instead of using the tools you've provided.

Mar 22, 2012 at 6:37 PM
Edited Mar 22, 2012 at 6:38 PM

Here's the bat file in case anyone else is having the same problem. Save the bat file in the same folder as the config file.

SET ProgFiles86Root=%ProgramFiles(x86)%
IF NOT "%ProgFiles86Root%"=="" GOTO cpu64
SET ProgFiles86Root=%ProgramFiles%
"%ProgFiles86Root%\dotNetInstaller\bin\InstallerLinker.exe" /Output:Setup.exe /Template:"%ProgFiles86Root%\dotNetInstaller\bin\dotNetInstaller.exe" /Configuration:bootstrapper.xml /Verbose+

Mar 22, 2012 at 11:43 PM

You also don't have to "install" DNI, that just creates an icon. For developer tools we usually commit those along with source and make tasks with MSBuild. 

May 2, 2012 at 2:19 AM

This should not have been changed, it should have been an option.

You could have at least have consulted your users.

This has caused me hours of trouble.

May 9, 2012 at 6:47 AM

Hi, I am new to dotnetInstaller. I want to check the directory path in ProgramFiles folder i.e., Program Files and Program Files (x86) on Win 7 32 & 64 bit. Can any one please let me know whether we have any Path variables to check them or dowe need to write any scripts, if so how to do that ?... Please let me know...


May 11, 2012 at 12:00 AM

Please ask questions on the new google group:!forum/dotnetinstaller