ukrawyl churches waltin
Jennell Venier
This introductory article explores what it means to create a solution and a project in Visual Studio. A solution is a container to organize one or more related code projects, like a class library project and a corresponding test project.
As an educational exercise to understand the concept of a project, you'll construct a solution and project from scratch. Ordinarily, you'd use Visual Studio project templates to create new projects. You'll also look at the properties of a project and some of the files it can contain, and create a reference from one project to another.
Developing apps in Visual Studio doesn't require solutions and projects. You can just open a folder that contains code and start coding, building, and debugging. For example, a cloned GitHub repo might not contain Visual Studio projects and solutions. For more information, see Develop code in Visual Studio without projects or solutions.
In Visual Studio, a solution isn't an "answer". A solution is simply a container Visual Studio uses to organize one or more related projects. When you open a solution, Visual Studio automatically loads all the projects that the solution contains.
Start your exploration by creating an empty solution. After you get to know Visual Studio, you probably won't create empty solutions often. When you create a new project, Visual Studio automatically creates a solution for the project unless a solution is already open.
If you have several workloads installed, the Blank Solution template might not appear at the top of your list of search results. Try scrolling to the Other results based on your search section of the list. It should appear there.
A solution appears in Solution Explorer on the right-hand side of the Visual Studio window. You'll probably use Solution Explorer often, to browse the contents of your projects.
If you have several workloads installed, the Blank Solution template might not appear at the top of your list of search results. Try scrolling through Other results based on your search to find the template.
The QuickSolution solution appears in Solution Explorer on the right side of the Visual Studio window. You'll use Solution Explorer often to browse the contents of your projects.
If you don't see the Empty Project (.NET Framework) template, you must install the .NET desktop development Visual Studio workload. Visual Studio uses workload-based installation to install only the components you need for the type of development you do.
An easy way to install a new workload when you're creating a new project is to select the Install more tools and features link under the text that says Not finding what you're looking for?. After Visual Studio Installer launches, select the .NET desktop development workload and then the Modify button.
Visual Studio uses workload-based installation to install only the components you need for the type of development you do. If you don't see the Empty Project (.NET Framework) template, you need to install the .NET desktop development Visual Studio workload.
An easy way to install a new workload when you're creating a new project is to select the Install more tools and features link under the text that says Not finding what you're looking for?. In the Visual Studio Installer, select the .NET desktop development workload, and then select Modify.
Visual Studio adds a file named Calendar.cs to the project. The .cs on the end is the file extension for C# code files. The Calendar.cs file appears in the Solution Explorer visual project hierarchy, and the file opens in the editor.
You don't need to understand everything the code is doing yet. Run the app by pressing Ctrl+F5, and see that the app prints today's date to the console, or standard output, window. Then, close the console window.
Solutions commonly contain more than one project, and these projects often reference each other. Some projects in a solution might be class libraries, some might be executable applications, and some might be unit test projects or websites.
Starting in Visual Studio 2019 version 16.9, the MSTest project template name changed from MSTest Unit Test Project (.NET Core) to Unit Test Project. Several steps in the project creation changed in this update.
You'll use the new unit test project to test your method in the QuickDate project, so you need to add a reference to QuickDate to the QuickTest project. Adding the reference creates a build dependency between the two projects, meaning that when you build the solution, QuickDate builds before QuickTest.
The line in the Calendar.cs file that contains the InternalsVisibleToAttribute attribute references the assembly name or file name of the QuickTest project. The assembly name might not always be the same as the project name. To find the assembly name of a project, use the project properties. The property pages contain various settings for the project.
A request that we frequently heard was for the project properties to match theming with the rest of Visual Studio. The previous project properties UI was outdated and did not match the more modern look of the rest of the editor.
The last time we updated the look of the project properties UI was before you had the ability to change the Visual Studio theme! Because of this, an obvious flaw of the old UI was the lack of appropriate theming to match the rest of Visual Studio. The good news is that with the new Project Properties, you can use dark mode in peace! The new project properties will match the theming that you have chosen for the IDE without distracting bright UI elements unexpectedly popping up during your workflow.
This side-by-side comparison shows the old project properties dialog on the left and the new one on the right, both with Visual Studio in dark mode. As you can see, the new UI is much easier on the eye and reacts appropriately to changes in the Visual Studio theme.
Another highly requested feature, one that will make life easier for new and experienced developers alike, is the search function in the project properties. Just search for any property or value and your search term will be highlighted in the UI and you will be able to locate and edit the field immediately.
Previously you would have to sift through the various tabs in the properties dialog to find the property you were looking for. Search now simplifies this process. The ability to search for a specific property allows for clean new UI which seamlessly scrolls between tabs so that you no longer need to open multiple windows and switch from tab to tab to locate a property field.
As before, property changes also automatically save to the project file when your code is run, so there is no need to hit a save button before leaving the page. This way, complex property changes will not be lost if you navigate away prematurely.
In this new update we have streamlined the project properties to be property-centric and distilled the UI down to its essential components. As a part of this effort, the launch profiles editor been moved to its own UI where it will be easier for you to manage many profiles at once.
The new project properties UI also displays evaluated property values. Properties for which there is an evaluated value will show the evaluation underneath in shadow text, differentiating it from the property labels surrounding it.
This change makes it much easier to understand evaluated values without having to spend time debugging or unnecessarily jumping through code. We have done our best to enable you to fix issues quickly by making all the information you will need available and simple to discover in the project properties UI.
To support this complexity, we have made it much easier to keep track of these configurations and see how properties vary. Previously you would have to toggle configurations in the drop-down list and monitor for values that changed. This made it difficult to tell if a given configuration applied to all conditions or just one without going through all of them manually.
Now if you want to have separate configurations for debug or release builds, for example, you no longer must change them in separate windows and toggle between the conditions to view the setting for each conditional configuration. For properties for which this type of configuration is possible, such as in the screenshot below, hovering over the little gear icon in the top left corner gives the option to vary the value by configuration. Selecting this option will add fields where you will be able to edit the property value for each configuration, in this case, for both debug and release builds.
Our new UI enables you to see if there are conditional configurations with just a glance at the project properties. It is also much clearer what the value is for a given configuration. You may continue to add conditions directly in the code itself, which will be reflected in the UI after saving.
One of the things we are most excited about is that our new data-driven UI will allow us to add value to our customers faster and react more quickly to changes in the platform. Now we will be able to easily ship new updates and react more swiftly to customer feedback.
This looks very promising, good work! Will this be made available for C++ as well, or is it C# exclusive?
Especially messing with conditional compilation and other per-configuration settings is even more important in C++ projects.
Hi cs. The easiest way to share properties between multiple projects is to use a Directory.Build.props file. Doing so allows you to specify a set of properties once and have them picked up by multiple projects automatically, which is much easier than manually copying settings and trying to keep them in sync over time. You can read more about that here:
c01484d022