Adding External Reference for Resolver throws exception

SyntaxEditor for Windows Forms Forum

Posted 9 years ago by Steven Nielson - Software Developer Lead, Microfocus
Version: 4.0.0283
Avatar
I am attempting to add Microsoft.VisualBasic as an External Reference to the .Net Project Resolver using the AddExternalReferenceFromSystemAssembly method with "Microsoft.VisualBasic" as the parameter. When this method executes, the following line excepts:

loader = (ProjectContentLoader)loaderDomain.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(ProjectContentLoader).FullName);

with the following excetion:

An unhandled exception of type 'System.MethodAccessException' occurred in ActiproSoftware.SyntaxEditor.Addons.DotNet.Net20.dll

Additional information: ProjectContentLoader..ctor()


The loaderDomain variable's members all read

"System.Runtime.Remoting.RemotingException: Remoting cannot find field '_activationContext' on type 'System.AppDomain'.
at System.Object.GetFieldInfo(String typeName, String fieldName)
at System.Object.FieldGetter(String typeName, String fieldName, Object& val)
at System.Object.FieldGetter(String typeName, String fieldName, Object& val)
at System.RuntimeFieldHandle.GetValue(Object instance, RuntimeTypeHandle fieldType, RuntimeTypeHandle declaringType, Boolean& domainInitialized)
at System.Reflection.RtFieldInfo.InternalGetValue(Object obj, Boolean doVisibilityCheck, Boolean doCheckConsistency)
at System.Reflection.RtFieldInfo.GetValue(Object obj)
at Microsoft.Office.Tools.Debugger.Tools.TryCreateDebuggerItem(MemberInfo member, Object target, __Item& item)"

for each member. I am able to successfully add System.* entries. The method fails without exception correctly for an assembly that should be pathed. Any suggestions?

Comments (5)

Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Steven,

When we browse to the Microsoft.VisualBasic.dll in our .NET Reflection QuickStart and add a reference to it via the Add Reference button, it loads up ok. Try accessing it via its specific path instead. AddExternalReferenceFromSystemAssembly has a path list it looks for System assemblies in but Microsoft probably installs the VB assembly in another location.


Actipro Software Support

Posted 9 years ago by Steven Nielson - Software Developer Lead, Microfocus
Avatar
I have attempted this with the full specified path with the same results. The code is finding the file. It is more an issue of the creation of the loader class. The following line of code fails to return a valid object:

// Try and load an assembly in a separate app domain
AppDomain loaderDomain = AppDomain.CreateDomain("SyntaxEditorReflectionLoader",
new Evidence(AppDomain.CurrentDomain.Evidence), setup);
Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Steven,

Can you duplicate it in a simple sample project and email it over so we can try it here? Please don't include any .exe files in the ZIP.


Actipro Software Support

Posted 9 years ago by Steven Nielson - Software Developer Lead, Microfocus
Avatar
I am having difficulty getting an example that is small enough to work on but still illustrates the issue for you. I have figured out exactly what the issue is though. It is similar to an issue that was resolved in your product in 2008 (http://www.actiprosoftware.com/Support/Forums/ViewForumTopic.aspx?ForumTopicID=3153). However the fix for that one probably created the issue for me. I have a MFC application that is calling into a .NET dll which in turn calls into your library. The problem is that the Default AppDomain gets created with an empty evidence because it is instantiated via COM Interop. If it were null that would be fine because that would make us fully trusted domain by default. If it actually had some evidence, that would probably be fine as well as we would be partially trusted. The empty evidence from our Default AppDomain is passed on to your CreateDomain call within AssemblyCodeRepository::Add found in AssemblyCodeRepository.cs. The call to CreateDomain with this evidence succeeds, but then triggers the security exception when newly created domain is used to instantiate ProjectContentLoader a few lines later. I modified the source code to check for the empty evidence condition and pass in null instead of the empty evidence and this solved the issue. I think of this as a workaround, not a final fix because I would not want to have to modify the source each time I get an update.

What are your thoughts?

Here is a link (http://connect.microsoft.com/VisualStudio/feedback/details/107671/nunit-fails-due-devenv-exe-app-domain-settings) that describes the problem from a generic point of view.

I have put a before and after of my changes for your inspection below:

BEFORE
AppDomain loaderDomain = AppDomain.CreateDomain("SyntaxEditorReflectionLoader", new Evidence(AppDomain.CurrentDomain.Evidence), setup);


AFTER
Evidence ev = null;
if (AppDomain.CurrentDomain.Evidence != null && 0 != AppDomain.CurrentDomain.Evidence.Count)
{
ev = new Evidence(AppDomain.CurrentDomain.Evidence);
}

AppDomain loaderDomain = AppDomain.CreateDomain("SyntaxEditorReflectionLoader", ev, setup);
Posted 9 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
This seems like a good fix for the problem. We'll add it to the next release.


Actipro Software Support

The latest build of this product (v2018.1 build 0341) was released 7 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.