Is it possible (GAC)

[MC-Advantica]

Is it possible to place a strongly named assembly (C++ based) which
references legacy (i.e., native) DLLs in the GAC? I seem to be having
difficulty when trying to load the assembly into a client app. I wondered
how the assembly found the legacy DLL dependencies; is there some kind of
search path?

[Bruno van Dooren [MVP VC++]]

Is it possible to place a strongly named assembly (C++ based) which

references legacy (i.e., native) DLLs in the GAC? I seem to be having
difficulty when trying to load the assembly into a client app. I wondered
how the assembly found the legacy DLL dependencies; is there some kind of
search path?

You need to place the dlls someplace where the system will find them.
The easiest solution is to place them in a folder in program files, and then
add the path to the PATH variable.

I think the problem is that your unmanaged dlls are not placed alongside
your assembly in the GAC.
In that case, the assembly will not find them automatically.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[MC-Advantica]

What do you mean by "your unmanaged dlls are not placed alongside your
assembly in the GAC"; is this different than your suggested solution of make
sure DLLs are in PATH variable referenced directory? Am I correct that I
cannot place unmanaged DLLs in GAC?

Is the idea of a GAC based managed assembly referencing unmanaged DLLs a
problem in general, or do I just need to get the configuration correct?

Thanks for your help

"Bruno van Dooren [MVP VC++]" wrote:

Is it possible to place a strongly named assembly (C++ based) which
references legacy (i.e., native) DLLs in the GAC? I seem to be having
difficulty when trying to load the assembly into a client app. I wondered
how the assembly found the legacy DLL dependencies; is there some kind of
search path?

You need to place the dlls someplace where the system will find them.
The easiest solution is to place them in a folder in program files, and then
add the path to the PATH variable.

I think the problem is that your unmanaged dlls are not placed alongside
your assembly in the GAC.
In that case, the assembly will not find them automatically.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[MC-Advantica]

What do you mean by "your unmanaged dlls are not placed alongside your
assembly in the GAC"; is this different than your suggested solution to place
unmanaged DLLs in PATH variable referenced directories? Am I correct that
you cannot place unmanaged DLLs in GAC?

Also on the conceptual side; is there a problem with placing a mixed
assembly in the GAC since it references unmanaged DLLs?

"Bruno van Dooren [MVP VC++]" wrote:

Is it possible to place a strongly named assembly (C++ based) which
references legacy (i.e., native) DLLs in the GAC? I seem to be having
difficulty when trying to load the assembly into a client app. I wondered
how the assembly found the legacy DLL dependencies; is there some kind of
search path?

You need to place the dlls someplace where the system will find them.
The easiest solution is to place them in a folder in program files, and then
add the path to the PATH variable.

I think the problem is that your unmanaged dlls are not placed alongside
your assembly in the GAC.
In that case, the assembly will not find them automatically.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Bruno van Dooren [MVP VC++]]

What do you mean by "your unmanaged dlls are not placed alongside your

assembly in the GAC"; is this different than your suggested solution of
make
sure DLLs are in PATH variable referenced directory? Am I correct that I
cannot place unmanaged DLLs in GAC?

Is the idea of a GAC based managed assembly referencing unmanaged DLLs a
problem in general, or do I just need to get the configuration correct?

If I recall correctly, If an assembly is installed in the GAC, it is
physically copied to a special location in the Windows directory.
If it relies on any native DLLs, those DLLs will no longer be located in the
same folder as the assembly because they are not copied along.
This means that the assembly cannot locate the native DLLs at runtime.

To solve this, the native DLLs have to be placed where the system can find
them.
I.e. the thing to do is to create a folder with those DLLs, and then add
that folder to the PATH variable.

Then, if the assembly tries to load those DLLs, the DLL loader will search
through all path folder and find them.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"

[Ben Voigt]

"MC-Advantica" <MC*********@discussions.microsoft.comwrote in message
news:9C**********************************@microsof t.com...

What do you mean by "your unmanaged dlls are not placed alongside your
assembly in the GAC"; is this different than your suggested solution of
make
sure DLLs are in PATH variable referenced directory? Am I correct that I
cannot place unmanaged DLLs in GAC?

GAC has two parts, a directory holding the DLLs and a metadata database.
Unmanaged DLLs can be in the directory (where the managed DLLs can find
them), but they don't have metadata.

>
Is the idea of a GAC based managed assembly referencing unmanaged DLLs a
problem in general, or do I just need to get the configuration correct?

Thanks for your help

"Bruno van Dooren [MVP VC++]" wrote:

Is it possible to place a strongly named assembly (C++ based) which
references legacy (i.e., native) DLLs in the GAC? I seem to be having
difficulty when trying to load the assembly into a client app. I
wondered
how the assembly found the legacy DLL dependencies; is there some kind
of
search path?

You need to place the dlls someplace where the system will find them.
The easiest solution is to place them in a folder in program files, and
then
add the path to the PATH variable.

I think the problem is that your unmanaged dlls are not placed alongside
your assembly in the GAC.
In that case, the assembly will not find them automatically.

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"