---
title: "Layout and site requirements for ASP.NET Core rendering"
slug: "layout-and-site-requirements-for-asp-net-core-rendering"
abstract: "Overview of site and layout requirements for site definitions, Experience Editor support, JSON renderings, and dynamic placeholder keys for ASP.NET Core rendering."
---
# Layout and site requirements for ASP.NET Core rendering

> [!important]
> If you integrated your app before , it's using the legacy ASP.NET Core Rendering SDK, version 22 or earlier. This SDK is no longer receiving updates, so we recommend that you [upgrade to the latest version of the new](https://doc.sitecore.com/xmc/en/developers/asp-net/latest/asp-net-core-sdk/upgrade-from-v22.html) .

When you are building your site and layout structure for the [Sitecore Layout Service](https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/layout-service.html "Layout Service") and ASP.NET Core rendering, there are some important differences from development with [Sitecore MVC](https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/en/mvc-and-renderings.html). Keep these in mind as you structure your site, or restructure existing content for use with ASP.NET Core.

> [!note]
> These differences are familiar to developers who have worked with JSS, especially when using a [Sitecore-first workflow](https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/sitecore-first-development-workflow.html "Sitecore-first development workflow").

## Configuring your site definition

Even though the rendering host is the front door to your site, you still need a configured [site definition](https://doc.sitecore.com/xp/en/developers/103/platform-administration-and-architecture/en/configure-multiple-managed-websites.html) for use with the Layout Service. When configuring a site definition for your ASP.NET Core rendered site:

- Configure the `rootPath` as you would for any Sitecore site.
- Configure the `hostName` or `targetHostName` URL as the external-facing host name of your [Content Delivery (CD) server](https://doc.sitecore.com/xp/en/developers/103/platform-administration-and-architecture/en/content-delivery--cd-.html). This host is used when the Layout Service outputs media library URLs (if you are not using a CDN).
- The site `name` should be configured in your Layout Service Client [default request values](https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/asp-net-core-rendering-engine.html "ASP.NET Core Rendering Engine").

## Configuring for Experience Editor support

To support the Experience Editor, you must configure your Layout, Site Root, and App Configuration appropriately.

## Using JSON renderings

When creating new renderings for use on your ASP.NET Core site, do not use Sitecore MVC rendering types such as Controller rendering or View rendering. Always use a Json Rendering (`/sitecore/templates/Foundation/JavaScript Services/Json Rendering`).

This rendering type is serialized by the Layout Service with the data needed by your ASP.NET Core components for rendering. Important fields on a Json Rendering include:

| Field | Description |
| --- | --- |
| Component Name | This populates the `componentName` property in your Layout Service output. When configuring components in the [Rendering Engine](https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/asp-net-core-rendering-engine.html), this is the name that you map to. |
| Datasource Location | Behaves the same as in Sitecore MVC development. |
| Datasource Template | Behaves the same as in Sitecore MVC development. |
| Always Display Field Editor Button in Experience Editor | Enables a field editor on the component in the Experience Editor, useful for editing of non-inline field types. |
| Field Editor Displayed Fields | Configures the fields for the above field editor (default is all fields). |
| Cacheable (and related) | Configures output caching for the component. See [Implementing Output Caching for the Layout Service](urn:resource:component:766669). |
| Rendering Contents Resolver | Allows specifying a custom serialization configuration / C# class when outputting data for the rendering. See [Creating a rendering with a contents resolver](https://doc.sitecore.com/xp/en/developers/hd/21/sitecore-headless-development/walkthrough--creating-a-model-bound-view-that-renders-a-contents-resolver.html). |
| Layout Service Placeholders | > [!important]<br>> To output the full structured layout of an item, the Layout Service needs to know what placeholders are present on a rendering.<br>> To make these exposed placeholders discoverable, the Layout Service adds this field to the Sitecore rendering definition.<br>> Select any child placeholders which you wish to use in this rendering (e.g. `<sc-placeholder name="child-placeholder"></sc-placeholder>`). |

## Using dynamic placeholder keys

For simplicity, the Layout Service assumes that all placeholders other than root placeholders (usually header, main, footer, etc.) are [dynamic placeholders](https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/en/dynamic-placeholders.html).

This means that in order for components in a page's layout to be output by the Layout Service, they must be addressed using a dynamic placeholder key in the format `{placeholder key}-{rendering unique id}-0`. For example:

```text
/main/accordion-{3A59ED89-58AB-4B51-8F9C-6100453DDFEC}-0

```

This means that using the Content Editor to add renderings to a page is usually impractical.

Instead, open the page in the Experience Editor, which calculates the required key for you. It is also possible to open `__Standard Values` items in the Experience Editor from the **Publish** ribbon.

> [!note]
> The Layout Service does not support indexed dynamic placeholders. The final value in the key is always zero.