Import from assembly does not work (when it depends on other dll?)
Baltasarq opened this issue · 6 comments
I'm using Manjaro Linux with mono 6.10.
I have a project which consists of a main main.exe assembly and an util.dll one. When I import the assembly util.dll, it works okay, buy when importing the main.exe assembly, it crashes with the following (misleading?) stacktrace:
System.IO.FileNotFoundException: Resource 'down.bmp' was not found.
at System.Drawing.Bitmap..ctor (System.Type type, System.String resource) [0x0004d] in <3ca78e922b044185b653d000a8e4d973>:0
at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap..ctor(System.Type,string)
at NClass.GUI.Dialogs.DetailsErrorDialog..ctor (System.Windows.Forms.MessageBoxIcon icon) [0x00006] in <89877bea8cb14088bcbdc573d7a3a51e>:0
at (wrapper remoting-invoke-with-check) NClass.GUI.Dialogs.DetailsErrorDialog..ctor(System.Windows.Forms.MessageBoxIcon)
at NClass.GUI.Dialogs.DetailsErrorDialog.Show (System.String title, System.String message, System.String details, System.Windows.Forms.MessageBoxIcon icon, System.Boolean isCenteredOnParent) [0x00008] in <89877bea8cb14088bcbdc573d7a3a51e>:0
at NClass.AssemblyImport.NETImportPlugin.ImportAssembly (System.String fileName, NClass.DiagramEditor.ClassDiagram.ClassDiagram diagram, NClass.AssemblyImport.ImportSettings settings) [0x000a1] in <d3102a97ae5646e48164f70ae825aadc>:0
at NClass.AssemblyImport.NETImportPlugin.Launch () [0x0005e] in <d3102a97ae5646e48164f70ae825aadc>:0
at NClass.AssemblyImport.NETImportPlugin.menuItem_Click (System.Object sender, System.EventArgs e) [0x00000] in <d3102a97ae5646e48164f70ae825aadc>:0
at System.Windows.Forms.ToolStripItem.OnClick (System.EventArgs e) [0x00019] in <313abb6e08e943459ea3b455bc2f9adb>:0
at System.Windows.Forms.ToolStripMenuItem.OnClick (System.EventArgs e) [0x00090] in <313abb6e08e943459ea3b455bc2f9adb>:0
...
Yes, I've added this DetailsErrorDialog, so that I can troubleshoot things better, when stuff goes south and I was relying on a resource that is apparently in an assembly present only in Windows.
The good news is - the error dialog should be fixed now. The bad news - there is indeed some problems with the import of your assembly.
I've noticed that there are some problems in general with the assembly import, but hadn't gotten to it yet.
It would be very kind of you, if you upload the 'real' stack trace, when you get to use 2.8.1
Certainly! Glad to help.
No stack trace this time, though. The app no longer crashes (this is good news), though a new error dialog pops up (I suppose the one that did not work last time) and shows some confusing information:
Error while importing!
Note: Assemblies created with a fuscator may fail to import.
NClass.Core.BadSyntaxException: It is not allowed to use the override modifier with the virtual one.
at NClass.CSharp.CSharpLanguage.ValidateOperationModifiers (NClass.Core.Operation operation) [0x000de] in <916a16957e634fbf87287d7ed34393bf>:0
at NClass.CSharp.CSharpLanguage.ValidateOperation (NClass.Core.Operation operation) [0x00006] in <916a16957e634fbf87287d7ed34393bf>:0
at NClass.Core.Operation.set_IsOverride (System.Boolean value) [0x0004f] in <032305033f6e4ec9867de29b196ac5ff>:0
at NClass.CSharp.CSharpProperty.InitFromDeclaration (NClass.CSharp.ICSharpPropertyDeclaration declaration) [0x0010b] in <916a16957e634fbf87287d7ed34393bf>:0
at NClass.CSharp.CSharpProperty.InitFromDeclaration (NClass.Core.IPropertyDeclaration declaration) [0x0000a] in <916a16957e634fbf87287d7ed34393bf>:0
at NClass.AssemblyImport.NETImport.AddProperties (NClass.Core.CompositeType type, System.Collections.Generic.IEnumerable`1[T] properties) [0x0001c] in <9e815396c68f4af9ac871c34ddba1cba>:0
at NClass.AssemblyImport.NETImport.AddClasses (System.Collections.Generic.IEnumerable`1[T] classes) [0x00062] in <9e815396c68f4af9ac871c34ddba1cba>:0
at NClass.AssemblyImport.NETImport.ImportAssembly (System.String fileName, System.Boolean useNewAppDomain) [0x00099] in <9e815396c68f4af9ac871c34ddba1cba>:0
at NClass.AssemblyImport.NETImportPlugin.ImportAssembly (System.String fileName, NClass.DiagramEditor.ClassDiagram.ClassDiagram diagram, NClass.AssemblyImport.ImportSettings settings) [0x00025] in <9e815396c68f4af9ac871c34ddba1cba>:0
I say this is confusing since it would be actually strange to have a virtual override member (?). I felt prompted to disassemble it and find the culprit:
$ monodis Colorado.exe | grep virtual
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig newslot
.method public virtual hidebysig newslot
.method public virtual hidebysig newslot
.method public virtual hidebysig newslot abstract
.method public virtual hidebysig newslot abstract specialname
.method public final virtual hidebysig newslot
.method public virtual hidebysig
.method public virtual hidebysig
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method family virtual hidebysig newslot abstract
.method public virtual hidebysig
.method public virtual hidebysig newslot abstract
.method public virtual hidebysig newslot abstract specialname
.method public virtual hidebysig newslot abstract specialname
.method public virtual hidebysig newslot abstract specialname
.method public virtual hidebysig newslot abstract specialname
.method public virtual hidebysig newslot abstract
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method public virtual hidebysig
.method public virtual hidebysig specialname
.method public virtual hidebysig specialname
.method family virtual hidebysig
.method family virtual hidebysig
$ monodis Colorado.exe | grep override
$
The project is Colorado, in case you want to experiment with the assemblies yourself.
If I grep the source code, then the situation is the inverse one: I have a lot of overrides but not a single virtual (I have abstracts instead). I suppose this is due to the particularities of assemblies, anyway.
Bottom line, I did not find anything in my project that justifies this error.
Another issue is: why err in that case? I mean, it is unusual and strange, but what about showing just a warning and go with, say, virtual?
Yep, the one that you posted (containing the BadSyntaxException) is the stack trace, I meant :)
There is nothing wrong with your assembly, there are some bugs in the assembly importer, which - it appears - I've inherited with the original project.
To answer your last question: I haven't took a deep look yet, but I'm quite certain following happens: there is a piece of code (NClass.CSharp.CSharpLanguage) that generally validates the state of your classes. It is used to validate entities (classes, interfaces, etc), which can come from the diagram editor or from the assembly importer. And this code is fed garbage by the latter, this is why it flips out.
So basically I need to take a look why the hell some props are recognized simultaneously as virtual and override.
I would suggest that you try this nightly build: https://baychev.visualstudio.com/NClass/_build/results?buildId=110&view=artifacts&type=publishedArtifacts
9ec02b2 should fix this.
@Baltasarq so, did you try the build I've mentioned above?
Oh dear, my bad...
I thought that I already had commented on it..
.
Yep, it works perfectly now, thank you!