about the probing tag and assembly location

[Shiraz]

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.DllNotFo undError 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.DllNotFo undError.

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!

[NuTcAsE]

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

[Shiraz]

Sure I could do that, though I think it might not help.... Here's the block I
used in the config file:

<runtime>
<assemblyBindin g xmlns="urn:sche mas-microsoft-com:asm.v1">
<probing privatePath="Dl lFolder" />
</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...

Do you have any suggestions that might help?

Thanks
"NuTcAsE" wrote:

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