Kentico 12: Design Patterns Part 22 - Improving Our Projects for Developer Experience
Tags: kentico, dotnet, mvc, cms
Published: 2020-05-06 14:21:31

---
title: Kentico 12: Design Patterns Part 22 - Improving Our Projects for Developer Experience
published: true
description: Learn how to improve the Developer Experience in your Kentico 12 MVC projects.
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/0r9003gzp4g3vp9bnbc5.jpg
tags: kentico, dotnet, mvc, cms
series: Kentico 12 - Design Patterns
---

## Laying A Foundation

I've recently had some conversations with other developers about setting up and configuring projects.

I work 👷‍♂️ for a web development and marketing agency, [WiredViews](https://www.wiredviews.com/). Working for an agency involves a constant stream of greenfield projects, which means I've had lots of experience "starting" things.

Below I'd like to cover some recommendations for setting up a Kentico 12 MVC project and what benefits these bring.

This is going to be a 3-part post. In this post we're going to look at Developer Experience.

> The next 2 parts will cover [Documentation](https://dev.to/seangwright/kentico-12-design-patterns-part-23-improving-our-projects-with-documentation-pfp) and Configuration.

Let's begin!

![Cat typing like a champ](https://media.giphy.com/media/uzglgIsyY1Cgg/giphy.gif)

---

# Developer Experience

Developer Experience is made up of all the little things in a code base that either make development a breeze 🏖 or wear us down over the course of a project 😩. If Developer Experience is bad, it's like walking on sharp stones, but if it's good, we are more efficient and focused on doing our best work 💪🏾.

Improving Developer Experience can be owned by anyone on a team - it's usually too small to make a separate task, but big enough to annoy if it's not taken care of.

## Editorconfig

![EditorConfig logo](https://dev-to-uploads.s3.amazonaws.com/i/lqj7fw9r5weitcqudvwl.jpg)

I'm a big fan of not having to worry about formatting and syntactical conventions when coding.

Languages, like Go, having [code formatting and linting](https://www.golangprograms.com/code-formatting-and-naming-conventions-in-golang.html) built in.

JavaScript and TypeScript have [Prettier](https://prettier.io/), which I like to joke is the tool you can hate so you don't hate your teammates. They also have [TSLint](https://palantir.github.io/tslint/) and [ESLint](https://eslint.org/), both of which have highly configurable rule systems.

C# and .NET don't have anything quite as integrated or opinionated 😕, but we do have modern tooling to support formatting and conventions 👍🏽.

These days, Visual Studio and VS Code both support formatting rules defined by [EditorConfig](https://editorconfig.org/) (brought to us via [Roslyn](https://github.com/dotnet/roslyn), the C# compiler-as-a-service).

> EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

We can find a [full set of configurable rules](https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference?view=vs-2019) in Microsoft's documentation.

If you're unsure about what options to pick, it wouldn't be a bad choice to go with the configuration for the [.NET Core runtime repository](https://github.com/dotnet/runtime/blob/master/.editorconfig) or the [Roslyn repository](https://github.com/dotnet/roslyn/blob/master/.editorconfig).

The best time to establish these types of conventions is at the beginning ⌚ of a project, both to help avoid massive changes in our Git history from re-formatting, and to not annoy other developers when they find out the way they've been formatting for 3 months is "the wrong way" 😒.

Add an `.editorconfig` file to the root of your project on day 1 and use extensions like [Code Cleanup On Save](https://marketplace.visualstudio.com/items?itemName=MadsKristensen.CodeCleanupOnSave) (for Visual Studio) and [OmniSharp](https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp) (for VS Code) to guarantee formatting is always applied 😎.

## Solution Folders

![Mutiple solution folders in Visual Studio containing projects and miscellaneous files](https://dev-to-uploads.s3.amazonaws.com/i/9wg3n0ets00f280n4t2z.jpg)

When building a Kentico Portal Engine application, we could sometimes get away with the CMS being the only .NET ASP.NET project in a solution.

However, now with Kentico 12 MVC, we will have at least 2. If we want to share code between the Content Management (CMS Web Forms application) and Content Delivery (MVC 5 application) projects, we'll likely have several more 😮.

> To learn more about structuring a Kentico 12 MVC code base, checkout Kentico 12: Design Patterns Part 20 - Choosing a Solution Architecture

> {% post seangwright/kentico-12-design-patterns-part-20-choosing-a-solution-architecture-4jpb %}

As the number of projects and files in our repository grows, we'll want to come up with new organizational patterns.

[Solution folders](https://www.cathrinewilhelmsen.net/2018/07/30/organizing-visual-studio-projects-solution-folders/) can help us do just that.

In Visual Studio, Solution folders aren't actual folders on the filesystem, instead they are 'virtual' folders that appear in the Solution Explorer.

A common pattern is to create `src` and `tests` folders to separate deployable code from tests.

Maybe we have some console applications or other tools for a project - we could make a `tools` Solution folder and keep these projects and files there.

I typically have a `Solution Items` folder where I put files at the root of the repository that I want to edit in Visual Studio, like documentation, a `.gitignore`, or other configuration files 🤓.

## Solution and Project Names

When we use the [Kentico Installation Manager](https://docs.kentico.com/k12sp/external-utilities/kentico-installation-manager) (KIM) to create a new Kentico 12 MVC codebase, we'll get 2 solution files, `WebApp.sln` and one named after the project name we gave to the KIM.

I dunno about you, but `WebApp.sln` is pretty bland 😝... who knows what could be in there!?

In fact, my recommendation is to name Solutions and Projects to match the project being worked on.

> We likely have a client, department, or stakeholder this project is being built for. Figure out the official "business" project name and use that as a starting place for naming .NET solutions and projects. This will also impact .NET namespaces, and [this is a good thing](https://www.martinfowler.com/bliki/UbiquitousLanguage.html).

For solutions, this can be done either by renaming the `.sln` file directly or renaming the top level Solution node in the Solution Explorer from within Visual Studio.

We can even rename the CMS project! It's traditionally been named `CMSApp`, which comes from the `CMS\CMSApp.csproj` file.

Go ahead and change that to match the name of your project, like `CMSStorefront.Web`.

> I like using the "Content Management" and "Content Delivery" terminology for the CMS and MVC applications respectively 🧐, so I'll fit those into a naming scheme, like `Sandbox.Management.Web` and `Sandbox.Delivery.Web`.

We'll want to update the `<RootNamespace>` and `<AssemblyName>` properties in the `.csproj` to match.

> Note: While we can rename the CMS project, we _cannot_ rename the `\CMS` folder... well, technically you can but it will make applying hotfixes and patches a pain 😤.

## Running and Debugging 2 Apps Simultaneously

As mentioned previously, the KIM (Kentico Installation Manager) provides us with 2 solution files upon the creation of a new Kentico 12 MVC application.

I would recommend deleting 1 and adding the remaining ASP.NET project to the other solution.

Why 🤔?

Well, typically we won't be developing _just_ the Content Delivery or Content Management applications. We'll likely be working on both - adding content to the document tree, creating new page types, and viewing the site to make sure we're querying and rendering data correctly.

Do you want to always have 2 instances of Visual Studio open at the same time 🙄? Ya, neither do I 😉.

Once both of the projects are in the same solution, we can start and run them simultaneously.

Select the first project you want to start by right clicking on the project node in Visual Studio and selecting "Set as Startup Project":

![Project right-click options in Visual Studio](https://dev-to-uploads.s3.amazonaws.com/i/dnqpirrf3f3luy0ftqle.jpg)

Then either use the keyboard shortcut `ctrl+F5` or select the "Start Without Debugging" option from the "Debug" menu at the top of the screen:

![Debugging menu option in Visual Studio](https://dev-to-uploads.s3.amazonaws.com/i/56tbna5molg4wdzzg7ji.jpg)

Now do the same two steps for the other project.

The IIS Express tray icon should show 2 applications:

![IIS Express tray dialog](https://dev-to-uploads.s3.amazonaws.com/i/zerflzuc3122ccepback.jpg)

What about debugging 🙂? We will "attach" to the running IIS Express processes.

We need to get the process id from the IIS Express dialog (right click the tray icon and select "Show All Applications":

![IIS Express application list with URLs and process ids](https://dev-to-uploads.s3.amazonaws.com/i/bc6fajqpqiy837p39w2r.jpg)

Now, return to Visual Studio with this information and either use the keyboard shortcut `ctrl+alt+p` or select from the Debug menu "Attach to Process", after which the process list dialog will appear:

![Visual Studio process list dialog](https://dev-to-uploads.s3.amazonaws.com/i/i58pzm369pk3j9xscmrp.jpg)

Search for the correct IIS Express process (or processes, yes - you can attach to both applications at the same time 🤯!) and then click "Attach".

> We could have also assumed that all `iisexpress.exe` processes are the apps we just started and attached to those 🤷🏾‍♂️.

The great thing about this setup is, we can launch one or both applications from the same Visual Studio instance **and** debug.

If we want to stop debugging, we click the "stop" button, but this is much better than normal debugging, because the **sites are still running** 🥳!

That's right, we can attach and detach as much as we want and we don't have to restart 😁 the sites every time.

Also, there's a nice keyboard shortcut for re-attaching to the last attached process(es) - `shift+alt+p`, no need to open the process dialog again 😎.

---

## Conclusion

In this post we covered:

- Setting up [EditorConfig](https://editorconfig.org/) for consistent linting and formatting
- Using [Solution Folders](https://www.cathrinewilhelmsen.net/2018/07/30/organizing-visual-studio-projects-solution-folders/) to make organizing our work in Visual Studio easier
- Giving our Solution and Projects better names
- Running both Content Delivery and Content Management applications out of the same solution

Each one of these leads to a better Developer Experience for ourselves and for our team members.

There's lots of other ways we can improve Developer Experience on a project, and I'd love to hear your ideas, so leave a comment below if you have suggestions.

As always, thanks for reading 🙏!

---

<figcaption>Photo by <a href="https://unsplash.com/@furbee">Oscar Nord
</a> on <a href="https://unsplash.com">Unsplash</a></figcaption>

---

We've put together a list over on [Kentico's GitHub account](https://github.com/Kentico/Home/blob/master/RESOURCES.md) of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:

{% tag kentico %}

Or my Kentico blog series:

- [Kentico EMS: MVC Widget Experiements](https://dev.to/search?q=kentico%20ems%3A%20mvc%20widget%20experiements)
- [Kentico 12: Design Patterns](https://dev.to/search?q=Kentico%2012%3A%20Design%20Patterns)
- [Kentico CMS Quick Tips](https://dev.to/search?q=Kentico%20CMS%20Quick%20Tip)