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
Is your feature request related to a problem? Please describe.
The generated code does not import any namespaces. This means that every reference to a type is fully qualified. This greatly reduces the readability of the code, especially when you use long namespaces.
Describe the solution you'd like
It would be greate if all the relevant using statements could be added to ensure that types can be referenced without namespace qualification. I realize that the current solution sidesteps the issue of class ambiguity, for example when mapping between types of the same name. This could be solved with an aliasing convention, though I'm not sure what the best one would be. A better approach would probably be just to fall back to the old approach for these cases.
The text was updated successfully, but these errors were encountered:
Thank you for opening this issue. I think it could definitely improve the readability of the generated code. We'll keep the issue around but currently other features have higher priority.
If you are interested in implementing this, feel free to contribute a concept on how this could be implemented to this issue.
Is your feature request related to a problem? Please describe.
The generated code does not import any namespaces. This means that every reference to a type is fully qualified. This greatly reduces the readability of the code, especially when you use long namespaces.
Describe the solution you'd like
It would be greate if all the relevant using statements could be added to ensure that types can be referenced without namespace qualification. I realize that the current solution sidesteps the issue of class ambiguity, for example when mapping between types of the same name. This could be solved with an aliasing convention, though I'm not sure what the best one would be. A better approach would probably be just to fall back to the old approach for these cases.
The text was updated successfully, but these errors were encountered: