Build files are currently configured to treat all warnings as errors, which means that errors in documentation will cause build to fail. Please migrate documentation as and when you are migrating tcode from the Spring framework for Java project. This is less of an issue right now since the majority of the porting has already been done, but in the case of anything that has yet to be ported, or that is being ported as a part of continued development on the Spring framework for Java project, please do adhere to the guidelines on this page.
Use the following quick reference
when you need help with documentation tags. Additional information can be found on MSDN
. The current build process uses NDoc to genmerate all of the API documentation... you may find you have better mileage using NDoc's extra documentation tags.
Documenting Namespaces
In order to document namespaces (equivalent to package.html in Java), you need to crack open the 'NamespaceSummary.xml' file in the 'doc' folder just off of the top level Spring.NET solution directory (if you're using Visual Studio, this file can also be accessed from the 'Solution Items' at the bottom of the 'Solution Explorer' pane). You can then add the documentation for the namespace using this style of template...
You should copy existing documentation from package.html whenever possible.
General Documentation Guidelines
- Rename package and class names in documentation to reflect .NET names.
- Move examples into <example> tag and rewrite them in C#. The core of Spring.NET is CLR compliant, but we're only ever going to write embedded API documentation using C#.
- Add documentation where it's missing as you are going through the code.
- And never ever just type empty documentation summary tags 'cos while that does indeed shut the compiler warnings up, it irks the more anal retentive developers out there

What about GhostDoc to help auto generate some of the documentation?
http://www.roland-weigelt.de/ghostdoc/