Table of Contents

Generation message level configuration

The level of some messages emitted by the Neos generator is configurable.
These messages appear like this in the output of the neos generate command:

{Time} {MessageLevel} {MessageCode}:{ElementIdentifier} - {Message}

You can disable them globally with the GenerationLogLevels property in the cluster configuration:

GenerationLogLevels:
  {MessageCode}: None

It is also possible to change the log level:

GenerationLogLevels:
  {MessageCode}: Information
Warning

We advise you to never use this feature to reduce the severity level of a message.

If you judge that on a given element the message is not justified (a rule does not always apply to 100% of cases), it is possible to customize the log level only for this element.

In Neos Studio, you must go to the properties of the module containing the element and activate the Generation message level configuration tab. From this screen, you can configure the log level by indicating {MessageCode} and {ElementIdentifier} as well as a justification.

UI template references

Since Neos 3.2, UI template generation validates every reference to a UI view, an image, a menu, a lookup, a string resource, or a UI component:

  • it must point to an element that exists,
  • the referenced element's module must be a declared module dependency of the template's module,
  • if the referenced element is Internal, the template's module must be granted access — see Module accessibility.

The two checks are not configured the same way. Existence and module-dependency violations are warnings — mostly collapsed into a single generic message code, so lowering it also silences unrelated template warnings; use with care. Internal-accessibility violations are hard generation errors with no message code at all — they cannot be ignored through GenerationLogLevels. In both cases, fix by correcting the reference, adding the missing ModuleAssociation, or granting InternalAccessGrantedTo as appropriate.

.NET type references across modules

A metadata property that references an arbitrary .NET type by name (for example a DataObjectProperty.DotNetDataType, or a ProgrammableObjectParameter) is free text, so neos generate validates it on two independent axes:

  • M0090 — the referenced type is Internal and its module has not granted access to the referencing module. Fix the same way as an Internal-accessibility violation elsewhere: grant InternalAccessGrantedTo, or make the type Public if it is meant to be broadly reusable.
  • M0091 — the referenced type's module is not a declared ModuleAssociation dependency of the referencing module, regardless of Accessibility. Declare the missing dependency, or, if the two modules would then depend on each other in both directions, reconsider which module should actually own the referenced type.

Covers DataObject, Interface, EnumType, ConstantsStaticClass, Notification, ProgrammableObject, Entity, EntityView, UIView, and UIComponent — a smaller set than the transpiled-UI-C# [Origin] check (no ServerMethod, UISharedMethod, Lookup, Theme, Image, Report, or ReportStyle).

.NET compilation diagnostics

neos generate builds several scaffolding projects internally (CSharpAbstractions, AspNetCore, TaskRunner). When one of them fails to compile, the individual dotnet build diagnostics are parsed and reported one by one, deduplicated across the internal builds that can overlap on the same generated files:

  • M0092 (DotNetCompilationError) — a real .NET compilation error, shown by default (like any code, its level can be reconfigured through GenerationLogLevels or a per-element override — see the warning above).
  • M0093 (DotNetCompilationWarning) — a compilation warning, hidden by default like other diagnostics of this kind; enable it through GenerationLogLevels or a per-element override if you need to see it.

A diagnostic with a source position (file(line,col)) is reported with that file/line/column; one without a position (a NuGet restore failure, or a lower-level MSBuild/compiler error) is still reported and coded, just without a position.

The full raw output of the underlying dotnet build process is not shown by default anymore (it used to be logged in full for every failing build, which produced duplicate, uncoded log entries). It is still captured at the Verbose log level, so if a coded diagnostic alone isn't enough to diagnose a failure, rerun with neos [log:verbose] generate (or [log:debug]) to see it.

If the build process exits with an error but none of its output could be recognized as an individual diagnostic (an unexpected tool crash, for example), the raw output is still logged as an error by default, exactly as it was before this change — a build failure is never silently dropped, even in that case.