About Projects and Solutions

This section explains the concept of projects and solutions in Visual Studio and Atmel Studio.

The term "Project"

A project is a collection of source files (.ino, .cpp, .c and/or .h files) that are compiled into a program that you can upload to your board. The project also contains project properties like the board type or the port name/number for your upload.

The term "Solution"

A solution consists of one or more projects. You can use solutions to aggregate multiple projects that logically belong together. In the picture below, you see a sample solution for a system consisting of two connected boards: One for a client and one for a server, each with its own project.

Projects and Solutions


The following image shows our sample solution. 1 is the solution, 2 and 3 are the projects with their (single) source files server.ino and client.ino.

Solution Explorer Multiple Projects

(To open the Solution Explorer window above, press [Ctrl+Alt+L])

The projects in a solution are completely independent. The main difference from having them in separate solutions is, that you can open them at once in Visual Studio/Atmel Studio.

E.g. you can have different board types and ports for the client and the server project. In this example, you may want to connect the server and the client board to separate USB ports simultaneously.

The Startup Project

From all projects within a solution, exactly one project is the startup project. This is the project whose executable code will be uploaded to the board if you activate the Build & Upload command. If you have debugging enabled, this will also be the Arduino board and project that you are debugging. Building with multiple projects: VM does noit work this way anymore

You can change the startup project by right clicking on the project in Solution Explorer (indicated by the 2 and 3 above) and choosing "Set as Startup Project".

The startup project is shown in bold in the Solution Explorer.

Building and uploading

With multiple projects, you have the following choices for building and/or uploading:

vMicro > Build & Upload
Buld & Uload icon on the Micro Project toolbar.
Builds the current project and uploads the startup project's executable code to the Arduino board.
The current project is the one that contains the highlighted
Build > Build Solution
Builds all projects but does not upload anything
vMicro > Build & Upload
Buld & Uload icon on the Micro Project toolbar.
Builds one of the projects.
If the cursor is in a source file, builds the project this source file belongs to.
If the cursor is in Solution Explorer, builds the project the highlighted line belongs to.

Therefore, this command will not necessarily always build the startup project.

Viewing Into Core and Library code

Warning 16 Note:

The following function is only available with Visual Studio, not with Atmel Studio.

In the Arduino world, libraries and core code exists as source code and, therefore, can be viewed in the editor. As a default, Visual Micro does not show library and core files in the project tree. To make them visible, highlight the project in Solution Explorer and choose vMicro > Toggle Hidden Files from the menu.

There will be two more nodes in the project tree: "_cores" showing all core files and "_libraries" containing core and library source files, respectively.

Project > Show All Sketch Files acts as toggle, so choosing it again will hide core and library files again.

What are libraries?

Read here about libraries.

What is "core"?

"Core" code is the code that Arduino already brings along. Commonly used functions like "digitalWrite" or the "Serial" functions are all in the core code.

Warning 16 Note:

Although it is possible, you should never change core source code.
Reason: Whenever a new version of Arduino and the Arduino IDE will be available, you would have to transfer your changes to the new core version. This might even be impossible: If the Arduino team decides to change the structure of the core code, then your additions and changes won't fit to the new structure and you would have to redo your changes with the new core all over again.

To a limited extent, this is also true for libraries. If you ever plan to switch to a newer version of a library, you should not change the library code, because then you create an own version of your library (a so called "code split") and you exclude yourself from the use of newer version of your library.

Other Pages