You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the --nullableReferenceAttributes is set some members are annotated with nullable attributes. At least in my usecases most of the members won't receive any attribute, but should be treates as non nullable. Because the compiler does not emit nullable attributes for tool generated source code. There is currently no easy way to get non oblivious nullability annotations. The only way to enable nullable annotions from the compiler is to explicitly enable #nullable in the generated source file.
The global nullable context does not apply for generated code files. Under either strategy, the nullable context is disabled for any source file marked as generated. This means any APIs in generated files are not annotated. There are four ways a file is marked as generated: [...]
Therefore i suggest to add a new flag, that will emit a #nullable at the start of the generated file.
From a pure "does it compile" standing point, it should be save the emit #nullable enable whenever --nullableReferenceAttributes and --netCore is set. But there might be xsd schemas, that would lead to property falsely annotated as non nullable.
The text was updated successfully, but these errors were encountered:
Pretasoc
changed the title
Add flat to emit #nullable enable
Add flag to emit #nullable enableJul 28, 2022
From a pure "does it compile" standing point, it should be save the emit #nullable enable whenever --nullableReferenceAttributes and --netCore is set. But there might be xsd schemas, that would lead to property falsely annotated as non nullable.
Can you give an example?
Where should we put the #nullable enable? Before the leading comment or after?
Actually i don't have an example, where adding #nullable enable would result in wrong annotations. Its simply that i dont feel confident enough to say, there will never be a problem. I think a very common source of wrongly annotated classes could be bad designed schemas, but thats a scope we can't handle here. However i will do some investigations, whether its save or not to emit the #nullable enable in the cases mentioned above.
Where should we put the #nullable enable? Before the leading comment or after?
The microsoft documentation is not really specific about it. I tested sucessfully with putting it between the leading comment and the first namespace declaration
When the
--nullableReferenceAttributes
is set some members are annotated with nullable attributes. At least in my usecases most of the members won't receive any attribute, but should be treates as non nullable. Because the compiler does not emit nullable attributes for tool generated source code. There is currently no easy way to get non oblivious nullability annotations. The only way to enable nullable annotions from the compiler is to explicitly enable#nullable
in the generated source file.Therefore i suggest to add a new flag, that will emit a
#nullable
at the start of the generated file.From a pure "does it compile" standing point, it should be save the emit
#nullable enable
whenever--nullableReferenceAttributes
and--netCore
is set. But there might be xsd schemas, that would lead to property falsely annotated as non nullable.The text was updated successfully, but these errors were encountered: