This article describes standards that apply to configuration development for Linux. All of the listed recommendations are mandatory unless noted otherwise.
1. In most scenarios you do not need additional development efforts to ensure that your configuration (the client application and the server) can run on Linux. This article contains recommendations for specific scenarios described in the "System behavior in various modes" appendix of 1C:Enterprise Developer Guide.
2. During the implementation of the key applied solution features, use the cross-platform development capabilities available in the 1C:Enterprise platform.
2.1. Instead of Windows COM technology (COMObject object), use the following cross-platform technologies:
- For administering the 1C:Enterprise server cluster, instead of managing the server object model using the v83.ComConnector COM object, use the administration server (ras) and the administration utility (rac).
- For getting directory paths, instead of Windows COM objects, use the following global context methods: UserDataWorkDir, DocumentsDir, and TempFilesDir.
In other scenarios consider using other alternatives to the COM technology, such as the NativeAPI add-in development technology.
2.2. Use the Native API technology for the development of add-ins (both client and server ones) delivered with the configuration. With this technology you can create add-ins for Windows and Linux operating system families, as well as for the web client, which can run in browsers supported by 1C:Enterprise.
An add-in must include executable files (.so) for 32-bit and 64-bit Linux versions. For more information on add-in development, see the "Add-ins" chapter of 1C:Enterprise Developer Guide.
2.3. Instead of using the Mail object, consider the following:
- Use the InternetMail object
- Develop Linux add-ins that support the mail clients available on Linux.
2.4. The appearance of the HTMLDocumentField control might vary depending on the operating system: Windows or Linux. This is because the Linux version of this control is based on the WebKit library, while the Windows version is Internet Explorer-based.
Note that the appearance and the object model of the HTML document (DOM model), which can be accessed using the HTMLDocumentField.Document property, might differ on Linux and in Windows client applications:
- Use only standard DOM model elements that are available in all operation modes.
- Use the web development standards for HTML content generation and do not use browser-specific methods and properties.
because some browsers do not support the SaveAs command (see http://help.dottoro.com/larpvnhw.php).
TempStorageAddress = GetTemplate(...);
2.5. If your configuration includes pictures in WMF or EMF format (Windows metafiles), replace them with raster pictures, such as PNG or JPG.
2.6. Use the cross-platform development capabilities related to the file system operations:
2.6.1. Since the file names in Linux are case-sensitive, use the same case in all file name (or path) usage instances.
2.6.2. Do not specify file path separators and the file mask manually (i.e. "/" or "*.*"). Use the GetPathSeparator and GetAllFilesMask functions instead.
If your configuration includes 1C:Subsystems Library, use the CommonUseClientServer module functions for file name operations.
3. You can disable less important (service) features of your applied solution on Linux. For applied solutions that automates sales, examples of less important features are synchronizaton with other applications using direct connection and importing email from third-party clients.
Implement this by hiding the controls related to these features from the Linux user interface. If there is no way to hide them, ensure that a message like "<Operation> is not available on Linux" is displayed.
Procedure CommandProcessing(CommandParameter, CommandExecutionParameters)
Info = New SystemInfo;
If Info.PlatformType = PlatformType.Linux_x86 Or Info.PlatformType = PlatformType.Linux_x86_64 Then
ShowMessageBox(, NStr("en = 'Cannot print to Microsoft Word on Linux.'"));