Configuring project and build options

Before we can get stuck into writing some code, we need to set up some parameters. Many settings described here are good for all projects, but some you may wish to change, depending on the scenario.

Getting ready

This follows the previous recipe, but can apply equally to any Operations project. Just load up Visual Studio and the project you wish to configure.

How to do it...

This will be split into two parts: generic options for all projects, Operations options; and project specific parameters.

Before we do either, we should always have the Application Explorer open, which is hidden by default. This is the Application Object Tree (AOT) of prior versions. This is opened from the View menu.

Dynamics 365 for Operations' options

To configure the generic options for all projects, follow these steps:

1. Select Options from the Dynamics 365 menu.

Note

The form is actually the Visual Studio options dialog, but it takes you to the section specific to Operations.

 

2. The default option in the left-hand tree view is Debugging; the options here are usually fine. The Load symbols only for items in this solution option affects debugging and should be left checked for performance of the debugger. We would uncheck this if we want to trace code that calls code outside of the current package.
3. Select the Projects option on the left and check Organize projects by element type. When adding new elements to the project, it will automatically create a sub folder in the project for the element type. This makes organization much easier to maintain.
4. The other two options should be left blank. Although the Synchronize database on build for newly created project option can be useful, this database synchronization takes time, and it is usually preferable to do this as required. That is, before you run it.
5. The Best practices node lets you choose which best practice checks you wish to be executed on build. This detail is beyond the scope of this book as the checks required are case specific.

The project-specific parameters

These are usually fine as default for development, but we often want to test our code using the sample data that comes with the virtual machine.

To set up the common parameters, follow these steps:

1. Right-click on the project in Solution Explorer and choose Properties.
2. To save time whilst debugging, you select which object you wish to start with. To start with the form SalesTable, set the Startup Object Type option to Form, and Startup Object to SalesTable.
3. Set Company to USMF or any other company you wish to start with when debugging.
4. Leave Partition as initial. These are now only supported for certain unit test scenarios.
5. If you wish to always synchronize the database on build, you can set Synchronize Database on Build. My advice is to do this manually, as required after the build completes.

There's more...

You may notice that we can change the Model in the project's parameters. Our advice is, don't do it. To change the project's Model also means that the folders have to be moved in the local packages folder.