kontent-ai/delivery-sdk-net

Kontent.ai Delivery .NET SDK

Kontent.ai Delivery .NET SDK

Paradigm	Package	Downloads	Compatibility	Documentation
Async			net8.0	📖 Wiki
Reactive			net8.0	📖 Wiki

Summary

The Kontent.ai Delivery .NET SDK is a client library that lets you easily retrieve content from Kontent.ai.

Getting started

Installation via Package Manager Console in Visual Studio:

PM> Install-Package Kontent.Ai.Delivery

Installation via .NET CLI:

> dotnet add <TARGET PROJECT> package Kontent.Ai.Delivery

Usage

To retrieve content from your Kontent.ai environments, you'll be using an implementation of the IDeliveryClient interface. This is the main interface of the SDK. Here's how you can instantiate and use the Delivery client either with DI/IoC or without DI/IoC.

Use dependency injection (ideal for ASP.NET Core web apps)

Startup.cs

public void ConfigureServices(IServiceCollection services)
{
	services.AddDeliveryClient(Configuration);
}

HomeController.cs

public class HomeController
{
	private IDeliveryClient _client;

	public HomeController(IDeliveryClient deliveryClient)
	{
		_client = deliveryClient;
	}
}

In this case, the SDK reads the configuration from the DeliveryOptions section of the Configuration object. There are many ways of providing the configuration to the DeliveryClient as well as many advanced registration scenarios which you can all find in the Wiki.

To see a complete working example, go to one of our sample apps:

• Kontent.ai ASP.NET Core MVC or
• Kontent.ai ASP.NET Core Razor Pages

To spin up a fully configured blank site quickly, use the:

• Kontent.ai ASP.NET Core MVC boilerplate

Usage without IoC/DI containers (ideal for console apps, unit tests...)

You can also set up a DeliveryOptions manually using the DeliveryClientBuilder.

IDeliveryClient _client = DeliveryClientBuilder
    .WithOptions(builder => builder
        .WithEnvironmentId("<YOUR_ENVIRONMENT_ID>")
	.UseProductionApi()
	.Build())
    .Build();

Your first request

Use the .NET code generator to generate POCO models:

public class Article
{
        public string Title { get; set; }
        public string Summary { get; set; }
	public string Body { get; set; }
	public DateTime? PostDate { get; set; }
	public ContentItemSystemAttributes System { get; set; }
}

Call the IDeliveryClient to retrieve data from Kontent:

// Retrieving a single content item
var response = await _client.GetItemAsync<Article>("<article_codename>");
var title = response.Item.Title; // -> "On Roasts"
var lang = response.Item.System.Language; // -> "en-US"

See Working with Strongly Typed Models to learn how to generate models and adjust the logic to your needs.

Further information

For more developer resources, visit:

• ✔️ Best practices for Kontent.ai Delivery SDK for .NET
• Kontent.ai Learn:
  • .NET Tutorials
  • API Reference

Get involved

Check out the Contributing page to see the best places to file issues, start discussions, and begin contributing.

delivery-sdk-net's Issues

In the Pagination when retrieving lists of content items it should give either total available items or total available pages

If I want to implement traditional pagination on my site/app I need to be able to find out how many total items there are available in the result set without paging, but only retrieve the current page's items.

The Pagination object seems to be the right place for this but it doesn't seem to work like this, instead only returning the number of items currently retrieved which is the single page worth.

Unit tests vs. integration tests?

Do we want/need to expand the testing to unit tests? The current tests look like integration tests to me as they rely on at least two different projects (which could get modified) and requires the deliver endpoint to be accessible and available.

Let the SDK bypass the CDN for particular requests

Motivation

Currently, the DeliveryClient can either be configured to utilize or circumvent the CDN of Kentico Kontent, as a whole. One of the pitfalls of this is when an app clears its cached Kentico Kontent data and needs to fetch the most-up-to-date content in the very subsequent Delivery request.

Design guidelines

Allow the SDK to sense whether it should use the X-KC-Wait-For-Loading-New-Content header for each particular request.

Based on the signal, the SDK should either use the header or not.

The logic that decides whether to send the signal, it should be outside the SDK (eg. in our boilerplate project).

If no signal is sent explicitly, the SDK should not use the header (ie. not bypass the CDN).

Add mocked responses to the rest of the unit tests

Similarly to #22 (PR #83), add fixtures to ContentLinkResolverTests and ValueConverterTests.

Fully support DI instantiation

Enrich this constructor with all the publicly exposed interfaces of DeliveryClient - IContentLinkUrlResolver, IInlineContentItemsProcessor , and ICodeFirstModelProvider so that we can use proper DI instead of this.

Some extra info for unit testing:
https://andrewlock.net/using-dependency-injection-in-a-net-core-console-application/

Fix unit tests

• the KC project referenced by DeliverClientTests seems to be empty...we should point it to another project

project guid: e391c776-9d1e-4e1a-8a5a-1c327c2586b6

nunit test runner: https://github.com/nunit/dotnet-test-nunit

Spike: Context-aware caching

Expected outcome

Originally, the CachedDeliveryClient had stored data in memory cache for a fixed period of time. As the boilerplate now purges cache entries via web hook push notifications, the timeout defined in settings is no longer important. The CacheTimeoutSeconds appsettings.json value is therefore set to a generous value of 24 hours. Still, the situation is not ideal. The app may appear in a memory pressure condition where the MemoryCache logic may start an uncontrolled cache eviction process.

Find ways of setting the level of importance of various sorts of data in cache. This value should then be used by the framework code to prioritize the cache entries for the purpose of eviction.

Also, identify factors that most often affect the levels of importance. If such factors stem from the state of the app and could be computed, design an implementation (in a high-level fashion).

Reference

• https://github.com/Kentico/cloud-boilerplate-net/blob/master/src/content/CloudBoilerplateNet/Services/ReactiveCacheManager.cs
• https://github.com/Kentico/cloud-boilerplate-net/blob/master/src/content/CloudBoilerplateNet/appsettings.json
• https://docs.microsoft.com/en-us/dotnet/api/system.web.caching.cacheitempriority

Pulling strongly typed content item without it's modular content throws an exception.

Problem is most likely on this line https://github.com/Kentico/delivery-sdk-net/blob/master/KenticoCloud.Delivery/CodeFirst/CodeFirstModelProvider.cs#L116

Failing test

[Test]
public void FailingTest()
{
	var client = new DeliveryClient("975bf280-fd91-488c-994c-2f04416e5ee3");
	client.CodeFirstModelProvider.TypeProvider = new CustomTypeProvider();

	// Returns on_roasts content item with related_articles modular element to two other articles.
	// on_roasts
	// |- coffee_processing_techniques
	// |- origins_of_arabica_bourbon
	//   |- on_roasts
	var onRoastsItem = Task.Run(() => client.GetItemAsync<Article>("on_roasts", new DepthParameter(1))).Result.Item;

	Assert.AreEqual(2, onRoastsItem.RelatedArticles.Count());
	Assert.AreEqual(0, ((Article)onRoastsItem.RelatedArticles.First()).RelatedArticles.Count());
	Assert.AreEqual(0, ((Article)onRoastsItem.RelatedArticles.ElementAt(1)).RelatedArticles.Count());
}

public class CustomTypeProvider : ICodeFirstTypeProvider
{
	public Type GetType(string contentType)
	{
		switch (contentType)
		{
			case "article":
				return typeof(Article);
			default:
				return null;
		}
	}
}

public partial class Article
{
	public string Title { get; set; }
	public IEnumerable<object> RelatedArticles { get; set; }
}

Add roslyn analyzers & fix potential issues

Motivation

We use tests to prevent bugs. To make test code as reliable as it gets, the XUnit team has leveraged Roslyn to create XUnit Analyzers. It is a NuGet package that will make Visual Studio warn about issues that were not visible before.

Howto

• Add xunit.analyzers to the test project
• Fix found issues

Resources

http://davidpine.net/blog/xunit-powered-by-roslyn/

Add support for secured access to published (production) content

In coming weeks, the Delivery API will start supporting authenticated access.

In the first version of this feature, content will be secured using an API key. The developer will be able to turn the authenticated access on and off for the whole project. There will be one authentication key for the project, not multiple ones (for various user roles, for example).

Implement support for submitting the key in the form of the "Authorization" request header. The key should be sent via the Bearer scheme (with a "Bearer " prefix).

We'll provide more information once they become available. https://kenticocloud.com/roadmap#secured-delivery-api

Assets don't include "Description" property

The asset type doesn't include the "description" property that is now available.

Replace usage of the sample project in tests with mocked responses

Currently, the DeliveryClientTests depends on two sample projects in Kentico Cloud ("975bf280-fd91-488c-994c-2f04416e5ee3" and "e1167a11-75af-4a08-ad84-0582b463b010").

• We'd like to remove that dependency and use fake responses instead. Ideally, it should be done by mocking the httpclient (via moq or fakeiteasy).
• add test for #43 (item.AssetField.First().Description)

Implement simple caching

Make it possible to inject HttpClient

More details at:
https://forums.kenticocloud.com/discussion/comment/157#Comment_157

Add language variant filtering support to the LanguageParameter

Motivation

Currently, the LanguageParameter does not support filtering based on language variants.

var response = await DeliveryClient.GetItemsAsync<Article>(new LanguageParameter("en-US"));

It would be nice if it was possible to ignore language fallbacks as described in the documentation:

This means that the LanguageParameter needs to be enriched with filtering based on system.language on top of the currently present language.

Design guidelines

Let's create two new constructors:

// This one will cause the system.language to be set instead of language
public LanguageParameter(string language, bool ignoreFallbacks = false)

// This one will set both language and system.language
public LanguageParameter(string language, string languageVariant = null)

The GetQueryStringParameter() method will need to be adjusted to return one or two query parameters in a single string.

• Don't forget to add unit tests

CI / CD improvements

• Set up Appveyor for build
• Enable tests in AppVeyor (wating for #4)
• Set up branch protection for pull requests
• Set up automatic artifacts generation
• Set up version incrementation for artifacts
• Set up automatic artifacts publishing from master to NuGet

WaitForLoadingNewContent

// Set to true if you want to wait for updated content. It should be used when you are acting upon a webhook call.

8edf2cf

Depth=0 vs Depth=1 & modular content

While requesting our blog post content items with depth=0 and selecting also top-level modular content author i get this response:

You can see, that the "author" modular content is present in the json response. However, when i use
item.GetModularContent("author"), null is returned.
When setting depth=1 , the same exact json response is returned; however, item.GetModularContent("author") returns expected values.
I am really confused, is this really the intended behavior? I thought the depth parameter should limit the amount of data I'm gonna receive (also, i can easily avoid the SDK and get my author data from the response directly).

Spike: Support interfaces as generic parameters of collections

Motivation

In strongly typed models, this is supported:

IEnumerable<MyType> CollectionOfMyTypes { get; set; }

and this is not:

IEnumerable<IMyType> CollectionOfMyInterfaces { get; set; }

This applies both to externally defined types and types defined within the SDK (Asset, TaxonomyTerm).

We should give developers the freedom to unwind from specific classes and work with Kontent data through interfaces. For example, defining shadow properties wouldn't be necessary anymore.

Expected spike outcome

Propose a way of defining translations between interfaces and concrete types.

These translations would be used in CodeFirstModelProvider wherever Activator.CreateInstance(...); is called.

There would be default translations for Asset, TaxonomyTerm and other types defined in the SDK to maintain backwards compatibility.

As for how we could allow the CodeFirstModelProvider to translate interfaces to objects, maybe we can leverage the good old IoC pattern. A brief spike revealed that 3 out of 4 popular IoC containers for .NET Core use the IServiceCollection abstraction to work with the services and their implementations.

Namely:

• Lamar's ServiceRegistry class implements IServiceCollection.
• AutoFac works directly with ServiceCollection, which is a default implementation of IServiceCollection.
• And of course, the default Microsoft.Extensions.DependencyInjection work with IServiceCollections.

The obvious way how the CodeFirstModelProvider would obtain the IServiceCollection would be through a DeliveryClient constructor (in ASP.NET Core apps, in Startup.cs).

Reported by: @kenticomartinh and @JanLenoch

Spike: Simplify IDeliveryClient and get rid of its internal dependencies/references

Motivation

• IDeliveryClient contains members such as IContentLinkUrlResolver, ICodeFirstModelProvider, or IInlineContentItemsProcessor which shouldn't be part of the contract at all. Currently, they're there just because of internal referencing of the DeliveryClient in the underlying code.
• The wrong code can be easily identified:
  • All references to this in the DeliveryClient (and references to IDeliveryClient in the underlying code
    • such as _contentLinkResolver = new ContentLinkResolver(_client.ContentLinkUrlResolver); in the ContentItem.
    • or _client.CodeFirstModelProvider.GetContentItemModel<T>(source, _response["modular_content"])) in DeliveryItemListingResponse<T>

Expected spike outcome

We should come up with a way to get rid of these dependencies and simplify the IDeliveryClient contract.

Things to consider:

• we could utilize DI, however we'd like to avoid using any particular DI framework
  • we don't want to push consumers of the library to use a specific DI framework
  • we might want to introduce some simple DI of our own making, crafted just to fit our needs
    • there would be a default implementation of the container with a possibility to replace the logic
    • it should also be possible to inject a DI framework of user's choice to take care of the instantiation completely
      • is there some kind of generic DI interface that we could expose for replacement?
  • we should keep in mind that the user can create multiple instances of the DeliveryClient in a single application. So a simple singleton might not be the right thing for us.
• another approach would be to refactor the logic in a way that no DI is needed.
  • in a way that all the complex stuff happens outside of the models/response objects and the models/responses are just dummy container objects

Fix XML documentation warnings

https://ci.appveyor.com/project/kentico/deliver-net-sdk

E.g.

CodeFirst\CodeFirstModelProvider.cs(60,66): warning CS1574: XML comment has cref attribute 'T' that could not be resolved [C:\projects\deliver-net-sdk\KenticoCloud.Delivery\KenticoCloud.Delivery.csproj]

GetItemsAsync<T> should generate type filter automatically

Strongly typed methods like GetItemsAsync<T> should generate and apply a type filter automatically.

T contains codename of the content type (see e.g. Cafe.cs) so it should be no problem.

CodeFirstModelProvider shouldn't set null for collections

It should be consistent with ContentItem.

With ContentItem.GetModularContent("related_articles") I get an empty collection if there is no modular content. With custom Strongly Typed model, I get a null value.

It forces me to use null check in my MVC views

foreach(var article in Model.GetModularContent("related_articles"))
{ ... }

// vs.

if (Model.RelatedArticles != null) 
{
    foreach(var article in Model.RelatedArticles)) { ... }
}

IMO it's safer to return an empty collection. Developers won't see so many exceptions on their websites 🙂

Support casting DeliveryItemListingResponse->DeliveryItemListingResponse<T>

Users should be able to cast the DeliveryItemListingResponse to its generic version.

• Implement similarly to DeliveryItemResponse
• Add and unify comments of all CastTo methods

Use Guid.TryParse instead of PROJECT_ID_MAX_LENGTH for validation

Adjust the DeliveryClient.

Add language property within system fields

The .Net SDK doesn contain the language property within system fields (ContentItemSystemAttributes class).

Update README with contribution guidelines

Allow excluding properties from (de)serialization

• Enrich https://github.com/Kentico/delivery-sdk-net/blob/master/KenticoCloud.Delivery/CodeFirst/CodeFirstPropertyMapper.cs with http://www.newtonsoft.com/json/help/html/PropertyJsonIgnore.htm
  to allow excluding properties from deserialization...
• Write unit tests

This comes in handy in situations such as:

public IEnumerable<object> X { get; set; } // element name x exists in kentico cloud
public IEnumerable<Product> Y { get { return X.Cast<Product>(); } set { X = value; } } // element name y does not exist in KC

where one property would overwrite the other. (Typical when extending models via partial classes.)
Warning: order of properties in a code file is significant!

Document strongly-typed model retrieval

we need to document these changes:
3e46027

Update wiki with the new capabilities of the code generator

To document: [--withtypeprovider] CLI option (kontent-ai/model-generator-net#11)

Taxonomies documentation

• add an example to readme (demonstrating usage of the taxonomy api)

Support for ReactiveX programming

Are there any plans to support ReactiveX and their Rx.NET extension?

I feel like this could be a nice addition to the SDK as it would make working with (especially multiple) asynchronous operations much easier. Especially it would help with cancelling, chaining, retrying and error handling of the http requests that are made to Kentico Cloud.

The highest benefit would receive UI heavy applications (i.e. desktop apps), but it would be useful for web as well.

Migrate to VS2017

Blocked until 2017-04-07 (VS2017 RELEASE+1 month)

• Migrate the project to VS2017 (xproj -> csproj)
• Fix AppVeyor (this needs to be done by Kentico)
  • Make sure tests are running fine
  • Make sure artifacts are being produced

Resources:

• http://www.natemcmaster.com/blog/2017/01/19/project-json-to-csproj/
• http://www.natemcmaster.com/blog/2017/02/01/project-json-to-csproj-part2/
• http://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

Use constructor chaining

Use :this() to chain the two almost identical constructors.

Support of 'Modular Content in Rich Text Elements'

With the introduction of that feature, the SDK should scan for tags inside of Rich text elements to build more structured objects using the runtime typing functionality. That way, the included Modular content items would get recognized and rendered by frameworks like MVC.

Improve pagination in the DeliveryItemListingResponse

As part of the DeliveryItemListingResponse object, the Pagination.NextPageUrl property provides a reference to getting the next page data.

The GetItemsAsync method should have an overload to be able to get the next page data, either using the NextPageUrl, or something more appropriate.

Set up code coverage

Generating coverage:

• dotnet test --collect:"Code Coverage" only works if Visual Studio Enterprise is installed.

  • appveyor has only the community edition

• coverlet

  • example: coverlet .\bin\Debug\netcoreapp2.1\hanselminutes.core.tests.dll --target "dotnet" --targetargs "test --no-build"
  • or: dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov .\hanselminutes.core.tests for nuget package

• Compare and pick a code coverage service

  • Comparisons:
    • https://stackshare.io/stackups/codecov-vs-coveralls
    • https://www.slant.co/topics/2188/versus/~codecov_vs_coveralls_vs_code-climate
  • Services:
    • Code Climate - we slightly prefer this as we use it in other repos
    • Codecov
    • Coveralls

• Set it up

Examples for .NET Standard libraries:

• https://github.com/keenlabs/keen-sdk-net/blob/master/.appveyor.yml

Generic filters

Current situation:
When I want to use e.g. GreaterThanFilter with DateTime I have to know how to format the DateTime so that the API accepts it.

Proposed solution:
We should solve this in a generic way. The filters should accept <T> as a value and handle the formatting internally based on the type.

• public abstract class Filter (the base class for filters) should be switched into a generic class
• it should have an extra constructor accepting <T> and storing it in a public property
• getter of public string Value should be modified to take the type into consideration
  • for DateTime it should format it to the ISO 8601 format (accepted by the delivery API)
  • for the rest it should call just ToString()
• adjust filters inheriting from Filter correspondingly (where it makes sense)
• add unit tests
• adjust the readme if necessary
• all changes should preserve backward compatibility

Suggestions for any better approaches appreciated!

Use IDeliveryClient wherever possible

Places like internal DeliveryItemResponse(JToken response, DeliveryClient client) should use IDeliveryClient.

The concrete implementation - DeliveryClient - shouldn't be used in the SDK at all.

Use IOptionsSnapshot instead of IOptions

Prerequisity

#117

Motivation

Once an app is initialized, the configuration of the SDK is set in stone. To reload the configuration (for new instances of the DeliveryClient, for example), the app needs to be restarted.

Design guidelines

Use IOptionsSnapshot instead of IOptions to allow reloading of configuration.

Resources

• https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration

Response objects should contain data for easier debugging

It's usual that the response objects contain data for easier debugging.

In our case, we should include:

• API URL (URL constructed by DeliveryEndpointUrlBuilder)
• Raw data (JSON string)
  to make debugging easier.

The remaining questions is - should we make it private and fill it only #if DEBUG or should it be available all the times via public properties?

Support for custom type property mapping (Value Converters)

Prototype implementation:
f72373c

This would nicely solve scenarios such as:
https://forums.kenticocloud.com/discussion/49/support-nodatime-in-property-types#latest

Support .NET Standard

We should start targeting .NET Standard to enable usage on different platforms.

Get rid of build-time conditions

Convert this:

 #if (DEBUG && NET45)
        private string PRODUCTION_ENDPOINT = ConfigurationManager.AppSettings["ProductionEndpoint"] ?? "https://deliver.kenticocloud.com/{0}";
        private string PREVIEW_ENDPOINT = ConfigurationManager.AppSettings["PreviewEndpoint"] ?? "https://preview-deliver.kenticocloud.com/{0}";
        #else
        private const string PRODUCTION_ENDPOINT = "https://deliver.kenticocloud.com/{0}";
        private const string PREVIEW_ENDPOINT = "https://preview-deliver.kenticocloud.com/{0}";
        #endif

in DeliveryEndpointUrlBuilder to use ASP.NET Core Configuration.

Custom class that can read appSettings from web.config needs to be implemented.

IQueryable<T> LINQ Provider

Current situation:

var parameters = new IQueryParameter[]
            {
                new AllFilter("elements.personas", "barista", "coffee", "blogger"),
                new AnyFilter("elements.personas", "barista", "coffee", "blogger"),
                new ContainsFilter("system.sitemap_locations", "cafes"),
                new EqualsFilter("elements.product_name", "Hario V60"),
                new GreaterThanFilter("elements.price", "1000"),
                new GreaterThanOrEqualFilter("elements.price", "50"),
                new InFilter("system.type", "cafe", "coffee"),
                new LessThanFilter("elements.price", "10"),
                new LessThanOrEqualFilter("elements.price", "4"),
                new RangeFilter("elements.country", "Guatemala", "Nicaragua"),
                new DepthParameter(2),
                new ElementsParameter("price", "product_name"),
                new LimitParameter(10),
                new OrderParameter("elements.price", SortOrder.Descending),
                new SkipParameter(2)
            };
client.GetItemsAsync(parameters)

Ideal situation:

var items = client.GetItems<Article>().Where(a=>a.Name.Contains("xyz").Skip(2)....;

Resources:

• https://msdn.microsoft.com/en-us/library/bb351562(v=vs.110).aspx
• https://msdn.microsoft.com/en-us/library/bb546158.aspx
• https://blogs.msdn.microsoft.com/mattwar/2008/11/18/linq-building-an-iqueryable-provider-series/

AppVeyor should increment hotfix part of the version only

Currently, AppVeyor replaces the NuGet packes version in project.json to current build version. It would be better if it would increment the hotfix part (third number) only.

Let the DeliveryClient be initialized by passing a configuration section

We should let the DeliveryClient (and its subclasses) read from a configuration object . The consumer would have the option of passing a configuration object and not having to provide projectid and preview api key explicitly through the constructor.

This story should lead to a better support of DI scenarios, better separation of concerns (e.g. DeliveryEndpointUrlBuilder should not know anything about where its settings come from) and ability to control settings on an application level.

Suggested changes:

• introduce a new class DeliveryOptions with 4 properties (ProductionEndpoint, PreviewEndpoint, ProjectId, PreviewApiKey) - the first two will have their default values set (similarly to MyOptions)

• DeliveryEndpointUrlBuilder

  • will have a new constructor accepting IOptions<DeliveryOptions> options
  • will internally use the IOptions<DeliveryOptions> object
  • the old constructors should construct the IOptions<DeliveryOptions> object as well
  • DeliveryClient will use the new constructor with IOptions<DeliveryOptions> object to construct the DeliveryEndpointUrlBuilder
  • the constructors should be chained, if possible (:this(...))
  • it will no longer be possible to override ProductionEndpoint and PreviewEndpoint when using the old constructors (shouldn't be a breaking change for anyone)...(it will still be possible by using the new constructor)

• DeliveryClient

  • will have a new constructor accepting IOptions<DeliveryOptions> options
  • will internally use the IOptions<DeliveryOptions> object
  • the old constructors should construct the IOptions<DeliveryOptions> object

• the NET45ConfigurationProvider (#57)

  • will be converted to a class that returns an IOptions<DeliveryOptions> object ( IOptions<DeliveryOptions> a = new OptionsManager<DeliveryOptions>(new List<IConfigureOptions<DeliveryOptions>>()); return a;)
  • this is a breaking change for Kentico who'll have to call this method prior instantiating the DeliveryClient using the new constructor (only in NET45)

• It may be possible to avoid the IOptions wrapper.

• Follow up story: #59
  Resources: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration

Description not initialized

If I do this:

        var item= (await client.GetItemAsync("codename")).Item;

        var model = item.CastTo<Article>();

the Article.TeaserImage[0].Description is not initialized.

Set up automatic creation of GitHub Releases

Motivation

We'd like to avoid going to AppVeyor to publish new NuGet packages.

Design guidelines

• Create and publish nugets based on github releases (tags)
  • 1. Deploy on tag
    • Conditional deployment
  • 2. Publish artifacts to GitHub

Other resources:

• Per-branch settings

• if "%APPVEYOR_REPO_TAG%"=="true" set VERSION=%APPVEYOR_REPO_TAG_NAME%

• Document the release process

Strongly typed models should have all rich_text links resolved

At least I think :)

Right now the value is simply copied.