NimbleSchedule.Api.Client
1.0.2
dotnet add package NimbleSchedule.Api.Client --version 1.0.2
NuGet\Install-Package NimbleSchedule.Api.Client -Version 1.0.2
<PackageReference Include="NimbleSchedule.Api.Client" Version="1.0.2" />
paket add NimbleSchedule.Api.Client --version 1.0.2
#r "nuget: NimbleSchedule.Api.Client, 1.0.2"
// Install NimbleSchedule.Api.Client as a Cake Addin #addin nuget:?package=NimbleSchedule.Api.Client&version=1.0.2 // Install NimbleSchedule.Api.Client as a Cake Tool #tool nuget:?package=NimbleSchedule.Api.Client&version=1.0.2
.NET library, written in C#, that can be used to consume the NimbleSchedule API.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET Framework | net461 is compatible. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
-
.NETStandard 4.6.1
- EntityFramework (>= 6.1.3)
- Microsoft.Net.Http (>= 2.2.29)
- Newtonsoft.Json (>= 9.0.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|
In this release we continue our focus on exposing all of the read-only methods of the api first. Then as planned in the roadmap, we will begin to expose the transactional api calls. Key changes in this release are noted below.
- Enclosed NimbleSchedule.Interface calls from the client within using statements so that its Dispose() method is called after the result is returned.
- Converted to C# 6.0 String format
- MethodCall.WithDynamicStringParameter($"Some strings contain {variable} data and this syntax is more fluid");
- Implemented the following api calls and unit tests:
- Locations/Index
- Locations/GetAccessibleLocations
- Countries/Index
- Departments/Index
Implemented test class constructor so that authInfo file i/o is only called once. Although in the case of test classes the constructor is called for each test method, so this would be the same as including the call in each method. However we, try to stay consistent with good coding practices by keep things DRY yet without abstracting away too much of the context so that you are still left with somewhat self-documenting code.