Type alias "DocTypeName" has a more than one parent class.

[tompipe]

When implementing interfaces, the interfaces have to reside in the same directory as the doctype classes, or the custom tool throws an error:

ZbuModelsBuilder: ZbuModelsBuilder failed to generate code: 
Exception: Response status code does not indicate success (InternalServerError)
{
    "Message":"An error has occurred.",
    "ExceptionMessage":"Type alias "DocTypeName" has a more than one parent class."
}

With an inner exception of:

error CS0246: 
The type or namespace name 'IInterfaceName' could not be found 
(are you missing a using directive or an assembly reference?)

If it can’t find the file to parse, it presumes that the interface is actually a class, and flags the implementing class as having multiple parent classes.

http://blog.tompipe.co.uk/post/Adventures-with-Umbraco-and-ZbuModelsBuilder.aspx

[zpqrtbnk]

Not sure it needs to be in the same directory, but it needs to be "found" ie there should be a "using" statement telling the compiler how to find the class. See this documentation page - what you're looking for is, I think, at the bottom of the page. The ModelsUsingAttribute should let you declare that models files need to have one or more "using" statements so your interface can be found. Making sense?

[zpqrtbnk]

Oops, should have read your blogpost first, notice you did try ModelsUsing and it did not work - so might be a bug - looking into it.

[zpqrtbnk]

Probable bug in CodeParser & Compiler. The Roslyn compilation is initialized with references to the Zbu.ModelsBuilder assembly and that's all, so it does not have references to your own code when parsing the files in the directory, even with a using statement - unless the file is in the directory too, of course. Working on it...

[zpqrtbnk]

Fixed, now adding all BuildManager (ie ASP.NET) references before parsing the files, so it should work.

[tompipe]

Great! Thanks

[hfloyd]

I am experiencing the same issue with version 2.0.2...

The interface in question is defined in an external class... Is that what the issue is?

[hfloyd]

I figured out the problem - it actually didn't have anything to do with the interface, but with some code defined in a related custom partial class file. Once I removed that, the tool worked correctly again.