I have published a couple of NuGet packages (.NET class libraries). The packages include XML documentation file for each DLL. All packages are published on www.nuget.org and www.symbolsource.org.
Now, is there a website/service which will automatically generate (and host) documentation for my packages? I am picturing some sort of mini-site for my packages, where users can see all class definitions, their methods and related documentation from the XML file (basically something like MSDN but for my package)?
Ideally every time I publish a nuget package, I want to be able to go to www.SomeNugetDocumentationSite.com/packages/MyPackage and see MSDN-like documentation for my packages.
Thank you.
I have noticed that nudoq.org does such thing for my Pkcs11Interop package. I have never registered there or anything like that so I guess they are generating documentation from XML file which is present in the package.
However I still prefer to generate documentation with doxygen (which by the way uses the same inlined XML comments present in C# source code) and host it by myself because this way I can fully control the result.
Related
As of lately, I see that the NuGet package pages include a Documentation section:
In all packages that I've checked, though, the only contents of that section is a seemingly expandable Show more item, which, when expanded, reveals to sport no further content.
As the docs do not appear to contain any hint about how that item works, I am asking here: How can I provide (presumably) package documentation for a NuGet package that will show up in that section? (And can you point out any example package that illustrates what the docs will look like on the NuGet package website?)
Notably, my packages contain the documentation XML files generated by the C# compiler from documentation comments. Yet, nothing shows up in the Documentation section, so that's not what is supposed to appear there.
The section you are mentioning is on a specific packages page on Nuget.org. For example on the RestSharp package page, this shows the Documentation near the top of the page. This section is NOT related to any package data/details. I point out RestSharp because this package does come with a readme.txt file (which is displayed after installing that package). I initially thought it might be related to the readme.txt file. However, it is not!
No, this section is only displayed when you manually configure it from the NuGet website. See the image below (taken from a package I have previously uploaded):
You can manually add text, direct the website to a file, or upload a file directly. It is in markdown format.
I don't really understand what the point of having a package is. Every Class is kept in a different file, so what's the point of using different packages in a single project?
An Eclipse project has nothing to do with Java. It is a feature of Eclipse to organize and configure your different projects.
A Java package is a language feature of Java. You can use them to structure your project and control visibility between different classes. This becomes necessary even in relatively small projects, which already might have a few hundred classes. I suggest you look for a basic tutorial on what a Java package is and what it can do. To give you a headstart, here is what the official documentation has to say about the purpose of bundling related classes in a package:
You should bundle these classes and the interface in a package for several reasons, including the following:
You and other programmers can easily determine that these types are related.
You and other programmers know where to find types that can provide graphics-related functions.
The names of your types won't conflict with the type names in other packages because the package creates a new namespace.
You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package.
Packages are useful for many things. For example, you could store a set of files that do a given task TASK in a package named task.
Packages are a way for developers to find easily and quickly a file, knowing what the role of the file is.
Whenever your project starts growing, packages are essential.
See this lesson for basic understanding of packages utility.
I am trying to link two doxygen html documentations. To this end, I generated the first documentation for package A using GENERATE_TAGFILE, then I set in the Doxyfile of package B TAGFILES = "pathtotagfile = relpathtodocumentation". This seems to work properly, since there are no warnings. However, I the connection of the two packages is not as deep as I would like it to be.
Using doxygen 1.8.13, I only see links to the external files. Can I configure that classes and namespaces also list external stuff? I have set ALLEXTERNALS, EXTERNAL_GROUPS and EXTERNAL_PAGES to YES, but still I only see external files.
Using doxygen 1.8.4, external packages appear under Related Pages, but this seems to have been changed. I would have appreciated this. Can I reenable it in the latest version?
I also welcome hints at how Link to external documentation works. The doxygen help is a bit short here.
My team is using more and more NuGet packages as a way to break the system into smaller pieces and share things between parts. We have adopted a sort of SRP principle for packaging, creating small and hopefully cohesive packages that do just one thing (logging, auditing, security stuff, etc).
Ideally they should be so cohesive and self-contained that it would be straightforward to know what package will contain what you need. However we are not yet there and sometimes is difficult to know what package you should add to access some functionality.
My question is: is there any way to publish and navigate package content information? Like, for instance, in MSDN you can see what assembly contains a class. Would it be possible to know something like that, at the package level?
Thanks.
It's a very localised version, but there is a package searcher for the ASP.NET 5 packages hosted on NuGet. It might be possible to host a version that looks at a wider scope at some point.
https://packagesearch.azurewebsites.net/
The closest functionality I can think of is implemented in ReSharper. However it can only search the packages in nuget.org(closed issue on GitHub). Since packages don't expose type info, JetBrains built a custom index and that's the only data source it can query.
My company commonly uses Web Forms projects and MVC projects within Visual Studio. When creating a package, the package will/should be different for the different project types.
QUESTION: Rather than creating two slightly different NuGet packages that do exactly the same thing for the two different project types, is there a way to just create ONE NuGet package that's project-type independent? So when installing the package, there will be logic in, perhaps, the .nuspec file that will say "if the project this is being installed on is Web Forms, then do this. If it's MVC, then do this".
I've looked at the following link, for the different ProjectProperties on a project - this seems like something I would utilize, but I'm not sure how.
I would not create a single package for different platforms, because you're loosing flexibility. You might want to take a look at how the Glimpse guys have created their packages as they were facing the same issue.
Check the following packages and the way they are chained:
http://www.nuget.org/packages/Glimpse/
http://www.nuget.org/packages/Glimpse.Mvc4/
http://www.nuget.org/packages/Glimpse.AspNet/