AddAllAssembliesInAppDomainAsExternalReferences

SyntaxEditor .NET Languages Add-on for Windows Forms Forum

Posted 13 years ago by Edward
Version: 4.0.0236
Avatar
Hi,

I am experiencing an issue when I call the DotNetProjectResolver.AddExternalReferenceForSystemAssembly() method, here is the trace of the exception:
System.Reflection.TargetInvocationException: Error invoking delegate in InfoMessageBoxThread ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: The path is not of a legal form.
   at System.IO.Path.nGetFullPathHelper(String path, Char[] invalidPathChars, Char[] whitespaceChars, Char directorySeparator, Char altDirectorySeparator, Char volumeSeparator, Boolean fullCheck, String& newPath)
   at System.IO.Path.FixupPath(String path)
   at System.IO.Path.GetDirectoryName(String path)
   at ao.a(Assembly A_0)
   at ao..ctor(Assembly A_0, String A_1, String A_2, String A_3, Boolean A_4)
   at ActiproSoftware.SyntaxEditor.Addons.DotNet.Dom.b.a(c A_0)
   at ActiproSoftware.SyntaxEditor.Addons.DotNet.Dom.AssemblyCodeRepository.Add(Assembly assembly, String assemblyFullName, DotNetProjectResolver projectResolver)
   at ActiproSoftware.SyntaxEditor.Addons.DotNet.Dom.DotNetProjectResolver.AddExternalReference(Assembly assembly, String assemblyFullName)
   at ActiproSoftware.SyntaxEditor.Addons.DotNet.Dom.DotNetProjectResolver.AddExternalReference(Assembly assembly)
   at ActiproSoftware.SyntaxEditor.Addons.DotNet.Dom.DotNetProjectResolver.AddAllAssembliesInAppDomainAsExternalReferences()
   at ScriptEditor.ScriptEditor..ctor()
   at ScriptUI.ScriptUI.InitializeComponent()
   at ScriptUI.ScriptUI..ctor()
Here is my code. The exception is thrown at this.dotNetProjectResolver.AddAllAssembliesInAppDomainAsExternalReferences(). I have checked if the Cache path is well formed and I found no problem.
InitializeComponent();
            string exePath = System.IO.Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]) ;            
            this.dotNetProjectResolver.CachePath = System.IO.Path.Combine(exePath, @"Cache\");
            this.dotNetProjectResolver.AddAllAssembliesInAppDomainAsExternalReferences();
    
            foreach(string ass in FSLAssemblyReferences)
            {
                this.dotNetProjectResolver.AddExternalReference(System.IO.Path.Combine(exePath, ass)) ;
            }
            this.editor.DocumentSyntaxLanguageLoaded += new ActiproSoftware.SyntaxEditor.SyntaxLanguageEventHandler(editor_DocumentSyntaxLanguageLoaded);
Any chance you could help me to find out if that bug comes from my code or from the addon?

Thanks & regards,

Edward

[Modified at 12/21/2006 06:34 AM]

Comments (11)

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Edward,

I did some looking at our code and the path internally that GetDirectoryName is passed
comes from Assembly.Location. Could you scan the assemblies in your AppDomain and see
if any of the Assembly.Location paths look odd? Also you might try calling Path.GetDirectoryName
on each Assembly.Path and it will probably blow up on the offending path. Then let us know
what is causing it. Thanks!


Actipro Software Support

Posted 13 years ago by Edward
Avatar
Thank you, this enabled me to localize the problem.

I have scaned the assemblies like this:
System.Reflection.Assembly[] assemblies = System.AppDomain.CurrentDomain.GetAssemblies() ;
            using(System.IO.StreamWriter writer = System.IO.File.CreateText("c:\\test.txt"))
            {
                foreach(System.Reflection.Assembly assembly in assemblies)
                {
                    writer.WriteLine(assembly.Location != string.Empty ? assembly.Location : assembly.FullName) ;
                }
            }
And here is what I get in the text file:
c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll
c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll
c:\windows\assembly\gac\system.data\1.0.5000.0__b77a5c561934e089\system.data.dll
c:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll
c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll
c:\windows\assembly\gac\system.runtime.remoting\1.0.5000.0__b77a5c561934e089\system.runtime.remoting.dll
c:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll
c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.drawing.dll
c:\windows\assembly\gac\accessibility\1.0.5000.0__b03f5f7f11d50a3a\accessibility.dll
<b>uaetaoah, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null</b>
c:\windows\assembly\gac\system.design\1.0.5000.0__b03f5f7f11d50a3a\system.design.dll
c:\program files\X\tools\bin\scripteditor.dll
c:\program files\X\tools\bin\actiprosoftware.syntaxeditor.addons.dotnet.net11.dll
c:\program files\X\tools\bin\actiprosoftware.shared.net11.dll
c:\program files\X\tools\bin\actiprosoftware.syntaxeditor.net11.dll
c:\program files\X\tools\bin\actiprosoftware.winuicore.net11.dll
As you thought I have a assembly location that looks odd. I think this is caused by .Net remoting which must create temporary assemblies for the serialization (the name uaetaoah changes every time).

Now I know how to work arround this, and I am going to call the AddExternalReference() method on each assembly instead (after checking Assembly.Location).


Thank you very much for your support!

Edward

[Modified at 12/21/2006 10:31 AM]
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Edward,

I'm glad that solved it. I've added a try...catch around that code for the future so
that it will not blow up.


Actipro Software Support

Posted 13 years ago by Edward
Avatar
Well, I think a test like this
Assembly.Location == string.Empty
would be enough in my situation.

Thank you a lot,

Edward
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Yes that check has been added as well. Thanks!


Actipro Software Support

Posted 13 years ago by Leif Zars
Avatar
i am on version 4.0.244.0 and this doesn't seem to be fixed. has it?
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Everything mentioned above has been added already. If you are experiencing a problem, then please e-mail us and we can work with you to sort out what is happening.


Actipro Software Support

Posted 13 years ago by Igor Velikorossov - Sydney, Australia
Avatar
I'm using ActiproSoftware.SyntaxEditor.Addons.DotNet.Net20 v4.0.246.0 and the problem is still there.
Strangely enough the offending dll (w/o proper Location is being added to the list of ExternalReferences but no assemblies after it can be added, and DotNetProjectResolver throws a fit with the "The path is not of a legal form"

Instead of calling .AddAllAssembliesInAppDomainAsExternalReferences() I was forced to iterate through the external refs, check their Locations and and add them to the list...

<whine>
I find it rather inconvinient that DotNetProjectResolver.ExternalReferences is of ICollection type instead of string[] or something implementing IList...
</whine>
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Hi Igor,

If you are seeing an issue and can isolate down which assembly is causing it, please email it over to us. Alternatively, email us a small project that reproduces the problem so we can debug it.

As for the ExternalReferences, we unfortunately can't make it a list because there are other things that happen when you call AddExternalReference. Namely, we load the assembly and reflection information. Perhaps in the future we could modify the object model so that the add/remove reference methods were Add/Remove methods off of a custom ExternalReferenceCollection instead.


Actipro Software Support

Posted 13 years ago by Igor Velikorossov - Sydney, Australia
Avatar
The problem is similar to the one described above - one of the assemblies in the domain seems to be dynamically generated (it contains xml serialisation/deserialisation stuff, and I think it actually resides in the memory not on disk).

I haven't experienced problems in test-bed projects, and the one causing troubles is a big complicated multiprojects solution, where the editor control is just a tiny part of it.

I'm puzzled tho why adding that assembly prevents from adding any of the following assemblies. Looking at the code it may have something to do with AssemblyCodeRepository.Add() call in AddExternalReference().

Perhaps the following may rectify the problem, tho I am not 100% sure it will completely eliminate it.

        public void AddAllAssembliesInAppDomainAsExternalReferences()
        {
            foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
            {
                try
                {
                    if (!string.IsNullOrEmpty(assembly.Location))
                        this.AddExternalReference(assembly);
                }
                catch (Exception ex)
                {
                }
            }
        }
Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
If you can somehow create a small sample project that shows the exception and email it over, we can debug it and figure out what is going on.

I've altered the AddAllAssembliesInAppDomainAsExternalReferences code so that if an exception occurs, it will continue on and then rethrow the exception at the end. This will be in the next maintenance release.


Actipro Software Support

The latest build of this product (v2020.1 build 0400) was released 24 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.