DLL woes

This all seems like it's pointing me in the right direction, yet I can't quite put my fingers around it.

I have a VC++ project, and in one of the .cpp files I have

"using namespace MyNamespace"

MyNamespace is defined in a VC# DLL.

Now, I want to run the vc++ project without having to have the MyNamespace.dll located in the application directory of the project.

I don't know much about CLR and all of that, but why is it that all of the DLL reference issues aren't automatically resolved at runtime.


Regarding the link you posted about the app.config file, it seems like it would only be useful if I actually knew what directory the dll could be located in, hence I'd specify the assembly directory, or what have you. My issue is, I don't know where the MyNamespace DLL will be located at runtime. It could be anywhere. I'd like for the CLR to search the directories listed in the PATH env variable in hopes of resolving the reference issue.

ok http://en.csharp-online.net/.NET_CLR_Components%E2%80%94Resolving_Names_to_Locations explains more about how the process works (go towards the end, the searching).


This is however not what you want. You want it to use PATH, in order to do this you will need to write a little bit of custom code to do the search in the assemblyresolve event (I gave you a link above). It should only be about 7 lines of code to do the search as you want it.

Cheers,

Greg

I'm confused as to where the assembly resolve stuff should be. Do I put this in my C++ project (i.e. the project trying to reference the DLL that can't be found ), or in the code for the DLL that can't be found.

well it wouldn't make much sense to put the code to find the DLL in the DLL that can't be found would it?

that's what I was thinking as well :-P

Thought I'd better be safe and ask rather than jumping right in.

basically hook that event on your appdomain (created by the CLR for your code to run in). then in that event grab the PATH environment variable and do the search yourself. Should only be a few lines of code. You can then return the assembly to the CLR.

Cheers,

Greg

ok so here's my deal:

I thought I would try and hardcode the path to the MyNamespace.dll the first time around, just so I could see that it's working.


Am I doing this correctly?

///header.h
#define ABSOLUTE_DLL_PATH "C:\\MyNamespace.dll"
 
extern "C"
{
     int _declspec(dllexport) DoSomething(char* param);
     static Assembly^ MyAssemblyResolver( Object^ sender, ResolveEventArgs^ e );
}
 
//header.cpp
#import "header.h"
 
int DoSomething( char* param )
{
      AppDomain::CurrentDomain->AssemblyResolve+= gcnew ResolveEventHandler(MyAssemblyResolver);
      
       //do other stuff here
}
 
static Assembly^ MyAssemblyResolver( Object^ sender, ResolveEventArgs^ e )
{
      return Assembly::LoadFrom( ABSOLUTE_DLL_PATH );
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:

looks reasonable.

Unfortunately, this is not working.

Here are some interesting observations though:

I have the following three things:
1. An exe test project which calls C++ DLL
2. The C++ DLL which calls a C# DLL
3. The C# DLL

If I place all 3 files in the same directory, everything works.
If I place the exe and the C# DLL in the same directory and the C++ DLL somewhere in my PATH, it works.

If the C# DLL is not in the same directory as the exe, it never works. FileNotFoundException trying to find the C# DLL.

Another thing which is probably of importance:

1. The exe references the managed C++ DLL using PInvoke.
2. The  C++ DLL references the C# DLL only by "using namespace MyNamespace";

Are you calling your DoSomething() method before attempting to access anything out of the Managed DLL? eg when are you tying the event to assembly load?

I think what you're asking is, is DoSomething() the first method from that DLL that I call, this way to ensure that the assembly resolver is called?

The answer is yes.

If that's not what you're asking, then please clarify.

Is your resolver being called?

If not the problem is in your setting up of the event.

This may be unrelated but according to this article http://msdn.microsoft.com/en-us/library/ms682586.aspx, "The directories that are listed in the PATH environment variable" are searched.

Can you shed some light on this?

That is windows searching for unmanaged dlls ... the rules are different for the CLR searching for managed assemblies.

Ok so that makes sense why the C++ DLL is loaded if it's located in one of the PATH directories ( as I mentioned a few posts ago ). Apparently I was wrong in saying it was a "managed C++ DLL". The fact that it has "extern C" in my function definitions makes it unmanaged I'm assuming?

Its likely a mixed mode DLL. But your extern C is referencing it as an unmanaged dll.

Cheers,

Greg

Ok, I have some sort of good news.

Recall how things are getting called : Test Project Loads -> c++ DLL -> C# DLL
Previously, I put the resolver stuff in the C++ DLL, but it never get's called. The CLR tries to load the C# DLL before the resolve event handler is ever added.

If I put the resolver into the Test project, then everything WORKS!

Unfortunately, I need the resolver to be in the C++ dll, so now I need to figure out why the CLR is trying to load the DLL before I've even called any functions in the dll.

Any suggestions?

Also note that it appears as though the C# DLL is being loaded as soon as the C++ DLL is being loaded, hence making it seem impossible to add an assembly resolver event in the C++ DLL.

I'm at  a dead end and dont know how to proceed :-\

I found a solution, although I'm sure it's not the best.

I added the C# DLL to the GAC.

Yes that will work (its in the probing area then). Can you post code for your usage of the dll? I assure you this can be done.

Cheers,

Greg

Here ya go, and here's how I reproduce the exception:

Clean & Build Test Project "DLL_Test".
Take CPP_DLL.dll and place it any directory specified in my PATH.
Take CSharp_DLL.dll and place it in C:\.
Run DLL_Test.exe.
Click "Do Something" button to produce exception:

Could not load file or assembly 'CSharp_DLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

///////////////////////////////////////////////////////////////
////The Test project class that is calling the C++ DLL/////////
///////////////////////////////////////////////////////////////
 public partial class Form1 : Form
    {
        [DllImport(@"CPP_DLL.dll")]
        public static extern void DoSomething(string withSomething);
 
        public Form1()
        {
            InitializeComponent();
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            System.Console.WriteLine("Trying to do something.");
            DoSomething("Test test test");
        }
    }
 
 
//////////////////////////////////////////////////////////////
////////////////////The CPP DLL///////////////////////////////
//////////////////////////////////////////////////////////////
// CPP_DLL.h
 
#pragma once
 
using namespace System;
using namespace System::Reflection;
 
extern "C"
{
	void _declspec( dllexport ) DoSomething( char* withSomething );
        static Assembly^ AssemblyResolver( Object^ obj, ResolveEventArgs^ e );
}
 
// CPP_DLL main file
 
#include "stdafx.h"
 
#include "CPP_DLL.h"
 
void DoSomething( char* withSomething )
{
	String^ s = gcnew String( withSomething);
	CSharp_DLL::Class1^ test = gcnew CSharp_DLL::Class1( s );
	delete s;
}
 
static Assembly^ AssemblyResolver( Object^ obj, ResolveEventArgs^ e )
{
	Console::WriteLine("Resolving assembly...");
	return Assembly::LoadFrom("C:\\CSharp_DLL.dll");
}
 
//////////////////////////////////////////////////////////////////
/////////////////////// The CSharp DLL ///////////////////////////
//////////////////////////////////////////////////////////////////
namespace CSharp_DLL
{
    public class Class1
    {
        public Class1( String something )
        {
            System.Console.WriteLine("Class1 initialized with something: {0}", something);
        }
    }
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:

The problem is your DoSomething() method ...

when it gets called the JIT compiler has to compile it before it can be run ...

In it you use a type out of the assembly that you want to load CSharp_DLL::Class1^ test = gcnew CSharp_DLL::Class1( s );
 so it tries to load that assembly.

Take that out of doSomething ... call Dosomething() first then call that other method after.


Cheers,

Greg

That works!

Now just one last question:

Say I have method DoSomething1() and DoSomething2(), both declared as extern C in the of my CPP dll.

Instead of calling the CSharp_DLL::Classwhatever directly inside those methods, I'm adding the assembly resolver event handler, then calling an internal method that then references the CSharp_DLL.

Does it hurt to add a new assembly event resolver each time I call the method? What's the easiest way to check if the handler has already been added?

See code for example:

int DoSomething1( )
{
     	AppDomain::CurrentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver );
        //call internal dosomething
        _DoSomething();
}
 
int DoSomething2()
{
        AppDomain::CurrentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver );
        //call internal dosomething2
        _DoSomething2();
}
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

I would just use a static boolean flag ...

when I tie it I would mark the boolean to be true. then check if the boolean is set.

Also you don't *have* to make it two methods (that was just to show you what the problem was). You could also do it other ways (like having it do that then call a different function that had your other code in it, JIT compiler wouldn`t hit it first so it would work).

The 2 call option I would use would be to have a method Initialize() and then methods to actually do things ...

Cheers,

Greg

What could be the most likely cause of why my assembly resolver is not getting called when I build the Release version? It works when I build for Debug.

possibly an optimization with the JIT or something?

Do you know how to use a static constructor? Put it on your object in your C++ DLL and it will be called before any method to that type.

Cheers,

Greg

The C++ references all extern "C" functions, so there is no such thing as an object, correct? Hence, no constructor. I don't want to have to do anything else from the Test_DLL in order to initialize the C++ DLL. I just want to have to call DoSomething(), not Initalize() then DoSOmething().

Its all about where the reference gets used in relation to where you add the event handler (the JIT seeing the reference forces the other DLL to be loaded, you must tie the event handler before this happens). You can put a static type in your assembly (the key with the static type is that it controls it only being done once for you). You can also do this very easily by doing something like pseudocode

void Dosomething() {
    //remove event
    AppDomain::CurrentDomain->AssemblyResolve-= gcnew ResolveEventHandler(MyAssemblyResolver);
    //add event
    AppDomain::CurrentDomain->AssemblyResolve+= gcnew ResolveEventHandler(MyAssemblyResolver);

    ActuallyDoSomething();
}

to avoid adding too many (assuming you are not worried about threading ... you would just remove the event/add the event on every call ... The keeping of the other code in another method may or may not get the JIT to handle this properly (it depends on the complexity of the other method and whether or not the JIT attempts to do things like inlining it).

You could also do this kind of thing when your DLL is loaded (I forget the unmanaged method for this but its *NOT* dllmain).

It seems to be something related to optimization, as you mentioned.

This works in debug, but not in release. However, if I uncheck the "Optimize Code" in my release build, I still get the same problem.

it has nothing to do with that .... It is the JIT compiler (Just in time) that turns the IL into machine code at runtime.

I see, so it seems like I'm out of options? Once again, I'm unsure how to proceed.

You need to figure out why it is doing it or use one of the other options I gave you. I would personally recommend continuing to the simplest *first* to prove everything works which is adding an initialization method. I would then research what the hook is to add initialization code safely to your DLL (I know there is a method I just forget what it is, maybe this is actually allowable for DLLMAIN I forget the exact state of the CLR at the time dllmain is called so you would have to do a little research on it.

Ok, so calling an initialize method before I call the DoSomething does work, but it's not what I need.
I don't want to have to export another function from the C++ DLL that MUST be called before any other function can.

I'll look into the DLLMain route.

I put a DLLMain inside my C++ DLL and tried adding the resolve hander in there. This is the result:

\CPP_DLL.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

I'm getting some stupid compiler error even though , but I cannot figure it out :-\

I did include System::Runtime::CompilerServices.

Here's the error :C2144: syntax error : 'System::Runtime::CompilerServices::MethodImplOptions' should be preceded by ')'

void DoSomething( char* withSomething )
{
	AppDomain::CurrentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver );
	_DoSomething( withSomething);
}
[MethodImplAttribute(MethodImplOptions.NoInlining)]
void _DoSomething( char* withSomething )
{
	CSharp_DLL::Class1^ cl = gcnew CSharp_DLL::Class1( withSomething );
}
static Assembly^ AssemblyResolver( Object^ obj, ResolveEventArgs^ e )
{
	Console::WriteLine("Resolving assembly...");
	return Assembly::LoadFrom("C:\\CSharp_DLL.dll");
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

I think I got it figured out, along the same lines as what you said:

In my CPP.h, I declared the _DoSomething as follows:

void _declspec (noinline) _DoSomething( char* withSomething );

                                              

1: