Microsoft Visual Studio 2013 Summary from DLLs - c#

I have been working with a DLL which contains some classes, and one of the classes has some constants. I wrote Summary for every one of these constants and these summaries appears as "tooltips" when I want to use the constants inside the DLL.
However, when I access these constants from the main project which is referencing this DLL, I don't see any Summary in the tooltip.
Does anyone know a solution for this problem? Everything is declared with a public access modifier. But MVS2013 does not cache these Summaries.

To see the summaries outside of the project you need to build the XML documentation file. Go to the project settings and select the Build section. At the bottom you'll see the "Output" options, and there will be a checkbox for XML documentation file make sure it's checked (in both debug and release modes).
If you're deploying the assembly by hand to other projects you'll need to make sure you copy the documentation XML file as well.

Related

What does the .dtbcache file do?

I have a C# WinForms project, which I am working on in Visual Studio 2017 (although it was originally created in the 2015 version).
I don't recall having done anything special, but it has added a file called .dtbcache, that it wants to add to git. The file has no extension, and a Google search doesn't show any results.
The file is located in ..\repos\myprject\.vs\MyProject\DesignTimeBuild. Which means that the "dtb" part of the file name probably means design time build, but that doesn't really make it that much better.
Can I delete it or add it to .gitignore? I would prefer not to include it in our git repository, unless it is required.
Short answer: You can safely exclude it from your Git repo.
Long answer:
You're right that dtb stands for Design Time Build. This is a file automatically created by VS2017, with a bit more information here and here (links to a blog from someone working on the Visual Studio project system). In summary, it's Visual Studio more or less extrapolating what files will be produced in order to make sure Intellisense is fully available as intended.
From the linked articles, one of the purposes of this is to make sure Visual Studio has an answer in certain cases:
Given an assembly reference in the project file, what assembly on disk is that reference going to actually refer to at compile time?
Given a XAML file, what is the code that is going to be generated by the XAML compiler at compile time going to look like?
Given a glob file pattern (*.cs), what files are actually going to be included at compile time?
So the files, being generated on the fly, are not needed in your Git repo, and can safely be excluded. Moreover, from what I can tell, these files are specifically made and used by Visual Studio 2017.

Visual Studio: Writing hints visible in other projects

Using Visual Studio 2013 and .NET I've created set of widgets which I want to use in external projects. Each class and method is well documented with the XML-style comments. For example:
///<summary>...</summary>
When I use already commented code within the same solution, the appearing prompt suggesting how to finish the line contains my remarks. Nevertheless, when I tried to generate a DLL file with the code and use it in the external project the comments were not available anymore. How can I document code to make these hints visible in other projects using the compiled DLL?
If you want to use Code Documentation when referencing dll you have to generate XML documentation. XML documentation has to be in same folder that .dll is in.

Unable to see comments in intellisense

I am developing a .Net library (dll). All the public methods are decorated with full /// comments.
When I hover over one of these methods whilst in the same solution (eg in a test project) I can see the comments as a tooltip.
However when I reference the dll in a different Visual Studio solution, I can't see the comments in the intellisense tooltip.
Is there something I need to do to 'turn this on'? I notice I can see comments when I hover over .Net library methods, for example.
In the project properties, you need to enable the setting "XML documentation file" under the Build tab - and then keep the generated Xml file in the same folder as your Dll.
You need to make sure 'Generate XML documentation file' is enabled in your project settings.
(Compile tab on VB, not sure exactly where it is in C#).

Adding reference (e.g by adding "using system.web" ) once for multiple libraries [duplicate]

I am a recently converted VB developer to C#, but there is one thing thus far that I haven't been able to find. In VB when I setup a new project I can specify the namespaces used in the project and add them to the default imports for all classes (so everything automatically has them as if I added "Imports System.Data.OracleClient" to each class). With C# I've found that I'm always typing these in for each new class. Is there a way to setup defaults for projects so it at least appends those to every class file for me automatically?
No there is no way. C# does not support the concept of project level imports or project level namespaces.
The only thing you can do is alter the item template you are using (Class.cs or Code.cs) to have the namespaces you would like. These files are located under the following directory
%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\itemtemplatescache\CSharp\Code\1033
Under here you should see a Class.zip and Code.zip directory each with a .cs file under them. This is the template file used when you do an "Add New Item" operation in Visual Studio. You can change these to meet your needs and have the default namespaces you'd like.
A slightly easier solution though is adding a per-user code file for the particular project you'd like. Simply create a code file you want to be the template for your application and then place it in the following directory.
C:\Users\YourUserName\Documents\Visual Studio 2008\Templates\ItemTemplates\Visual C#
This file will now show up whenever you do a "Add New Item" operation.
Others have suggested using templates etc. Personally I find it's just not a problem - I type the name of the class that I want to use into Visual Studio, and even if it's not found the "smart tag" (or whatever it's called) icon pops up. I hit Ctrl-. and it adds a using directive for me.
I think ReSharper helps to make this work even better, but it's so automatic for me now that I don't really think about it much any more. (I suspect the difference is that with ReSharper I can hit Alt-Enter at any point in the line and it'll offer the correction, instead of having to have the cursor in the type name itself for Visual Studio.)
With C# 10 this answer has changed.
C# 10 introduces [Global using directives][1]:
Global using directives
You can add the global modifier to any using directive to instruct the compiler that the directive applies to all source files in the compilation. This is typically all source files in a project.
no, there's no my namespaces in C#. I think you can probably accomplish the same thing with project templates or code snippets.
See this post for the answer..
Which, in a nutshell, is adding the usings you want to a template.
I believe you want to start here.

How do you get the XML documentation to show for a referenced C# library?

Suppose you have a C# library with several functions, all documented with the usual /// <summary> filled out nicely. Referencing the project will make the function and parameter description appear in the Visual Studio contextual help. But is it possible to have this show if you don't reference the project itself, just a build (and potentially some other file that has the documentation inside)?
Yes there is - the library needs to be built with the "XML Documentation file" tickbox checked (in the project property pages)
With this option ticked the build process will now build an extra XML file in the output directory which contains all of the xml documentation - whenever Visual Studio references an assembly by file it will load and show intellisense documentation from this XML file (if it can be found).
You should distribute this file alongside (in the same directory as) your compiled library.

Categories