Running Batch files from Installer to set Environmental variables

[Guest]

Hi

I'm using Visual Studio Installer to make my installer, and have not as yet
figured out a straightforward way to use it to set environmental variables.
Amongst the various things I tried, I'm thinking the following might help. I
would appreciate if someone could comment on this idea and possibly suggest a
better one:

The environement variable in question is 'Path' in the HKCU registry
folder's Environment key. I want to add some new values to it, which I want
the installer to remove upon uninstallation.

-----------------
GIVEN
-----------------
1. Using Setx, the new value can be appended to Path

2. What I would then need is to save the already exsisting path value in a
dummy key:
setx TempKey "%Path%"

3. Next, the new value is appened to path:
setx Path "%Path% theValueString"

4. On uninstallation, path can be restored by overwriting with the value
present in TempKey and the temporary key itself can be discarded.

----------------------------
REQUIRED:
----------------------------
Given the above, I'm guessing I would need to make two batch files, one for
installation and one for the uninstallation, and then somehow use the custom
actions editor to run these two batch files at the right time.

----------------------------
POSSIBLE BOTTLENECK:
----------------------------
I have never worked with batch files (though they don't seem overly
complicated), and I have yet to figure out how to use the custom actions
feature for vsi.

----------------------------
DILEMMA:
----------------------------
a) I haven't yet tried out this solution, so I don't absolutely know if it's
attainable.
b) Does there exsist a cleaner way to achieving the same?

Any help would be great.

Thanks a lot!

 

[James Curran]

Well, it's this doesn't exactly address your question, but......

I *despise* any program whose installer adds folders to my PATH evar.
Create a shortcut in the start menu with properly set "Target" & "Start in"
fields. If still need something in the PATH, you probably should reconsider
the design of your application rather than screwing with your user's
configuration.


--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com

 

[Gabriel Magaña]

I dont know the overall design/reason of what you are trying to achieve, but
you can take advantage of the fact that Windows processes inherit the env
variables of the parent process... For example, if you change the PATH
variable from within your app, you are not really modifying it machine-wide,
only withing your process space. Then if you need to start a child process
that depends on the modified path setting, just make sure you start the
process as a child of your current process (which has the changed
environment variable)...

If this does not exactly fit what you need then tell us a little more about
what you are trying to do... It looks like you are writing an installer or
a program launcher of some sort. Like James, I hate programs that modify
the path globally, but it might not be necessary in this case...

 

[Guest]

Thanks for your reponse. This application uses some dlls imported from C,
which are referenced in the source code. I'm guessing that is why there has
to be a reference to them in the path environment variable. Personally, I
wouldn't like to mess around with the registry either, but the application
doesn't run without these settings in the environment variables.

The reason why I'm not 'entirely sure' if it's because of the dlls that I
have to change the path is that this application has been developed primarily
by other developers. While setting up the environment on my machine though, I
had to make these changes in the env variable setting in order to work on the
application and at that time, I had assumed this to be the reason for making
these changes.

That's why I wanted my installer to append the dlls folder location to the
Path variable during installation and to remove these links after the
application uninstalls.

 

[Guest]

Alright, I think I have a better perception of assemblies and environment
variables now. Perhaps I could re-formulate my question better.

My application uses dlls made in c++/c, which have been wrapped for using in
C#. Initially, we had set the environment variables manually on our machines
to point to the location of these dlls. As expected, that worked without any
problem, though in retrospect, this approach could perhaps have been avoided.

Configuration files seem to be a better way for locating assemblies. Since
the dlls in question were not strongly types, I modified the <probing> tag of
the app.config file instead of the <codeBase> tag. I assumed the application
base folder to be the one where my application executable is located, and
subsequently had my installer place all the folders containing the different
dlls into this directory, so that they may be accessed as subfolders by the
probing tag.

All seemed well so far. One of those folders had the dll in question.
Installing and running the application however, made the application raise an
exception when this dlls was needed, a System.DllNotFoundError.

Thanks to a software one of my colleagues gave me, I was able to monitor the
files that were being accessed by all processes on my computer. On studying
the log, it appeared that my application was searching in all paths, except
for the one specified in the probing tag's privatePath attribute. It is
correctly defined; I have checked up the syntax and examples, so that's not
the reason for the problem. It seems like the application is not able to pick
up this information from the application configuration file, so it does not
look into the concerned subfolder and therefore, raises the given exception.

As a test, I physically copied this dll from the subfolder into the
application folder, and yes, this time the exception was not raised.

I'm not sure where the problem is now. Could it be the config file? Or since
this wrapped dll needs to be invoked by another one, somehow that's not
working (though it does placed in the application folder).

I would appreciate if you could perhaps give me some sort of feedback
regarding this

Thanks a lot!