Synergy files, projects, and solutions
This topic includes the following sections:
When you develop with Visual Studio, Synergy DBL code files are contained in Synergy projects, and projects are contained in Visual Studio solutions.
- Projects collect all files, settings (compiler settings, environment variables, etc.), data connections, and references needed to build a Synergy program or library. Projects supply this information to the Visual Studio build system (MSBuild) at build time, and they enable Visual Studio’s IntelliSense features to work for Synergy DBL files. (For more information on IntelliSense, see IntelliSense for Synergy files.)
- Solutions collect related projects and enable you to work with these collected projects as a whole. For example, projects in a solution can generally be built together (and they can be built separately).
In general, you will create a Visual Studio project for each program and library that is part of your application, and you will put all projects for an application in a single solution. There are many types of Synergy projects you can create. Some are for traditional Synergy; others are for Synergy .NET. See Synergy/DE project templates for more information.
Visual Studio solutions, however, are not language specific. A Visual Studio solution can contain a mix of Synergy and non-Synergy projects, it can contain a mix of traditional Synergy and Synergy .NET projects, and projects in a solution can share resources. For example, if you use the same core code for a traditional Synergy application and a Synergy .NET application, you can create a solution with a traditional Synergy project and a Synergy .NET project that share that code, as illustrated in figure 1 below.
1. Different projects can share source files.
However, Synergy .NET projects cannot reference traditional Synergy projects and libraries, and vice versa. (Although routines accessed via xfServerPlus can be converted for native .NET access. See Preparing Existing Code for Synergy .NET.) So if you have a solution with both traditional Synergy and Synergy .NET projects, you can build the projects together, but you probably won’t be able to deploy them as a single application.
For more information on Synergy .NET projects and how they relate to .NET assemblies, see Using Projects with Synergy .NET.
Project files, folders, and builds
Each Synergy project consists of a project folder, a project file (or files), and other associated files and subfolders. Synergy projects have a fairly standard set of files and folders, so see Visual Studio documentation for general information on projects. There are, however, a few differences:
- Synergy project files (.synproj and .synproj.user) are similar to project files for other languages (e.g., C#), but they do contain different settings (XML tags). These settings are undocumented because they are controlled by options in the Visual Studio interface. (For an exception to this rule, see Setting link priority for traditional Synergy in Visual Studio.)
- All project files, except .synproj.user files (which store machine-specific settings), should be included in source control.
- By default, files with the .dbl or .dbc extension are compilable files, and files with the. def or .rec extension are content files. See File types and build actions for more information.
- Strong prototyping is used automatically when developing in Visual Studio, so prototype files (.dbp), which are unique to Synergy, are generated and used behind the scenes by Visual Studio and SDI.
A project can be built to run as a 32-bit application or a 64-bit application, it can be built in debug or release mode, and it can be built to target an earlier version of Synergy/DE. (See Customizing Visual Studio behavior for Synergy projects below.) When you build a project, Visual Studio automatically runs a Synergy compiler (and linker for traditional Synergy) behind the scenes to generate program and library files. These are ELBs and DBRs for traditional Synergy, or .exe and .dll files for Synergy .NET.
If you build in debug mode, the compiled program will include symbol information for debugging. (Synergy .NET files built in debug mode reference .pdb files, which have symbolic debug information. For information on .pdb files, see Visual Studio documentation.) Note the following:
- .INCLUDEd files must not be compilable files—i.e., they must have build actions other than Compile. See File types and build actions.
- Visual Studio projects are not designed to work over network shares, so keep all files for Visual Studio projects local. This includes repository and .INCLUDE files.
- For Synergy DBL files, Visual Studio’s IntelliSense feature works only in Synergy projects, and all project files must be local. See IntelliSense for Synergy files for more information on IntelliSense requirements.
- Visual Studio cannot open unencoded (plain text) files with ASCII escape sequences. Attempting to open an unencoded file in Visual Studio will either cause Windows to prompt you for an application to use with the file (e.g., “How do you want to open this file?”) or, if there is a default application associated with the file extension, it will open the file in that application.
- You may be able to improve Visual Studio’s performance for large source files when editing or using Find All References by clearing the “Auto-detect UTF‑8 encoding without signature” option on the General options dialog box (Tools > Options > Text Editor > General).
- The RUNTIME_TARGET define is set at compile time to the runtime compatibility setting for a program. This enables you to programmatically exclude runtime features that are not available in the version you target.
- For information on improving performance by excluding SDI files and file locations from virus scanning, see www.synergex.com/synergy-dbl-integration.
Customizing Visual Studio behavior for Synergy projects
You can customize many aspects of Visual Studio’s behavior for Synergy projects. You can control
- the behavior of IntelliSense and the Visual Studio code editor. For example, you can control the way tabs work and the way indentation is applied in code blocks. See Options for Synergy/DE projects for more information.
- settings that determine which Synergy version IntelliSense will be limited to. This can be useful, for example, if you have the latest version of Synergy on your development machine, while other members of your development team use older versions. If you set the “IntelliSense language version” option (on the Build page of Project Designer) to the lowest common Synergy version for your team, IntelliSense will limit completions, listings, etc., to features that were available in that version. This helps you avoid creating code that won’t work with other development team members’ systems. See Build page, Project Designer for more information.
- settings that determine how the project is built. This includes settings for platform target (x86, x64, or Any CPU), Synergy runtime target, debugging, and the compiler. For example, we recommend that you develop with the most recent version of Synergy/DE and SDI. If production machines use an earlier version, set the “Synergy runtime target” option (on the Build page of Project Designer) to the version of Synergy running on the production machines. See Build page, Project Designer for more information.
File types and build actions
There are also settings that control how different file types (files with different extensions) are treated in Synergy projects. By default, Visual Studio treats Synergy project files with the .dbl and .dbc extensions as compilable files, and it treats Synergy project files with the .def or .rec extension as content (non-compilable) files. You can customize this by
- adding file extensions to the “Additional Compile File Extensions” and “Additional Content File Extensions” fields in the IntelliSense dialog box for the Synergy DBL text editor. See IntelliSense, text editor options for more information.
- changing the Build Action for an individual file (e.g., right-click the file in Solution Explorer and select Properties from the context menu) as illustrated in figure 2 below.
You can set Build Action for a file in a Synergy project to one of the following. Files with unrecognized extensions default to None.
- Compile. The file is compiled and added to the build output.
- Content. The file is copied to the project output (without being processed).
- Embedded Resource. The file is processed by a specified tool and the results are embedded in a manifest resource exclusive to the assembly. This setting is ignored for traditional Synergy projects.
- None. The file is ignored by the build. It is not processed or included in the project output.
- Page. The file is compiled as XAML and is embedded in a shared assembly manifest resource. This setting is for WPF projects only. It is ignored for all others.
- Resource. The file is added as a linked resource (.resx). This setting is for WPF projects only. It is ignored for all others.
- ApplicationDefinition. The file (which must be a XAML or class file) is used to define the application. This setting is for WPF projects only. It is ignored for all others
2. Changing the Build Action for a specific source file in a project.
Using the Error List in Visual Studio
If the Error List in Visual Studio (View > Error List) displays a lot of errors, keep in mind that you can filter this list so that it is limited to the current project, the current document in the editor, or all documents open in the editor. (The Current Project filter is often very helpful.)
You can also use the search feature to find specific words or phrases in the Error List, and you can filter out errors, warnings, or messages.
To clear only Synergy-related errors and warnings from the Error List, select Tools > Clear Error List from the Visual Studio menu.