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).
This is a continuation of the series on simplifying data access using ADO.NET. We have a little cleanup to do around parameters before finishing up the series.
One of the cool new features coming in C# v6 is the nameof operator. This handy little operator solves a common code smell, string literals for programmatic items. Let’s take a simple example.
This is a continuation of a series on simplifying the use of ADO.NET. In the last article we added the ability to cleanly separate query definition from the underlying data provider. But we left out parameters which are generally critical (and specific) to ADO.NET providers. In this article we will add support for parameters and add a fluent interface to make it easy to use.
One of the changes coming with VS 2015 is how NuGet packages are managed. In VS2013 you got something like this when managing packages for a solution.
This is awesome news from Microsoft. They have finally released a new edition for VS2013. Now before you grumble about yet another edition let me clarify exactly what this means – Express is dead.
In part 3 of this series on simplifying ADO.NET data access we will finally switch gears and start providing a cleaner approach. Under the hood we will continue to use ADO.NET but it will be wrapped in a provider-agnostic layer that doesn’t require any of the boilerplate code that we are used to seeing with ADO.NET.