.NET Client Library Release History

Version 1.4

• Added DegreeDays.Api.Regressions namespace to give API access to advanced regression functionality that was previously only available via the online regression tool.
• Increased the maximum number of DataSpec items in a request from 100 to 120.

Version 1.3

Added allowPartialLatest property to DatedBreakdown, to make it possible to fetch time-series data (like hourly temperature data) that includes figures for the current day so far.

Version 1.2

• Added TimeSeriesDataSpec and related classes for fetching time-series data (like hourly temperature data).
• Added support for custom breakdowns (typically used to fetch degree days to match irregular energy-usage data).
• Bundled IntelliSense docs with the NuGet package so they are available after installation through the NuGet Package Manager.

Version 1.1.1

A rebuild of version 1.1 to get it listed in NuGet.

Version 1.1

Added LocationInfoRequest to make it possible to do "two-stage data fetching" (described in the remarks for this class). Now you can find out what station the API would use to generate data for a geographic location (postal/zip code or longitude/latitude position), without having to use up a lot of request units actually fetching that data. This is useful if you are storing data by station ID and have enough real-world building locations that many of them share the same weather station.

Version 1.0.1

Bug fix: LongLatLocation was not working properly on systems that had the comma configured as the decimal separator. Silly us, we were using ToString to turn the double longitude and latitude values into strings for the XML request, when .NET's ToString uses the system settings to decide what decimal separator to use (and the API servers only allow '.' as the decimal separator). Apologies if you were affected by this bug.

Version 1.0

Exactly the same as version 0.9.4, apart from the version number. This .NET client library has been used in a number of systems for several months without issue, so we've decided it's time to declare it stable and label it version 1.0.

Version 0.9.4

Fixed a bug that was causing the MinutesToReset property of the RateLimit object to consistently return 1, causing sleeping background processes to awake many times more often than they needed to. A careless mistake on our part. Apologies for the previous releases containing this bug!

Version 0.9.3

No breaking changes.

This release added a strong name key to the DLL. The main reason was to resolve a problem for a client that was getting the following exception when trying to use DegreeDaysApi.dll as part of an ASP.NET web site:

System.Security.SecurityException: Request for the permission of type
'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089' failed.

We think this exception arose because the client had the DLL stored on a network share. When testing the web site locally, the development server was assuming that the DLL on the network share could not be trusted (as it could have been swapped for a malicious DLL if the network share was not locked down).

Now the DLL has a strong name, it can be referenced in web.config with a public key that .NET will check against the public key of the DLL. That way .NET can check that the DLL is the right one. To reference the DLL with a public key from web.config, add a line like the following within the <assemblies> element (within the <compilation> element within the <system.web> element):

<add assembly="DegreeDaysApi, PublicKey=0024000004800000940000000602000000240000525341310004000001000100d7e45113e0489e8fd8670f3b59292134481c5c4dece64449c2c6a7ce192e96ec9bfc86ecfefe07f81da32c374162a8a8c851bbc09128cb450888ab0baa79a267202549578dc375c14ccc54cd129bbbaec1eb4a11be68bedf8ee3c1e8e2b75f40be40af2ef77bdf42b8374adb617db9b9ff06ccb0a3ea9899a5e1ee1e930e3ba4"/>

The public key above is the right one for DegreeDaysApi.dll, and it should remain the same for future releases. You could also put PublicKeyToken=93e84014749cc07c instead of the full PublicKey, but we're not sure if that would be enough to prevent the SecurityException if the DLL was on a network share.

Note that there's probably no need to reference the DLL from web.config at all unless your app is accessing DegreeDaysApi.dll from an untrusted location or is running in an environment with reduced security permissions.

Version 0.9.2

No breaking changes, only internal changes:

• Fixed a bug that meant that some network-connectivity problems would result in a NullReferenceException instead of the TransportException that should have been thrown.
• Replaced a [MethodImpl(MethodImplOptions.Synchronized)] on an internal method with a method-internal lock, and made two private static variables readonly. These changes make no practical difference for normal use of the DLL, but we think they should make it possible to load the DLL into SQL Server (for use in a SQL CLR project) without having to use PERMISSION_SET = UNSAFE (the aim is for PERMISSION_SET = EXTERNAL_ACCESS to be enough).

Version 0.9.1

No breaking changes, only internal:

• Fixed bug that prevented the DLL from connecting to the API servers through a proxy server. Now if Windows is configured to use a proxy server (through the Internet Explorer settings), or if .NET is configured to use a proxy server (e.g. in app.config or web.config), the DLL should also use that proxy server automatically.

Version 0.9

First public release! This version works well, but it's not yet version 1.0 because it's possible we'll want to make some minor breaking changes to the API of the client library. If we were to make any breaking changes, they should only be small, and they should only affect you if you upgraded the DLL. So don't let the 0.9 version number stop you from developing against this client library today.

Back to .NET Quick-Start Guide