search

NMFCode / NMF

This repository contains the entire code for the .NET Modeling Framework
BSD 3-Clause "New" or "Revised" License
36 stars 15 forks source link

Generated static Retrieve methods need namespace to qualify ClassInstance reference #51

Closed ChrisH07 closed 5 years ago

ChrisH07 commented 5 years ago

The generated static Retrieve...Attribute and Retrieve...Reference currently reference BaseType.ClassInstance which may not be a valid reference. The full namespace for the BaseType is needed to resolve the class.

georghinkel commented 5 years ago

Please confirm that the merged PR solved the problem

ChrisH07 commented 5 years ago

Yes, this problem has been resolved.

ChrisH07 commented 5 years ago

Attached, Models.zip, are 2 metamodels that recreate this issue at SHA 37a4c19d89c8c0e2ce0571cfc676b2a2c78aa326. Code was generated with the following commands: -n ExampleA -f -o ./ModelA ModelA.nmf -n ExampleB -f -o ./ModelB ModelB.nmf

This was included in a class library with the following in AssemblyInfo.cs: [assembly: ModelMetadata("http://exampleA.com/ModelA/", "BlockSketch.MetaModels.ModelA.nmf")] [assembly: ModelMetadata("http://exampleB.com/ModelB/", "BlockSketch.MetaModels.ModelB.nmf")]

This class library was then referenced in a project that creates a model repo. This caused the following exception to occur:

System.Reflection.AmbiguousMatchException HResult=0x8000211D Message=Ambiguous match found. Source=mscorlib StackTrace: at System.RuntimeType.GetInterface(String fullname, Boolean ignoreCase) at System.Type.GetInterface(String name) at NMF.Models.Repository.MetaRepository.RegisterAssembly(Assembly assembly) in C:\Git\NMF\Models\Models\Repository\MetaRepository.cs:line 173

As a side note, I had trouble recreating this issue with a simple metamodel. This issue occurred for me when both classes were called ModelElement, but I couldn't get this to build since the code generator didn't create the GetClass method. This is may not be related, but the name is the same as an NMeta class and some of my metamodels and OMG metamodels have the same names as NMeta classes. Additionally, if the class has no attributes or references then none of the interface methods are generated, but this is an unrealistic edge case.

EDIT: Sorry I posted the wrong example.

ChrisH07 commented 5 years ago

This issue can be reproduced from SHA 37a4c19d89c8c0e2ce0571cfc676b2a2c78aa326 with kdm.txt. This is the OMG KDM metamodel converted to NMF. This metamodel was generated with:

-n OMg -f -o ./OMG/KDM kdm.nmf

This generated the following build errors:

Error CS1061 'Segment' does not contain a definition for 'Segment' and no accessible extension method 'Segment' accepting a first argument of type 'Segment' could be found (are you missing a using directive or an assembly reference?) Error CS1061 'Segment' does not contain a definition for 'Segment' and no accessible extension method 'Segment' accepting a first argument of type 'Segment' could be found (are you missing a using directive or an assembly reference?) Error CS1061 'Segment' does not contain a definition for '_segment' and no accessible extension method '_segment' accepting a first argument of type 'Segment' could be found (are you missing a using directive or an assembly reference?) Error CS1061 'Segment' does not contain a definition for '_segment' and no accessible extension method '_segment' accepting a first argument of type 'Segment' could be found (are you missing a using directive or an assembly reference?) Error CS0120 An object reference is required for the non-static field, method, or property 'KDMEntity.Track' Error CS0120 An object reference is required for the non-static field, method, or property 'KDMEntity.Track'

georghinkel commented 5 years ago

Ah, I recall that I have seen this error before. It is actually not that the problem that the type reference does not take part in the name conflict resolution system, it is rather that in C#, members take precedence over a type name. Therefore, the comiler resolve the name as a member whereas it is thought of being a type.

I put a comment why the fully qualified type name is needed. Further, I included the KDM metamodel (the original Ecore version) as a unit/integration test, so that should never fail again for a published package.