Holding ref to managed dll from native dll

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I can't seem to find one spot on the net that specifies exactly what I need
to do. Situation:
Native dll needs to hold a static reference to a managed class in .net 2.0
(whidbey) which needs to hold a static reference to managed classes.

1. In 2003 I needed special initialization because of the loader lock issue.
In 2005 it seems I dont need this, however I am calling into a managed dll
from a native dll, and I read somewhere there can still be an issue? Is this
true?

2. I need to keep some managed objects loaded into memory. Since the native
dll loads the managed dll, the native dll needs to hold a static rf. I will
need some sort of mixed dll, so the native dll can hold a reference to the
mixed mode dll, which can internaly load the required .net objects and keep
them in memory. However managed c++ libraries cannot maintain a static
reference to a managed object. I read I can put this static reference inside
a managed class. What do I need to do so I can load this managed class in
native code (what kind of wrapper or magic needs to be done?)

Thanks!
 
Hi Adam,
1. In 2003 I needed special initialization because of the loader
lock issue. In 2005 it seems I dont need this, however I am
calling into a managed dll from a native dll, and I read somewhere
there can still be an issue? Is this true?
Click to expand...
2. ... However managed c++ libraries cannot maintain a static
reference to a managed object. I read I can put this static reference
inside a managed class.
Click to expand...

Would you please give a hint on what's the concern you mentioned above,
which the documentation you read about the problem of calling into a
managed assembly from a native dll with VC2005?

By the way, for the issues about the C++/CLI, I suggest you can post such
problem in our MSDN forum

Visual C++ Language
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=96


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Gary,
I am referring to the loader lock issue using managed objects in DllMain.
There is various documentation around on this as Im sure you are aware, but
the specific article I'd have to do some searching to find. Using a GCHandle
in dllmain to initialize a managed object can cause this issue, even in
whidbey. A member of the VC team wrote me back on the list you recommended
confirming it is an issue. I've now properly initialized the object outside
of dllmain, but freeing it up is now a problem as referenced in my posting
from today titled "freeing static managed objects from native dll - cant use
dllmain"
Thanks,
Adam


"Gary Chang[MSFT]" said:
Hi Adam,
1. In 2003 I needed special initialization because of the loader
lock issue. In 2005 it seems I dont need this, however I am
calling into a managed dll from a native dll, and I read somewhere
there can still be an issue? Is this true?
Click to expand...
2. ... However managed c++ libraries cannot maintain a static
reference to a managed object. I read I can put this static reference
inside a managed class.
Click to expand...

Would you please give a hint on what's the concern you mentioned above,
which the documentation you read about the problem of calling into a
managed assembly from a native dll with VC2005?

By the way, for the issues about the C++/CLI, I suggest you can post such
problem in our MSDN forum

Visual C++ Language
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=96


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Back
Top