0
votes

I am having the following error when adding any custom field or overriding any attribute on existing fields on Marketing Campaign screen:

\App_RuntimeCode\PX_Objects_CR_CRCampaign_extensions.cs(1): error CS0246: The type or namespace name 'AP' could not be found (are you missing a using directive or an assembly reference?)

Any idea on where to track this error?

1
"Any idea on where to track this error?" Unless you are going to fix the error yourself, it all depends who the author/owner of that PX_Objects_CR_CRCampaign_extensions.cs source file is. If it is a source file that is part of the Acumatica software, you have to file a bug report with them. If it is a source file from another 3rd party source package you are using, file a bug report with said 3rd party. If the source file is part of your own software project, you will have to file it in the bug tracker used by your company. - user2819245
It is part of a runtime customization (likely third party). Technically it can be edited by anybody as the runtime customization are not compiled (source code is available for direct modification) - Hugues Beauséjour

1 Answers

1
votes

This likely occurred because of using static directive or nested namespace.

For example, having AP.xyz nested in PX.Objects.AP produces no compiler error: enter image description here

When AP.xyz is nested in another namespace it's not found: enter image description here

The issue with using static directive is a bit different but results in the same error. This can occur because runtime code uses IIS for compilation and IIS compiler is not the latest dot net compiler. So using static directive can work when you compile a dynamic library extension in visual studio but can fail when it's compiled by IIS as part of a runtime customization.

The easy fix is to edit the files to either:

  1. Fully qualify the identifiers by changing AP.xyz to PX.Objects.AP.xyz

  2. Sometimes all that is required is to remove AP. and add using PX.Objects.AP at the top of the file if it's not there. When there's a conflict between 2 types with the same name in different namespace you must use method #1.