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
I've tried to generate a documentation out of an API without needing specific syntax filters (C#, VB etc.).
When no syntax filters are selected, the API is documented as expected, except for the methods parameters or return values.
This is not expected.
The parameters can be documented based on their XML entries at least.
Please add the parameters in this case too, as they don't depend on anything.
If the types are the problem, can present the CLR type names, like "System.Boolean", "System.Byte", "System.Int16", "System.Int32", "System.Int64", "System.SByte", "System.UInt16", "System.UInt32", "System.UInt64", "System.Decimal", "System.Single", "System.Double" and so on.
So can be applied to the return values.
The text was updated successfully, but these errors were encountered:
It may be possible with a generic syntax generator but I'm curious as to the use case for this. Why would you want to document the API without syntax filters of any kind? If I'm going to use an API, I want to see syntax and usage examples in the language of my choice.
In my team we don't need that at all. Just to know the parameters, their base types and meaning/purpose.
Also, not generating them was a surprise, a warning or a message would have been nice (to state the reason).
Struggled a day to find the reason and articles or discussion on the Internet were misleading in this matter.
"String" or "Integer" are enough to us.
I've tried to generate a documentation out of an API without needing specific syntax filters (C#, VB etc.).
When no syntax filters are selected, the API is documented as expected, except for the methods parameters or return values.
This is not expected.
The parameters can be documented based on their XML entries at least.
Please add the parameters in this case too, as they don't depend on anything.
If the types are the problem, can present the CLR type names, like "System.Boolean", "System.Byte", "System.Int16", "System.Int32", "System.Int64", "System.SByte", "System.UInt16", "System.UInt32", "System.UInt64", "System.Decimal", "System.Single", "System.Double" and so on.
So can be applied to the return values.
The text was updated successfully, but these errors were encountered: