Hello Monty,
Regarding on the problem you mentioned, based on my experience, it is
possibly caused by the following things:
** assembly loading, since when the .net assembly is not put in GAC, the
application CLR will try loading it from private assembly directory. For
your scenario, you call the .net through COM interop, then you need to make
sure the .net assembly is at your COM client app's private assembly folder.
You can use the "AppDomain.CurrentDomain.BaseDirectory" in your .net
component's code to get the current CLR appdomain's base directory(where
the runtime will try locating private dependency assemblies).
The following tool is useful for troubleshooting assembly loading and
binding issue:
#Assembly Binding Log Viewer (Fuslogvw.exe)
http://msdn2.microsoft.com/en-us/library/e74a18c4.aspx **As John mentioned, since the problem differs when the assembly is
installed in GAC or not, it does be possible that there is some CAS
security related issue since the component in GAC is always evaluaetd as
FullTrust. For CAS test, you can use the "caspol.exe" tool to temporarily
turn off CAS and test with both scenarios(wrapper assembly in GAC or not )
to see whether it works.
#Code Access Security Policy Tool (Caspol.exe)
http://msdn2.microsoft.com/en-us/library/cb6t8dtz.aspx In addition, all the above suggestion just based on some common scenarios.
We still can not make sure the exact problem in your wrapper component and
application. If possible, I would suggest you use some debugger to manually
attach to your application's process and locate the exact point the
exception get thrown. Visual Studio will be the preferred one if you've it
installed on the box.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
