Discussions

I'm working with a C#-based, deploy-the-binary kind of iPart. I'm working in iMIS 2017 with Service Pack I, recently upgraded from 20.2.9. The iPart was deployed and working before the upgrade, and continued to work after the upgrade. Now we're trying to configure the iPart in content and getting this exception:

Panels inheriting AtomPanelBase must have a non-null Atom Property. Panel: ASP.iparts_xxx_resetpassword_configedit_ascx
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: Asi.Web.UI.AtomPanelAtomNotDefinedException: Panels inheriting AtomPanelBase must have a non-null Atom Property. Panel: ASP.iparts_xxx_resetpassword_configedit_ascx

Stack Trace:
[AtomPanelAtomNotDefinedException: Panels inheriting AtomPanelBase must have a non-null Atom Property. Panel: ASP.iparts_mcle_resetpassword_configedit_ascx]
Asi.Web.UI.AtomPanelPage.EnsureAtom(IAtomPanelBase atomPanelBase) +810
Asi.Web.UI.AtomPanelBase.EnsureAtom() +163
Asi.Web.UI.AtomPanelBase.OnInit(EventArgs e) +130
Asi.Web.UI.ContentItemEditBase.OnInit(EventArgs e) +46
System.Web.UI.Control.InitRecursive(Control namingContainer) +166

The iPart does have this defined. From the ResetPassword.ConfigEdit.ascx.cs file:

public override string AtomComponentName => "ResetPassword";

This compiles, so I know it's overriding a real property. I've confirmed that the property is present in the compiled DLL, so the compiler isn't optimizing it away.

This displays when adding the iPart to a page, or trying to Configure the iPart where it already lives in content. The weird part is, the existing content still runs. Even cancelling the "Configure iPart" window allows the iPart to run normally.

It looks like the Configure iPart window is trying to discover the Atom property in a different way, one that doesn't fall back to referencing AtomComponentName.

I've read that the => syntax is shorthand for declaring a get-only property, and it compiles to exactly the same code.

Did something change in the plumbing of IAtomPanelBase and IAtomPanelPage that could cause this weird behavior?