Prerequisite: This post assumes you understand what web APIs are, what they are designed for and how to write them. If not then take a look at this MSDN article first.

In order for web APIs to be useful they need documentation. Unlike traditional APIs there is no function signatures to look at. Even if you know the name of the “function” there is no easy way to get the parameters or return value. Hence documentation is important to anyone wanting to use such an API. If you are writing a REST API then the documentation is technically where the HATEOAS concept comes in. The reality is, for now at least, most people write web APIs using the REST API philosophy but without HATEOAS. Hence documentation is still needed.

The biggest issue with documentation is keeping it in sync with the code. We have XML doc tags for .NET languages and can use them with web API. But to be useful we have to ensure the documentation is refreshed whenever the API changes. ASP.NET solves this problem by relying on the existing XML doc tags that you’re likely already using. At runtime the documentation is rendered on demand based upon the existing comments. This is one approach to solving the problem. In this article I will take a look at the “built in” functionality, identify when it might not be useful to you and provide an alternative approach that I use.

WebHooks are a relatively new concept in ASP.NET but they have been around for a while with other platforms. GitHub, PayPal and even Dropbox support them already. If you are unfamiliar with the concept of a webHook then go read the introduction first. Recently I needed to solve a problem for which WebHooks seemed like a possible solution. This is my journey through that decision process.

When Office 2016 was released the other day I was both surprised and excited. Office 2013 has been around a while and I knew Office 2016 was in development but there was no pre-release warning, it just appeared. In the continual need to always be using the latest stuff I uninstalled Office 2013 and installed 2016. Then the problems began.

A while back I posted a series of articles on how to use T4 and a custom VS extension to simplify some common code like application settings, WCF clients and environmental transforms. With the release of Visual Studio 2015 I had to update my own extension and templates so I wanted to posted a follow up article on the changes that need to be made to allow the extension to work with Visual Studio 2015. As part of the update I added some functionality to the app settings template. Before continuing be sure to download the previous version of the series (or simply download the final version below).

UPDATE: NuGet Package Manager 3.1 has been released to Visual Studio Gallery. It resolves the issue mentioned here.

For those of you using the Visual Studio 2015 RC/RTM release you should be aware of a bug in the version of NuGet that ships with it. The bug manifests itself when building or debugging a project. When you first start VS the package is fine and you can go to ToolsOptionsNuGet Package Manager and adjust settings. Clearly the package has been successfully loaded. But when you start to build the project (or start to debug which triggers a build check) then VS may report that the package failed to load.

The problem is that NuGet is attempting to update the nuget.config file to a new version and the file is read only causing the package to fail. The file can be read only for a number of reasons but the most likely case is when you are using source control (like TFS) and the file is checked in. The bug has been reported to NuGet and appears to be resolved in future versions. For now the workaround, if you encounter this issue, is to simply modify the nuget.config file to not be read only (or check the file out of source control) so that the update can succeed.

In SSIS (SQL Server Integration Service) you often need to talk with web resources like WCF services. To do that you will generally define the connection using Connection Manager and HTTP. This sets up SSIS to communicate with the remote resource. To use the connection you normally use a script task to get the connection from Connection Manager, create an HttpClientConnection object and then use the methods on the connection to communicate with the remote server. You will generally find code similar to the following.

Quick, what is the syntax for ArgumentException? How about ArgumentOutOfRangeException? Did you know the arguments are swapped between the two? In one case the parameter name comes first while the other has the message first. Getting this wrong is so easy that it happens a lot.

.NET does not have a type to represent monetary values. In general you will simply use Decimal as it has the necessary accuracy. This has some limitations though:

Without looking at surrounding code it is difficult to tell if a variable represents money or simply a large decimal value

Currency information is not part of the type so it is possible to incorrectly mix monetary values in systems that support multiple currencies at once

Displaying money requires that you use a format string to indicate the currency

There have been many implementations of money in .NET. This is my version. Please note that this code is new so bugs may exist. Additionally I’ve taken the requirements and implementation from my own needs. Your needs may differ so you may need to modify the code to behave differently for your applications.

Time to finish up the series on simplifying data access using ADO.NET. We have simplified everything around ADO.NET except for actually retrieving the results. This is probably the most complicated part of ADO.NET given the need for cleaning up the reader, enumerating the results and reading the actual data. We can simplify all this logic down to a single line (plus any action to take for each row).