Open topic with navigation
This topic includes the following sections:
When developing Synergy applications and libraries in Visual Studio, you can set environment variables that will be used by Visual Studio development tools (e.g., IntelliSense and MSBuild) and at runtime. Note, however, that environment variable settings are not used at runtime for Synergy .NET applications on devices (UWP), except when set with the SETLOG routine or translated with the GETLOG routine. (With any type of Synergy .NET application, including device and Linux applications, SETLOG and GETLOG can be used for internal program communication and for opening files.)
The location of an environment variable setting determines what it is used for.
Scope for development tools (including builds)
|synergy.ini/synuser.ini (Windows only)||n/a (settings remain in synergy.ini or synuser.ini)||All Synergy projectsa||All Synergy applications in the current processb|
|Project file (.synproj)||Project-specific (with some exceptions; see Environment bleed in Visual Studio below)||Not available|
|Common properties file (.props)||All projects in a solution that use the common properties file (with some exceptions; see Environment bleed in Visual Studio below)||Not available|
Debug page, Project Designer (.NET Core and .NET Standard only)
|App.Config / Runtime Settings page of Project Designer (Synergy .NET only)
See Runtime Settings page, Project Designer (Synergy .NET) for more information.
(renamed to ApplicationName.exe.config when the project is built)
|Not available||Application-wide for Windows desktop/server systems (.NET Framework and .NET Core). Not available for other platformsc|
a. If an environment variable is used for builds, it is generally better to set it on the Environment Variables page or the Common Properties page of Project Designer than in synergy.ini or synuser.ini.
c. If an environment variable is shared by multiple Synergy .NET executables, we recommend setting it in one shared synergy.ini file and then setting the SFWINIPATH environment variable in the application configuration (App.Config) files to point to the synergy.ini file.
If an environment variable is set in more than one location, the setting used depends on location precedence and whether the Synergy runtime is involved (see Precedence for environment variables and references below).
The Synergy tab of the Reference Manager dialog makes it easy to add references to ELBs and OLBs in a location specified by an environment variable.
For an ELB project, if you specify an environment variable in the “Output path” field on the Build page of Project Designer, that field will be used for any project references to the ELB project.
See Referencing ELBs and OLBs for more information on environment variables and ELBs and OLBs.
If an environment variable is set in more than one location, the location and whether the Synergy runtime is involved determines which setting is used.
Whenever the Synergy runtime is involved (e.g., at runtime or at build time for a Synergy/DE Repository project), the order of precedence is as follows, with settings higher in the list overriding settings lower in the list:
When using Visual Studio or MSBuild without involving the Synergy Runtime, the order of precedence is as follows, with settings higher in the list overriding settings lower in the list:
An environment variable set on the Environment Variables page is specific to the project it is set in, and an environment variable set on the Common Properties page is specific to projects that use the common properties file it is set in. This is true at runtime and for MSBuild when it is run from the command line. It is also generally true for Visual Studio development tools and builds in Visual Studio, but there are exceptions.
In Visual Studio, an environment variable set on one of these pages becomes part of the solution’s environment in Visual Studio when a project that has the setting is opened or built. At that point, the environment variable setting is no longer specific to a project or set of projects that use a common properties file; it is instead available to all projects in the solution. For example, if MY_ENVVAR is set on the Environment Variables page for a project named ProjectA, that setting will be available to other projects in the solution as soon as ProjectA is opened or built in Visual Studio. This is called “environment bleed” and can cause the following:
You can eliminate environment bleed by using Common Properties to set all environment variables used in your solution and including the common properties file in all projects in the solution.