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. 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 and Configuration.
Let's begin!
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
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 built in.
JavaScript and TypeScript have Prettier, which I like to joke is the tool you can hate so you don't hate your teammates. They also have TSLint and ESLint, 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 (brought to us via 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 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 or the Roslyn repository.
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 (for Visual Studio) and OmniSharp (for VS Code) to guarantee formatting is always applied ๐.
Solution Folders
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
As the number of projects and files in our repository grows, we'll want to come up with new organizational patterns.
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 (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.
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.WebandSandbox.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
\CMSfolder... 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":
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:
Now do the same two steps for the other project.
The IIS Express tray icon should show 2 applications:
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":
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:
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.exeprocesses 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 for consistent linting and formatting
- Using 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 ๐!
We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!
If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:
Or my Kentico blog series:
Top comments (0)