Publish configuration 1C on GitHub
The article shows how to prepare the 1C configuration for publication in versioning systems other than the 1C configuration repository. The operation involves the .Net framework and C #, which allows you to accurately distribute the 1C project into folders.
An example of publishing a configuration based on old BSP updates four years ago (from 1.0.7.5 to 1.1.3.1) can be found at https://github.com/elisy/ssl . In the same way, it is theoretically possible to publish configurations to other versioning systems. But, the experience of publishing a large number of changed files in SVN was unsuccessful: the SVN client hung up while viewing the log via Tortoise SVN.
Starting with version 8.3, 1C can upload the configuration as XML files.
This is done through the Configuration - Upload the configuration to the files ... You need to specify the directory and click OK. The configuration will be uploaded to the set of xml, txt, html files.
')
Via the command line, you can upload files with the / DumpConfigToFiles option to the upload directory, where the upload directory is the directory to which the configuration will be uploaded.
At this point, it would be possible to finish preparing the configuration for publication, but one problem arises. All configuration files will be in the same directory. For example, for UT 11.0.7 files there will be about 10,000 (ten thousand) approximately 430 MB in size. It would be more convenient to have these files distributed in directories, where each folder is responsible for files of the same type.
Expanding files into directories will help a specially written program. In this case, on C #.
The essence of placing files on directories is as follows: on the basis of the file name, decomposed with a “dot” separator, its full path with the same extension is obtained. So the first word to the dot defines the object type directory, the next word defines the object name directory inside the type. And so on - every word after a point - a new directory.
There are exceptions: forms, layouts and help. In addition, xml is transferred to the directory with the definition of a form / layout or help from the parent directory. Subsystems are distinguished by the fact that within subsystems there are definitions of subordinate subsystems. Files beginning with “Configuration.” Are placed in the root.
The code for obtaining the relative path is as follows:
Copying a file is followed by checking for the presence of the directory where it is copied (if there is no directory, it is created) and checking the presence of the final file (if there is a file, it is deleted before copying).
After registering on GitHub, you need to create a repository. In this case, the repository is called ssl.
To synchronize the local directory with the GitHub site, you need to download the Windows client from the github.com website. After installing the application, the GitHub.exe file is launched.
Through the settings (plus the top left of the application), the local directory must be associated with the repository. After that, the running GitHub.exe client will start tracking changes in the directory automatically. Will give the added or changed files.
Sending changes to the server or receiving modified files is performed via the Sync command - the button on the top right of the application.
There were examples of publishing configurations unloaded from cf files in the history. But the presentation of files in the internal format of 1C does not have clarity. The XML format seems to be more attractive, the unloading in which appeared only in 1C 8.3.
The experience of publishing configuration on GitHub has added another powerful tool to the arsenal of 1C tools. The advantages of GitHub compared to the 1C configuration store are obvious: branching, built-in bugtracker, the ability to revise and discuss code, fix code in the browser, reports and graphics, open API.
Despite the seeming attractiveness, only the practice of work will be able to prove the viability of the technique. Storage 1C, in spite of the criticism, somehow works for years. What difficulties the transition to other versioning systems hides can only be guessed at. It may be inconvenient in versions to track changes in XML files due to the specifics of this format ( see layout ).
An example of publishing a configuration based on old BSP updates four years ago (from 1.0.7.5 to 1.1.3.1) can be found at https://github.com/elisy/ssl . In the same way, it is theoretically possible to publish configurations to other versioning systems. But, the experience of publishing a large number of changed files in SVN was unsuccessful: the SVN client hung up while viewing the log via Tortoise SVN.
Stage 1: Uploading 1C 8.3 Configuration to XML Files
Starting with version 8.3, 1C can upload the configuration as XML files.
This is done through the Configuration - Upload the configuration to the files ... You need to specify the directory and click OK. The configuration will be uploaded to the set of xml, txt, html files.
')
Via the command line, you can upload files with the / DumpConfigToFiles option to the upload directory, where the upload directory is the directory to which the configuration will be uploaded.
At this point, it would be possible to finish preparing the configuration for publication, but one problem arises. All configuration files will be in the same directory. For example, for UT 11.0.7 files there will be about 10,000 (ten thousand) approximately 430 MB in size. It would be more convenient to have these files distributed in directories, where each folder is responsible for files of the same type.
Expanding files into directories will help a specially written program. In this case, on C #.
Stage 2: Distribute XML Files to Folders
The essence of placing files on directories is as follows: on the basis of the file name, decomposed with a “dot” separator, its full path with the same extension is obtained. So the first word to the dot defines the object type directory, the next word defines the object name directory inside the type. And so on - every word after a point - a new directory.
There are exceptions: forms, layouts and help. In addition, xml is transferred to the directory with the definition of a form / layout or help from the parent directory. Subsystems are distinguished by the fact that within subsystems there are definitions of subordinate subsystems. Files beginning with “Configuration.” Are placed in the root.
The code for obtaining the relative path is as follows:
private string GetRelativePath(string id) { var nameParts = Path.GetFileNameWithoutExtension(id).Split('.'); string newPath = id; if (String.Compare(nameParts[0], "Configuration", true) == 0) //Configuration.ManagedApplicationModule.txt newPath = id; else if (nameParts.Length == 2) //AccumulationRegister..xml newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[1] + Path.GetExtension(id)); else if (nameParts.Length == 4 && String.Compare(nameParts[0], "CommonPicture", true) == 0 && String.Compare(nameParts[2], "Picture", true) == 0 && String.Compare(nameParts[3], "Picture", true) == 0) { //CommonPicture.BCG.Picture.Picture.png newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[3] + Path.GetExtension(id)); } else if (nameParts.Length == 4 && String.Compare(nameParts[0], "CommonForm", true) == 0 && String.Compare(nameParts[2], "form", true) == 0 && String.Compare(nameParts[3], "module", true) == 0) { //CommonForm.Offline.Form.Module.txt newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[3] + Path.GetExtension(id)); } else if (nameParts.Length == 4 && String.Compare(nameParts[2], "form", true) == 0) { //AccumulationRegister..Form..xml newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[2], nameParts[3], nameParts[3] + Path.GetExtension(id)); } else if (nameParts.Length == 6 && String.Compare(nameParts[4], "form", true) == 0 && String.Compare(nameParts[5], "module", true) == 0) { //Catalog..Form..Form.Module.txt newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[2], nameParts[3], nameParts[5] + Path.GetExtension(id)); } else if (nameParts.Length == 4 && String.Compare(nameParts[2], "template", true) == 0) { //Catalog..Template..xml newPath = Path.Combine(nameParts[0], nameParts[1], nameParts[2], nameParts[3], nameParts[3] + Path.GetExtension(id)); } else if (String.Compare(nameParts[nameParts.Length - 1], "help", true) == 0) { //AccumulationRegister..Help.xml //SettingsStorage..Form..Help.xml //Subsystem..Subsystem..Help.xml List<string> pathParts = new List<string>(); pathParts.AddRange(nameParts.Take(nameParts.Length)); pathParts.Add(nameParts[nameParts.Length - 1] + Path.GetExtension(id)); newPath = Path.Combine(pathParts.ToArray()); } else if (nameParts.Length > 3 && String.Compare(nameParts[nameParts.Length - 2], "Subsystem", true) == 0) { //Subsystem..Subsystem..xml List<string> pathParts = new List<string>(); pathParts.AddRange(nameParts.Take(nameParts.Length)); pathParts.Add(nameParts[nameParts.Length - 1] + Path.GetExtension(id)); newPath = Path.Combine(pathParts.ToArray()); } else if (nameParts.Length > 2) { List<string> pathParts = new List<string>(); pathParts.AddRange(nameParts.Take(nameParts.Length - 1)); pathParts.Add(nameParts[nameParts.Length - 1] + Path.GetExtension(id)); newPath = Path.Combine(pathParts.ToArray()); } return newPath; } Copying a file is followed by checking for the presence of the directory where it is copied (if there is no directory, it is created) and checking the presence of the final file (if there is a file, it is deleted before copying).
string fullPath = Path.Combine(destinationDirectory, file.Path); if (File.Exists(fullPath)) File.Delete(fullPath); string fullPathDirectory = Path.GetDirectoryName(fullPath); if (!Directory.Exists(fullPathDirectory)) Directory.CreateDirectory(fullPathDirectory); File.Copy(Path.Combine(sourceDirectory, file.Id), fullPath); Stage 3: Posting on GitHub
After registering on GitHub, you need to create a repository. In this case, the repository is called ssl.
To synchronize the local directory with the GitHub site, you need to download the Windows client from the github.com website. After installing the application, the GitHub.exe file is launched.
Through the settings (plus the top left of the application), the local directory must be associated with the repository. After that, the running GitHub.exe client will start tracking changes in the directory automatically. Will give the added or changed files.
Sending changes to the server or receiving modified files is performed via the Sync command - the button on the top right of the application.
findings
There were examples of publishing configurations unloaded from cf files in the history. But the presentation of files in the internal format of 1C does not have clarity. The XML format seems to be more attractive, the unloading in which appeared only in 1C 8.3.
The experience of publishing configuration on GitHub has added another powerful tool to the arsenal of 1C tools. The advantages of GitHub compared to the 1C configuration store are obvious: branching, built-in bugtracker, the ability to revise and discuss code, fix code in the browser, reports and graphics, open API.
Despite the seeming attractiveness, only the practice of work will be able to prove the viability of the technique. Storage 1C, in spite of the criticism, somehow works for years. What difficulties the transition to other versioning systems hides can only be guessed at. It may be inconvenient in versions to track changes in XML files due to the specifics of this format ( see layout ).
Source: https://habr.com/ru/post/248303/
All Articles