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!
"Gabriel Magaña" wrote:
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...
"Shiraz" <Sh****@discussions.microsoft.com> wrote in message
news:B5**********************************@microsof t.com... 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!
