Lead with an Executable Project

The first project in the solution file should be an executable project since Visual Studio chooses this project as its default startup project.

Each time a project is added to a solution through Visual Studio, a reference to that project is added to the sln file. Visual Studio adds each new reference to the end of the list of existing references. The first project reference in this list is slightly special. If no project has been explicitly selected as the startup project, then Visual Studio selects the first project referenced in the sln to be the startup project.

linkUses for executable projects

The main reason for a codebase to contain an executable project is because the codebase contains application code, which means the primary artifact is an executable. In contrast, the primary artifact of library code is a package that is added as a dependency in other programming projects. For .NET code, these packages are called NuGet packages.

Even so, I often find executable projects in a repository that mostly contain library code. One example is a project that executes benchmarking tests. Another example is a project that demonstrates how the library code should be used.

I have seen automated test projects that are executable. Here is one example. However, such projects are not intended to be executed by setting them as the startup project and then starting them through Visual Studio via the start button. For this post, I am ignoring these types of projects. There is no use in making them the startup project.

linkNo startup project selected

Why would there be no record of an explicit selection for the startup project? I know of three reasons.

For a sln file named SolutionName.sln, Visual Studio (version 16.6.2) persists a reference to the startup project in the binary file .vs\SolutionName\v16\.suo. This .vs directory is created in the same directory as the sln file. Most gitignore files include an entry to ignore the .vs directory.

Having no project explicitly selected as the startup project is typically equivalent to the .vs directory not existing. Now let's get to those three reasons.

link1. No executable project

There is no reason to explicitly select a startup project if a solution doesn't contain an executable project. For this post, I am also ignoring such solutions. For them, the order of the projects in the sln file doesn't matter.

link2. git clone

The .vs directory won't exist after a repository is cloned. This is my experience every time I clone the repository of a new open-source project. In rare cases, I also experience this after my .git directory becomes corrupted and I reclone to fix the problem.

link3. git clean

The .vs directory won't exist after executing git clean -fdx, which deletes all untracked files. I often execute this command in order to increase the precision of my changes when modifying how a solution is built.

linkError message

I consider it a small mistake whenever I try to start a project that cannot be started. Visual Studio informs me of my mistake with this error message.

Microsoft Visual Studio

A project with an Output Type of Class Library cannot be started directly.

In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project.

Error message in Visual Studio when trying to start a class library

I never want to see this error message.

linkMaking it so

When I learned about this behavior of Visual Studio, I moved the primary executable project in my application at work to the beginning of the list of projects in the sln file. I am a co-maintainer of the open-source project Elmish.WPF. We have many samples, and I made our simplest sample the default startup project in this commit.

Then as writing this post, I wanted to make sure I was practicing what I preached. I found two sln files in other open-source projects that could benefit from this change. Pull requests for SkiaSharp and F# Hedgehog soon followed.

linkSummary

The development experience is improved by having the list of projects begin with an executable project. It is a simple and quick change to make if it is not already that way. I encourage everyone to go find a sln file that doesn't list an executable project first and then make it so. In a technical sense, the world will be a better (more efficient) place.


linkTags

The tags feature of Coding Blog Plugin is still being developed. Eventually the tags will link somewhere.

#DevOps #Visual_Studio

linkComments

Uses for executable projectsNo startup project selected1. No executable project2. git clone3. git cleanError messageMaking it soSummaryTagsComments

Home About Archive