G
Guest
Hi
It seems like none of the old posts get any follow up after a few messages,
whether or not something constructive comes out of them, so I'm left with no
choice but to repost an earlier question I asked. Below I've copy-pasted the
log of the last post. It's an interesting problem, and it might well be worth
reading if you are willing to be patient.
As always, I would appreciate your comments immensely
Thanks
--------------
START LOG:
--------------
------------------------
MESSAGE 1:
------------------------
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, it 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 the different 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 simplistic 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!
-------------------------------------------------------
MESSAGE 2: (REPLY TO MESSAGE 1)
-------------------------------------------------------
It would help if you could post parts of the config file that are
relevant to your problem. Kinda hard to tell what the problem could be
with your config file without having a look at it
- NuTcAsE
------------------------
MESSAGE 3:
------------------------
Sure I could do that, though I think it might not help.... Here's the block I
used in the config file:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="DllFolder" />
</runtime>
You may assume this to be a subfolder in the application base folder (where
the applciation executable is).
Now I suspect the problem is not because of the config file. It seems to me
that the config file is only read when the application is loaded. If later
the application needs to invoke a dll, the app.config file will not be read
again, and therefore, the application will have no way of accessing the dll.
And since all the dlls I'm using are weakly named, I don't think I can use
any other feature of the config files, either application based or machine
based.
As things stand currently, it seems like I have the following two options:
a) To have the user set the environment variables (Path) or do that from my
installer program, an approach I'm not inclined to taking and I'm sure none
of you will encourage it.
b) The second solution would be to dump all the required dlls in the
application folder: This solution would be less elegant and not as memory
efficient, but atleast it would work...
I'm wondering if there is any other way to permanently set the location for
the application to search the dlls in. Do you have any suggestions that might
help?
Thanks
It seems like none of the old posts get any follow up after a few messages,
whether or not something constructive comes out of them, so I'm left with no
choice but to repost an earlier question I asked. Below I've copy-pasted the
log of the last post. It's an interesting problem, and it might well be worth
reading if you are willing to be patient.
As always, I would appreciate your comments immensely
Thanks
--------------
START LOG:
--------------
------------------------
MESSAGE 1:
------------------------
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, it 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 the different 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 simplistic 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!
-------------------------------------------------------
MESSAGE 2: (REPLY TO MESSAGE 1)
-------------------------------------------------------
It would help if you could post parts of the config file that are
relevant to your problem. Kinda hard to tell what the problem could be
with your config file without having a look at it
- NuTcAsE
------------------------
MESSAGE 3:
------------------------
Sure I could do that, though I think it might not help.... Here's the block I
used in the config file:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="DllFolder" />
</runtime>
You may assume this to be a subfolder in the application base folder (where
the applciation executable is).
Now I suspect the problem is not because of the config file. It seems to me
that the config file is only read when the application is loaded. If later
the application needs to invoke a dll, the app.config file will not be read
again, and therefore, the application will have no way of accessing the dll.
And since all the dlls I'm using are weakly named, I don't think I can use
any other feature of the config files, either application based or machine
based.
As things stand currently, it seems like I have the following two options:
a) To have the user set the environment variables (Path) or do that from my
installer program, an approach I'm not inclined to taking and I'm sure none
of you will encourage it.
b) The second solution would be to dump all the required dlls in the
application folder: This solution would be less elegant and not as memory
efficient, but atleast it would work...
I'm wondering if there is any other way to permanently set the location for
the application to search the dlls in. Do you have any suggestions that might
help?
Thanks