G
Guest
Alright, I think I have a better perception of assemblies and environment
variables now. The question I had initially posted was pertaining setting of
environment variables using the VSI installer. This was presumed essential
for specifying the paths to certain dlls. Subsequently, the idea was dropped,
and the appication configuration file approach was adopted. However, the
application is not able to resolve the assembly location, and raises a
System.DllNotFoundError exception. I would appreciate if any one of you can
read the following, and give some constructive feedback:
Brief background:
--------------------
The 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.
app.config file modified:
----------------------------
Configuration files seem to be a better way for locating assemblies. Since
the dlls in question were not strongly typed, 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.
Possible problem?:
----------------------
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 if placed in the application folder).
Any help would be great
Thanks!
variables now. The question I had initially posted was pertaining setting of
environment variables using the VSI installer. This was presumed essential
for specifying the paths to certain dlls. Subsequently, the idea was dropped,
and the appication configuration file approach was adopted. However, the
application is not able to resolve the assembly location, and raises a
System.DllNotFoundError exception. I would appreciate if any one of you can
read the following, and give some constructive feedback:
Brief background:
--------------------
The 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.
app.config file modified:
----------------------------
Configuration files seem to be a better way for locating assemblies. Since
the dlls in question were not strongly typed, 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.
Possible problem?:
----------------------
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 if placed in the application folder).
Any help would be great
Thanks!