Methods, devices, computer equipment, and media for porting secondary development code across products

Abstract

This invention relates to the field of electronic digital data processing technology, and provides a method, apparatus, computer equipment, and medium for cross-product porting of secondary development code. The method includes loading a source project and screening source code files to be ported; identifying the original API type; determining the mapping relationship between the original API type and the target API type; and generating an adaptation layer code framework accordingly. The method also includes copying the source code files to be ported to the target project; replacing call nodes for the original API type with call nodes for the adapter type while maintaining the project hierarchy of the source project; replacing namespace references with the corresponding namespaces in the target project; and obtaining the migrated source code files. Finally, based on the adaptation layer code framework and the migrated source code files, a secondary development project of the target project, based on the API of the second product, is generated. This invention improves the efficiency and accuracy of cross-product secondary development code porting.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to computer code processing based on artificial intelligence, namely a method, apparatus, computer equipment and medium for cross-product portability of secondary development code. Background Technology

[0002] Currently, enterprise software, industrial automation systems, and design platforms widely offer open APIs (Application Programming Interfaces), allowing developers to extend or customize system functions, interfaces, and logic by calling vendor-provided APIs without modifying the underlying system architecture, thereby meeting individual business needs. This type of API-based secondary development has become an important form of software ecosystem construction.

[0003] With the rapid iteration and replacement of products from different vendors, developers often face the need to migrate secondary development functions written based on the API of product A to the API environment of product B. Such cross-product migration usually requires developers to completely replace and refactor the APIs called in the original code to adapt to the API interface of the new product.

[0004] The existing porting methods mainly rely on manual work. The typical process is as follows: First, the code blocks or files related to the function to be ported are identified in the original secondary development project; then, based on understanding the API call logic in various parts of the original project, each call point is manually replaced, and the API of product A called is rewritten to the API of product B; finally, after the porting is completed, the code is recompiled, debugged and the errors are corrected.

[0005] This method of artificial transplantation has the following main problems:

[0006] (1) Manual identification and screening is inefficient. When the project is large in scale and there are many files, developers need to manually determine which files are related to the target function, which is very easy to miss or misselect.

[0007] (2) The code replacement process is tedious and error-prone. Different vendors' APIs have significant differences in system architecture, naming rules and parameter design. Even the same functional interface may have different calling methods. Developers need to replace each API call one by one, which is a lot of work and has a high error rate.

[0008] (3) High learning and understanding costs. The porting personnel must be familiar with the API architecture of both the original vendor and the target vendor in order to correctly replace and adjust, which requires a high level of developer ability.

[0009] (4) Poor reusability and serious duplication of work. When multiple functional modules need to be ported, the results of previous porting are difficult to reuse. Each module needs to repeatedly perform screening, replacement and debugging operations, resulting in low efficiency and high maintenance costs.

[0010] Therefore, existing technologies still mainly rely on manual operation when handling the porting of secondary development code across products. How to improve the efficiency and accuracy of porting has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0011] The purpose of this invention is to provide a method, apparatus, computer equipment, and medium for porting secondary development code across products, in order to solve the aforementioned technical problems in the prior art.

[0012] On the one hand, in order to achieve the above objectives, the present invention provides a method for porting secondary development code across products.

[0013] The method for porting secondary development code across products includes: loading the source project to be ported, wherein the source project is a secondary development project written based on the API of a first product; selecting source code files to be ported from each source code file of the source project; identifying type references belonging to the API of the first product from the source code files to be ported to obtain the original API type; determining the mapping relationship between the original API type and the target API type in the API of a second product; generating an adaptation layer code framework based on the mapping relationship; copying the source code files to be ported to the target project; while maintaining the project hierarchy of the source project, replacing the call nodes for the original API type with call nodes for the adapter type, and replacing the namespace references with the corresponding namespaces in the target project to obtain the migrated source code files; and obtaining a secondary development project of the target project based on the API of the second product according to the adaptation layer code framework and the migrated source code files.

[0014] Further, the step of generating the adaptation layer code framework according to the mapping relationship includes: generating an adapter type for the original API type, wherein the inheritance relationship and member signature of the adapter type are the same as those of the original API type; and binding the internal members of the adapter type to the target API type corresponding to the original API type according to the mapping relationship to obtain the adaptation layer code framework.

[0015] Furthermore, the step of selecting source code files to be ported from each source code file of the source project includes: constructing a syntax tree and a semantic model for each source code file of the source project; and selecting source code files to be ported from each source code file of the source project based on the syntax tree and the semantic model.

[0016] Further, the step of generating an adapter type for the original API type includes: extracting the inheritance relationship and member signature of the original API type based on the syntax tree and the semantic model, wherein the inheritance relationship includes the base type, implemented interfaces, type visibility and type modifiers of the original API type, as well as generic parameters and constraints of the generic parameters, and the member signature includes member names, parameter lists and parameter passing modifiers; and generating the adapter type based on the inheritance relationship and member signature.

[0017] Further, based on the syntax tree and the semantic model, the step of selecting source code files to be ported from each source code file of the source project includes: taking the entry command of the target porting function as the traversal starting point, obtaining the syntax node and semantic symbol corresponding to the entry command; traversing in a breadth-first manner starting from the traversal starting point, and performing the following steps for each accessed type during the traversal process: Step S1: locating the declaration node of the accessed type based on the syntax tree, and determining the source code file where the declaration of the accessed type is located based on the declaration node; Step S2: analyzing the dependency relationship of the accessed type based on the semantic model; Step S3: adding the types obtained based on the dependency relationship that have not yet been traversed to the breadth-first traversal queue; when the breadth-first traversal queue is empty, deduplicating the source code files determined in step S1 to obtain the source code files to be ported.

[0018] Furthermore, after obtaining the original API type and before determining the mapping relationship, the method further includes: obtaining a list to be mapped; determining whether the original API type is in the list to be mapped; when the original API type is not in the list to be mapped, appending the original API type to the list to be mapped, wherein the step of determining the mapping relationship between the original API type and the target API type in the second product API specifically involves: determining the mapping relationship between each original API type in the list to be mapped and the target API type in the second product API.

[0019] Furthermore, before the step of generating an adapter type for the original API type, the method further includes: obtaining an existing adaptation layer code framework; determining whether there is an adapter type corresponding to the original API type in the existing adaptation layer code framework; when there is an adapter type corresponding to the original API type in the existing adaptation layer code framework, keeping the existing members in the adapter type unchanged, and only inserting the adaptation member corresponding to the original API type into the adapter type to achieve incremental update of the adaptation layer code framework.

[0020] On the other hand, in order to achieve the above objectives, the present invention provides a device for porting secondary development code across products.

[0021] The secondary development code cross-product porting device includes: a loading module for loading the source project to be ported, wherein the source project is a secondary development project written based on the API of a first product; a filtering module for filtering the source code files to be ported from each source code file of the source project; an identification module for identifying type references belonging to the API of the first product from the source code files to be ported, thereby obtaining the original API type; a determination module for determining the mapping relationship between the original API type and the target API type in the API of a second product; a generation module for generating an adaptation layer code framework according to the mapping relationship; a copying module for copying the source code files to be ported to the target project; a first processing module for replacing the call nodes for the original API type with call nodes for the adapter type and replacing the namespace references with the corresponding namespaces in the target project, while maintaining the project hierarchy of the source project, thereby obtaining the migrated source code files; and a second processing module for obtaining a secondary development project of the target project based on the API of the second product, according to the adaptation layer code framework and the migrated source code files.

[0022] On the other hand, to achieve the above objectives, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above method.

[0023] On the other hand, to achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above method.

[0024] The present invention provides a method, apparatus, computer equipment, and medium for cross-product porting of secondary development code. First, it loads a source project written based on the API of a first product. Then, it automatically filters out the source code files to be ported and identifies the original API types referenced within them. Based on the mapping relationship between the original API types and the APIs of a second product, an adaptation layer code framework is constructed. The filtered source code files are then copied to the target project. While maintaining the original project hierarchy, the original API call nodes are automatically replaced with adapter call nodes. Finally, the adaptation layer code framework is combined to generate a target project based on the APIs of the second product. This invention enables automatic filtering, identification, and replacement of code to be ported. The automatically generated adaptation layer code framework completes the mapping and conversion between old and new APIs, significantly reducing manual porting workload and improving the efficiency, accuracy, and maintainability of code migration. Attached Figure Description

[0025] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0026] Figure 1 A flowchart of the method for porting secondary development code across products provided in Embodiment 1 of the present invention;

[0027] Figure 2 This is a flowchart of a method for porting secondary development code across products, as provided in Embodiment 2 of the present invention.

[0028] Figure 3 for Figure 2 Detailed flowchart of Step 1;

[0029] Figure 4 for Figure 2 Detailed flowchart of Step 3;

[0030] Figure 5 This is a block diagram of a secondary development code cross-product porting device provided in Embodiment 3 of the present invention;

[0031] Figure 6 This is a hardware structure diagram of a computer device provided in Embodiment 4 of the present invention. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0033] Example 1

[0034] This invention provides a method for porting secondary development code across products. This method increases the automation level of porting secondary development code across products, reduces the learning cost for developers across products, and improves porting efficiency and accuracy. Specifically, Figure 1 The flowchart of the method for porting secondary development code across products provided in Embodiment 1 of the present invention is as follows: Figure 1 As shown, the method for porting secondary development code across products provided in this embodiment includes the following steps S101 to S108.

[0035] Step S101: Load the source project to be ported.

[0036] The source project is a secondary development project based on the API of the first product, including the source project's solution files, project files, source code files, and project configuration. Optionally, the source project is loaded using Roslyn's compiler workspace. After loading, the system parses the project structure and referenced assemblies in the project, establishing the initial context for code analysis. This step provides a complete code foundation for subsequent syntax parsing and semantic analysis.

[0037] Step S102: Select the source code files to be ported from the source code files of the source project.

[0038] Step S102 is used to determine the scope of code related to the target function to avoid indiscriminate processing of the entire project. Optionally, in this embodiment, by calling the API provided by the Roslyn compiler platform, a syntax tree and a semantic model are constructed for each source file, thereby enabling the identification of code structure and type relationships.

[0039] Optionally, starting from the entry command of the target porting function, a breadth-first search (BFS) traversal is performed on the syntax tree. During the traversal: each type declaration node is located in the syntax tree to determine its source file; the dependencies of this type (including base class, interface, member parameter types, and internal reference types) are identified through the semantic model; untraversed dependency types are added to a queue for further traversal until the queue is empty. Finally, all identified source files are deduplicated to obtain the set of source files to be ported. This step automatically identifies all files directly or indirectly related to the function to be ported, eliminating the need for manual identification.

[0040] Step S103: Identify the type references belonging to the first product API from the source code file to be ported, and obtain the original API type.

[0041] In step S103, the symbolic analysis function of the semantic model is used to identify the namespaces and type definitions referenced in the source code. When the source assembly of a type definition belongs to the API library provided by the first product, the type is recorded as the original API type. These original API types will be used as objects for subsequent mapping and replacement operations. Optionally, the identified original API types can be written to a list file to be mapped for subsequent manual or automatic establishment of mapping relationships.

[0042] Step S104: Determine the mapping relationship between the original API type and the target API type in the second product API.

[0043] Step S104 is used to establish the type mapping relationship between two sets of APIs from different vendors. In this embodiment, the developer can determine the corresponding target API type based on the API documentation of the second product, comparing it with the function and semantics of the original API type, and record the mapping relationship in the mapping configuration file. Optionally, the mapping file can be stored in key-value pair format, where the key is the fully qualified name of the original API type and the value is the fully qualified name of the target API type. If a new original API type is subsequently detected, the mapping file can be incrementally updated.

[0044] Step S105: Generate the adaptation layer code framework based on the mapping relationship.

[0045] Step S105 is the core of automated porting. Optionally, in one embodiment, the inheritance relationship and member signature information of each original API type are first extracted based on the syntax tree and semantic model. The inheritance relationship includes the base type of the original API type, the implemented interface, type visibility and modifiers, and generic parameters and their constraints; the member signature information includes the names, parameter lists, and parameter passing modifiers of members such as methods, constructors, properties, events, indexers, and fields. Based on the above information, an adapter type is automatically generated for each original API type, ensuring consistency with the original API type in inheritance hierarchy and member signatures. Subsequently, according to the mapping relationship, the target API type is bound to each adapter type, that is, placeholder implementation logic that interacts with the target API type is generated inside the adapter, thereby forming the adaptation layer code framework. If an adaptation layer framework already exists, only newly added adapters or adaptation members are generated incrementally.

[0046] Step S106: Copy the source code files to be ported to the target project.

[0047] Step S106 is used to build the migrated project structure. Optionally, the target project is a secondary development project based on the second product API, maintaining the same project hierarchy as the source project, and the selected source code files to be migrated are copied to the corresponding directory of the target project.

[0048] Step S107: While maintaining the project hierarchy of the source project, replace the call nodes for the original API type with call nodes for the adapter type, and replace the namespace references with the corresponding namespaces in the target project to obtain the migrated source code files.

[0049] In step S107, all nodes in the source code that call the original API are located by traversing the syntax tree, and their corresponding type names and namespaces are replaced with the adapter type and adaptation layer namespace. Optionally, the original logic and calling order are preserved during the replacement process, and only the reference paths are modified. The resulting migrated source code file remains consistent with the original project logic, but the underlying API calls will be redirected through the adaptation layer.

[0050] Step S108: Based on the adaptation layer code framework and the migrated source code files, obtain the secondary development project of the target project based on the second product API.

[0051] Step S108 involves compiling the previously generated adaptation layer code framework and the migrated source code files together to create a complete project that can run in the second product's API environment. Optionally, developers can implement the mapping logic or supplement virtual interfaces in subsequent stages to achieve full functional compatibility.

[0052] In the cross-product migration method for secondary development code provided in this embodiment, the source project written based on the API of the first product is first loaded. Then, the source code files to be migrated are automatically selected, and the original API types referenced in them are identified. Based on the mapping relationship between the original API types and the API of the second product, an adaptation layer code framework is constructed. The selected source code files are then copied to the target project. While maintaining the original project hierarchy, the original API call nodes are automatically replaced with adapter call nodes. Finally, the target project based on the API of the second product is generated by combining the adaptation layer code framework. Using the cross-product migration method for secondary development code provided in this embodiment, the automatic selection, automatic identification, and automatic replacement of the code to be migrated can be achieved. The mapping and conversion between the old API and the new API are completed through the automatically generated adaptation layer code framework, which greatly reduces the workload of manual migration and improves the efficiency, accuracy, and maintainability of code migration.

[0053] Optionally, in one embodiment, the step of generating the adaptation layer code framework according to the mapping relationship includes: generating an adapter type for the original API type, wherein the inheritance relationship and member signature of the adapter type are the same as those of the original API type; and binding the internal members of the adapter type to the target API type corresponding to the original API type according to the mapping relationship to obtain the adaptation layer code framework.

[0054] Specifically, when generating the adaptation layer code framework, an adapter class is first generated for each original API type based on its relevant information. The name of the generated adapter class can be the same as the original API type. The code structure of the adapter class is automatically output through a template generation mechanism, including class declarations, inheritance and interface implementation statements, member declarations, and method body placeholders. At this point, the adapter type maintains consistency with the original API type in inheritance hierarchy and member signatures, ensuring that the source code can still compile after migration.

[0055] Then, based on the generated adapter type structure, the binding logic is automatically injected into the adapter types using the mapping relationship between the original API type and the target API type established in the previous steps. During binding, the mapping file that sets the mapping relationship is read, where the mapping file defines the correspondence between the original API type and the target API type in key-value pairs. For each member declaration in each adapter type, placeholder statements for calling the corresponding member of the target API type are automatically generated. When some members cannot find a corresponding target API member, comments or "TODO" tags are automatically generated in the method body to prompt for manual addition later. After all adapter types have been generated, these class files are organized into a single, independent Adapter Layer Project, which contains all the generated adapter type files and mapping relationship reference configurations, thus forming the adapter layer code framework.

[0056] In the cross-product migration method for secondary development code provided in this embodiment, an adapter type is first automatically generated for each original API type, ensuring complete structural correspondence with its inheritance relationship and member signature. Then, based on the mapping relationship between the old and new APIs, binding logic for the target API type is generated within the adapter, thus forming an adaptation layer code framework with a unified structure and mapping semantics. Using the cross-product migration method for secondary development code provided in this embodiment, an intermediate layer connecting the old and new APIs can be automatically built without changing the original business logic, achieving type-level and method-level correspondence binding. This method significantly reduces the workload of manually writing adaptation code and improves the efficiency and correctness of cross-product API replacement.

[0057] Optionally, in one embodiment, the step of generating an adapter type for the original API type includes: extracting the inheritance relationship and member signature of the original API type based on the syntax tree and semantic model, wherein the inheritance relationship includes the base type of the original API type, the implemented interface, type visibility and type modifier, and generic parameters and constraints of generic parameters, and the member signature includes member name, parameter list and parameter passing modifier; and generating an adapter type based on the inheritance relationship and member signature.

[0058] Specifically, the Roslyn compiler platform's Syntax Analysis and Semantic Analysis interfaces are invoked to perform static code scanning on the loaded source project, extracting the complete structural definition of each primitive API type. First, after loading the target project through the compiler workspace, the type declaration nodes in the syntax tree (such as ClassDeclarationSyntax, InterfaceDeclarationSyntax, etc.) are traversed, and the corresponding semantic symbols (INamedTypeSymbol) are obtained. The inheritance information and member sets of the type can be accessed through the semantic symbols. The extraction of inheritance relationships includes reading the following information about the type: Base Type: the parent class it inherits from; Implemented Interfaces: the set of all directly implemented interfaces; Type Visibility and Modifiers: such as public, abstract, sealed, static, etc.; Generic Parameters and Constraints: including constraints on type parameters (such as where T : class, new()). The extracted information is saved in the form of a data structure, such as JSON or C# objects. The process further iterates through all member symbols of this type, recording key signature elements for each member, including: member name; parameter list (parameter type, order, and number); and parameter passing modifiers (such as ref, out, in, and params). Through this analysis process, the structure and calling characteristics of each type and member are accurately extracted without executing code, providing complete template information for subsequent adapter type generation.

[0059] Finally, based on the extracted structured information, an adapter type definition is automatically generated that maintains consistency with the original API type in inheritance relationships and member signatures. Optionally, a C# source code file is dynamically constructed using a code template engine. Specifically, a class declaration header is generated based on the inheritance relationship, including the class name, access modifiers, inherited parent class and interface, generic declarations, and constraints; member declarations (methods, properties, events, etc.) in the class body are generated based on the member signature, and placeholder comments indicating the implementation or call to the target API are inserted in the method bodies. After generation, the adapter type source file is saved to the adaptation layer project, and the project configuration file is updated to ensure direct compilation later. After this step, the resulting adapter type structurally corresponds completely to the original API type, ensuring that logic calling this type in the original project can still be parsed correctly after migration.

[0060] In the cross-product porting method for secondary development code provided in this embodiment, the inheritance relationship and member signature information of the original API type are first automatically extracted using a syntax tree and semantic model to ensure that the type structure and interface definition are completely parsed. Then, based on this information, an adapter type that is consistent with the original type in inheritance hierarchy and member definition is automatically generated, thereby achieving automatic replication and adaptation preparation of the original API structure during code migration. Using the cross-product porting method for secondary development code provided in this embodiment, API type structure parsing and adapter generation can be automatically completed without manual analysis of the code structure, ensuring compilation compatibility and logical consistency after source code migration, significantly reducing the workload of manually writing the adaptation layer, and improving the automation and reliability of cross-product code porting.

[0061] Optionally, in one embodiment, the step of selecting source code files to be ported from each source code file of the source project includes: constructing a syntax tree and a semantic model for each source code file of the source project; and selecting source code files to be ported from each source code file of the source project based on the syntax tree and the semantic model.

[0062] Specifically, the compiler API provided by the Roslyn compiler platform is used to perform static analysis on the source project, constructing a syntax tree and semantic model for each source file to obtain the structural and contextual semantic information of the source code. Specifically, the source project is loaded using Roslyn's MSBuildWorkspace or AdhocWorkspace, automatically resolving project dependencies and referenced assemblies; a syntax tree is constructed for each source file using CSharpSyntaxTree.ParseText(), resulting in an abstract syntax structure containing all syntax nodes; and the semantic model is obtained using the compiler context object via the GetSemanticModel() method. The semantic model provides semantic information for each syntax node, including symbolic references, type bindings, namespace context, etc. The syntax tree structure is used to analyze the hierarchical relationships of the code (such as namespaces, classes, methods, statement blocks, etc.), while the semantic model is used to interpret the meaning of the code (such as type attribution, dependencies, and reference sources). The combination of these two provides an accurate syntactic and semantic foundation for the subsequent automatic identification of files to be ported. The syntax tree identifies the class declaration ShapeManager, the member field shape, and the method Draw(). The semantic model further parses the IShape interface to determine its specific assembly, thus identifying that the file depends on the first product API. Ultimately, the constructed syntax tree and semantic model form the basis of the analysis, automatically determining which source code files are related to the function to be ported. In complex projects, this automatically filters out all files related to the functional logic, achieving precise filtering from the project level to the file level.

[0063] In the cross-product porting method for secondary development code provided in this embodiment, a syntax tree and semantic model are first constructed for each source code file in the source project to obtain the syntactic structure and semantic dependency information of the code. Then, based on the joint analysis results of the syntax tree and semantic model, source code files related to the target function are automatically identified from the project, forming a set of files to be ported. Using the cross-product porting method for secondary development code provided in this embodiment, source code files dependent on specific APIs or functional logic can be automatically identified without manual judgment, significantly reducing the workload and error rate of manual screening, improving the accuracy and efficiency of cross-product code porting, and providing a high-quality input data foundation for subsequent API replacement and adaptation layer generation.

[0064] Optionally, in one embodiment, the step of selecting source code files to be ported from the source code files of the source project based on the syntax tree and semantic model includes: taking the entry command of the target porting function as the traversal starting point, obtaining the syntax node and semantic symbol corresponding to the entry command; traversing in a breadth-first manner starting from the traversal starting point, and performing the following steps for each accessed type during the traversal process: Step S1: locating the declaration node of the accessed type based on the syntax tree, and determining the source code file where the declaration of the accessed type is located based on the declaration node; Step S2: analyzing the dependency relationship of the accessed type based on the semantic model; Step S3: adding the types obtained based on the dependency relationship that have not yet been traversed to the breadth-first traversal queue; when the breadth-first traversal queue is empty, deduplicating the source code files determined in step S1 to obtain the source code files to be ported.

[0065] Specifically, the first step is to determine the entry command for the target porting function (e.g., plugin entry class, command registration method, callback method for main menu actions, etc.). Using project indexing or symbol lookup, the syntax nodes and semantic symbols corresponding to the entry command are located. Syntax nodes are used to subsequently locate declarations and source files, while semantic symbols are used to resolve type relationships and cross-file references.

[0066] Then, starting from the traversal starting point, a breadth-first search is performed. During the traversal, steps S1 to S3 are executed for each visited type. In step S1, the declaration reference of the visited type is obtained through its semantic symbols. The first or all declaration syntax nodes are read, and the source file path is obtained from the declaration nodes and added to the candidate file set. In step S2, the base type, implemented interface, and types involved in the member signatures of the visited type are read, and the collected dependency types are used as the next level of objects to be visited. This step utilizes semantic analysis to identify other types that a type directly depends on, providing input for the BFS expansion queue. In step S3, a queue is used to store the types to be visited, and the visited set is used to remove duplicates, avoiding circular dependencies that could cause repetition or infinite loops. For each newly discovered dependency type, if it is not in the visited set, it is enqueued to ensure the hierarchy and completeness of the traversal.

[0067] When the breadth-first traversal queue is empty, the candidate file set is deduplicated by file path. Optionally, files that do not belong to the source project or are not under the specified namespace prefix are filtered out to obtain the final set of source code files to be ported, which serves as the input for subsequent copying and replacement steps.

[0068] In the cross-product porting method for secondary development code provided in this embodiment, the entry command of the target porting function is first used as the starting point for traversal to obtain its syntax nodes and semantic symbols. Then, based on the syntax tree and semantic model, a breadth-first traversal is adopted to locate the declaration file of each accessed type, and then its direct dependency types are obtained with the help of semantic analysis. Unaccessed dependency types are added to the traversal queue. When the traversal is completed, the accumulated declaration files are deduplicated to obtain the set of source code files to be ported along with the function. Using the cross-product porting method for secondary development code provided in this embodiment, all source code files associated with the target function can be automatically and systematically identified at the project level, avoiding manual judgment and omissions. This method ensures the completeness and accuracy of the screening results through the joint analysis of syntax location and semantic dependencies, providing accurate and reusable input for subsequent adaptation layer generation, API call replacement and project migration.

[0069] Optionally, in one embodiment, after obtaining the original API type and before determining the mapping relationship, the method further includes: obtaining a list to be mapped; determining whether the original API type is in the list to be mapped; when the original API type is not in the list to be mapped, appending the original API type to the list to be mapped, wherein the step of determining the mapping relationship between the original API type and the target API type in the second product API specifically involves: determining the mapping relationship between each original API type in the list to be mapped and the target API type in the second product API.

[0070] Specifically, the mapping list stores the set of original API types for which new and old API mapping relationships need to be established, serving as the input list for the mapping process. This list is persistently stored in an external configuration file, with the fully qualified name of the original API type as the primary key. This file is read into the memory structure before the mapping process begins, enabling rapid retrieval. After the upstream steps identify the original API types, it is sequentially checked whether the fully qualified name of each type already exists in the mapping list. If it exists, it means the type has already been recorded in historical mapping work and does not need to be added again; if it does not exist, it is appended. Optionally, to avoid misjudgments caused by differences in capitalization or namespace format, a normalization strategy (such as using a unified namespace separator and removing redundant whitespace) is applied to the type names before comparison. Only newly discovered original API types that have not appeared before are appended to the list, without modifying existing entries. Further, optionally, auxiliary metadata (such as first discovery time, source file path, and reference count) is written simultaneously during appending, and the memory structure is synchronized back to the configuration file in real time to reduce the risk of data loss due to power outages or anomalies. Simultaneously, additional items can be marked as unmapped, which will be used to filter items for processing when establishing mapping relationships later. The system iterates through the unmapped original API types in the unmapped list. Developers or the rule engine, based on the second product's API documentation and conventions, match each original API type to the target API type, write the mapping results back to the mapping relationship file, and mark the corresponding entries as mapped. For entries that cannot be mapped, the unmapped status and reason are recorded, and manual adaptation will be performed later.

[0071] In the cross-product migration method for secondary development code provided in this embodiment, after identifying the original API type and before establishing the mapping relationship between the old and new APIs, the historical list of APIs to be mapped is read first, and the newly added original API types are deduplicated and incrementally added. Then, based on the list of APIs to be mapped, the correspondence between each original API type and the target API type of the second product is established one by one, and the result is persisted as a mapping file, which serves as the direct basis for subsequent generation of the adaptation layer and replacement calls. By introducing an incremental maintenance mechanism for the list of APIs to be mapped in the mapping stage, the cross-product migration method for secondary development code provided in this embodiment can avoid repetitive work and significantly reduce the management complexity and error probability in cross-product API migration.

[0072] Optionally, in one embodiment, before generating an adapter type for the original API type, the method further includes: obtaining an existing adaptation layer code framework; determining whether there is an adapter type corresponding to the original API type in the existing adaptation layer code framework; when there is an adapter type corresponding to the original API type in the existing adaptation layer code framework, keeping the existing members in the adapter type unchanged, and only inserting the adaptation members corresponding to the original API type into the adapter type to achieve incremental updates of the adaptation layer code framework.

[0073] Specifically, before executing a new round of code migration, the process first checks whether historically generated adapter layer project files already exist. The adapter layer code framework consists of multiple adapter class files stored in a separate project. Its structure includes one adapter class file for each old API type. The project file and namespace hierarchy are consistent with the source API, and the files already contain some manually implemented adaptation logic or previously automatically generated adaptation members. The adapter layer path is loaded through configuration items or project indexes, and the structure definitions of all adapter types are read. Optionally, Roslyn's syntax analysis interface is used to parse these files, and a type index table within the adapter layer is established (e.g., using the fully qualified name of the class as the key and the corresponding syntax node or file path as the value). From this table, an adapter type that is consistent with or matches the current original API type (its fully qualified name, such as namespace + type name) is retrieved. If no match is found, it means that the original API type has not been migrated before, and a corresponding adapter type file will be created in subsequent processes; if a match is found, it is assumed that the type already has a historical version of the adapter class, and the incremental update logic can proceed.

[0074] Alternatively, the semantic model can be used to determine whether the inheritance structure of the adapter type is still compatible with the original API type. If there is an inconsistency, a warning will be generated or the class header definition will be regenerated.

[0075] When an existing adapter layer code framework contains an adapter type corresponding to the original API type, the following steps are taken: First, the syntax tree of the existing adapter class file is analyzed to identify its existing members, including methods, properties, and events, and their signatures are recorded. Then, the member signatures of the current original API type are compared with the existing adapter member signatures. For existing member signatures, they remain unchanged, preserving historical implementation code and comments. For newly identified members that do not yet exist in the adapter, declarations are automatically generated and inserted into the appropriate locations in the class definition. Standardized placeholder implementations are generated when inserting new members. After the tree operation is complete, the adapter layer file content is updated and saved to the original path, thus achieving incremental updates while maintaining the integrity of the existing adapter logic.

[0076] In the cross-product migration method for secondary development code provided in this embodiment, before generating a new adapter type, the existing adaptation layer code framework is first loaded, and it is determined whether it already contains an adapter type corresponding to the current original API type. If it already exists, the original members remain unchanged, and only newly identified members in the original API type are automatically inserted into the adapter with corresponding adaptation declarations, thereby achieving incremental updates to the adaptation layer code framework. Using the cross-product migration method for secondary development code provided in this embodiment, the existing adaptation layer structure and manual implementation results can be fully reused during cross-product API migration, eliminating the need to repeatedly generate or manually merge old code, significantly improving the reusability of code generation. Simultaneously, through the automated identification and insertion of new members, the structure of the adaptation layer code framework is synchronized with the original API type, further improving the efficiency and consistency of cross-version migration and multi-stage adaptation.

[0077] Example 2

[0078] like Figures 2 to 4 As shown, the method for porting secondary development code across products provided in this embodiment includes five steps, from Step 1 to Step 5. These are explained below:

[0079] Step 1: Static scanning and mapping list initialization.

[0080] In this embodiment, Roslyn's parser and semantic analyzer APIs are used to scan and parse the secondary development code.

[0081] 1.1 Constructing the syntax tree and semantic model. Using Roslyn's compiler workspace, load the secondary development project to be ported, traverse all projects and documents, and construct the syntax tree and semantic model;

[0082] 1.2 Identify Dependency Files. Based on the syntax tree, a breadth-first traversal is performed, starting from the entry command of the target porting function. For each type encountered, first, the file location of its own declaration is found; then, all dependencies of that type are identified through semantic model analysis, and the process is recursively traversed. Finally, all files that need to be ported are collected.

[0083] 1.3 Extract source API type information. Traverse each file to be ported, extract the old API types used in the code, including classes, interfaces, enumerations, and structs, and output the old API types to the mapping file so that the mapping relationship can be manually filled in the next step.

[0084] 1.4. Generate or incrementally update the list of unmapped types. If the list already exists, only add newly identified unmapped types to support incremental updates.

[0085] Step 2: Manually fill in the mapping relationship.

[0086] Developers analyze the type mapping relationships between the old and new APIs and fill them into the mapping file. Due to differences in API design, a small number of types may not be able to be mapped.

[0087] Step 3: Automated porting, including source file porting, adaptation layer framework generation, and interface and namespace replacement.

[0088] 3.1. Same as 1.1 for constructing syntax trees and semantic models.

[0089] 3.2 Extract the inheritance relationships between types to prepare for the automatic generation of the adaptation layer framework.

[0090] 3.3 Read the old and new API mapping relationships generated in step 2.

[0091] 3.4 Generate or incrementally update the adaptation layer code framework. In the adaptation layer, generate an adapter for each old API type, whose members, inheritance relationships, and modifiers are identical to the old API type. Automatically generate type and member declarations for each adapter and automatically bind them to the new API types they map to. During subsequent porting, if an adapter for the source API type already exists, keep the already adapted members unchanged and only insert new adapted members at appropriate locations.

[0092] 3.5 Source File Porting. Copy the code files to be ported to the secondary development project based on the new API, maintaining the original project hierarchy.

[0093] 3.6 Namespace Replacement. Automatically replace the old API interfaces called with adapter interfaces and replace the namespaces.

[0094] 4. Manually implement the adapter layer interface

[0095] Developers supplement the implementation of each adapter member in the adaptation layer so that the old and new APIs can be switched through the adaptation layer interface.

[0096] 5. Manual modification

[0097] For a small number of types that cannot be adapted due to differences in API design, the source code is manually modified.

[0098] The cross-product porting method for secondary development code provided in this embodiment, based on syntax tree and semantic model analysis, automatically searches, filters, and ports code files and projects, automatically generates an adaptation layer interface framework, and automatically replaces old interfaces in the ported code, significantly reducing manual porting costs. The adaptation layer supports incremental updates; each porting only requires implementing newly added adaptation layer interfaces, and each implemented interface can be permanently reused, ensuring high reusability. Through API adaptation, the original project structure and code logic of the ported code remain unchanged, as the API adaptation logic is all within the adaptation layer, resulting in strong code maintainability. The adaptation layer, gradually improved during the porting process, eliminates cross-product API differences, reducing the learning cost for developers across products.

[0099] Example 3

[0100] Corresponding to Embodiment 1 above, Embodiment 3 of the present invention provides a device for porting secondary development code across products. The technical features and corresponding technical effects can be referred to Embodiment 1 above, and will not be repeated in this embodiment. Figure 5 This is a block diagram of the secondary development code cross-product porting device provided in Embodiment 2 of the present invention, as shown below. Figure 5 As shown, the device includes: a loading module 201, a filtering module 202, an identification module 203, a determination module 204, a generation module 205, a copying module 206, a first processing module 207, and a second processing module 208.

[0101] The loading module 201 is used to load the source project to be ported, wherein the source project is a secondary development project based on the first product API; the filtering module 202 is used to filter the source code files to be ported from each source code file of the source project; the identification module 203 is used to identify the type references belonging to the first product API from the source code files to be ported, and obtain the original API type; the determination module 204 is used to determine the mapping relationship between the original API type and the target API type in the second product API; the generation module 205 is used to generate an adaptation layer code framework according to the mapping relationship; the copy module 206 is used to copy the source code files to be ported to the target project; the first processing module 207 is used to replace the call nodes for the original API type with the call nodes for the adapter type, and replace the namespace references with the corresponding namespaces in the target project, while maintaining the project hierarchy of the source project, to obtain the migrated source code files; and the second processing module 208 obtains a secondary development project of the target project based on the second product API according to the adaptation layer code framework and the migrated source code files.

[0102] Optionally, in one embodiment, the generation module includes: a generation unit, configured to generate an adapter type for the original API type, wherein the inheritance relationship and member signature of the adapter type are the same as those of the original API type; and a binding unit, configured to bind the internal members of the adapter type to the target API type corresponding to the original API type according to the mapping relationship, thereby obtaining the adaptation layer code framework.

[0103] Optionally, in one embodiment, when the generation unit generates an adapter type for the original API type, the specific steps include: extracting the inheritance relationship and member signature of the original API type based on the syntax tree and the semantic model, wherein the inheritance relationship includes the base type of the original API type, the implemented interface, type visibility and type modifier, and generic parameters and the constraints of the generic parameters, and the member signature includes member name, parameter list and parameter passing modifier; and generating the adapter type based on the inheritance relationship and member signature.

[0104] Optionally, in one embodiment, the filtering module includes: a construction unit, configured to construct a syntax tree and a semantic model for each source code file of the source project; and a filtering unit, configured to filter source code files to be ported from each source code file of the source project based on the syntax tree and the semantic model.

[0105] Optionally, in one embodiment, when the filtering unit filters source code files to be ported from each source code file of the source project based on the syntax tree and the semantic model, the specific steps include: taking the entry command of the target porting function as the traversal starting point, obtaining the syntax node and semantic symbol corresponding to the entry command; starting from the traversal starting point, performing a breadth-first traversal, and performing the following steps for each accessed type during the traversal process: Step S1: locating the declaration node of the accessed type based on the syntax tree, and determining the source code file where the declaration of the accessed type is located based on the declaration node; Step S2: analyzing the dependency relationship of the accessed type based on the semantic model; Step S3: adding the types obtained based on the dependency relationship that have not yet been traversed to the breadth-first traversal queue; when the breadth-first traversal queue is empty, deduplicating the source code files determined in step S1 to obtain the source code files to be ported.

[0106] Optionally, in one embodiment, the apparatus further includes: a first update module, configured to obtain a list to be mapped after the identification module obtains the original API type and before the determination module determines the mapping relationship, determine whether the original API type is in the list to be mapped, and when the original API type is not in the list to be mapped, append the original API type to the list to be mapped, wherein the determination module is further configured to determine the mapping relationship between each original API type in the list to be mapped and the target API type in the second product API.

[0107] Optionally, in one embodiment, before the step of the generation unit generating an adapter type for the original API type, the apparatus further includes: a second update module, configured to obtain an existing adaptation layer code framework; determine whether there is an adapter type corresponding to the original API type in the existing adaptation layer code framework; when there is an adapter type corresponding to the original API type in the existing adaptation layer code framework, keep the existing members in the adapter type unchanged, and only insert the adaptation member corresponding to the original API type into the adapter type to achieve incremental update of the adaptation layer code framework.

[0108] Example 4

[0109] This embodiment also provides a computer device, such as a smartphone, tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including a standalone server or a server cluster composed of multiple servers), etc., capable of executing programs. Figure 6 As shown, the computer device 01 in this embodiment includes, but is not limited to, a memory 012 and a processor 011 that can be interconnected via a system bus, such as... Figure 6 As shown. It should be noted that, Figure 6 Only a computer device 01 with component memory 012 and processor 011 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0110] In this embodiment, the memory 012 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 012 may be an internal storage unit of the computer device 01, such as the hard disk or memory of the computer device 01. In other embodiments, the memory 012 may also be an external storage device of the computer device 01, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 01. Of course, the memory 012 may include both the internal storage unit and its external storage device of the computer device 01. In this embodiment, the memory 012 is typically used to store the operating system and various reference software installed on the computer device 01, such as the program code of the secondary development code cross-product porting device in Embodiment 3. In addition, memory 012 can also be used to temporarily store various types of data that have been output or will be output.

[0111] In some embodiments, processor 011 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. This processor 011 is typically used to control the overall operation of computer device 01. In this embodiment, processor 011 is used to run program code stored in memory 012 or process data, such as methods for porting secondary development code across products.

[0112] Example 5

[0113] This embodiment also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, App reference store, etc., which stores computer programs. When the program is executed by a processor, it implements corresponding functions. The computer-readable storage medium of this embodiment is used to store a secondary development code cross-product porting device, and when executed by a processor, it implements the secondary development code cross-product porting method of Embodiment 1.

[0114] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0115] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0117] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A secondary development code cross-product migration method, characterized by, The method comprises the following steps: loading a source project to be transplanted, wherein the source project is a secondary development project written based on a first product API; constructing a syntax tree and a semantic model for each source code file of the source project respectively; screening source code files to be transplanted from each source code file of the source project based on the syntax tree and the semantic model, wherein the screening comprises: taking an entry command of a target transplanted function as a traversal starting point, obtaining a syntax node and a semantic symbol corresponding to the entry command, and starting traversal from the traversal starting point in a breadth-first manner, and performing the following steps for each visited type in the traversal process: Step S1: locating a declaration node of the visited type based on the syntax tree, and determining a source code file in which the declaration of the visited type is located according to the declaration node; Step S2: analyzing a dependency relationship of the visited type based on the semantic model; Step S3: adding a type obtained according to the dependency relationship and not yet traversed to a breadth-first traversal queue, wherein when the breadth-first traversal queue is empty, the source code file determined in step S1 is de-duplicated to obtain the source code file to be transplanted; identifying a type reference belonging to the first product API from the source code file to be transplanted to obtain an original API type; determining a mapping relationship between the original API type and a target API type in a second product API; generating an adaptation layer code framework according to the mapping relationship, comprising: generating an adapter type for the original API type, wherein an inheritance relationship and a member signature of the adapter type are the same as those of the original API type; and binding internal members of the adapter type to target API types corresponding to the original API type according to the mapping relationship to obtain the adaptation layer code framework; copying the source code file to be transplanted into a target project; replacing a calling node of the original API type with a calling node of an adapter type and replacing a namespace reference with a corresponding namespace in the target project while keeping a project hierarchy of the source project to obtain a migrated source code file; and obtaining a secondary development project of the target project based on the second product API according to the adaptation layer code framework and the migrated source code file.

2. The secondary development code cross-product migration method according to claim 1, characterized by, The step of generating an adapter type for the original API type comprises: extracting an inheritance relationship and a member signature of the original API type based on the syntax tree and the semantic model, wherein the inheritance relationship comprises a base type, implemented interfaces, type visibility and type modifiers, and generic parameters and constraints of the generic parameters of the original API type, and the member signature comprises a member name, a parameter list, and a parameter passing modifier; generating the adapter type based on the inheritance relationship and the member signature.

3. The secondary development code cross-product migration method according to claim 1, characterized by, After obtaining the original API type and before determining the mapping relationship, the method further comprises: obtaining a list to be mapped; determining whether the original API type is in the list to be mapped; when the original API type is not in the to-be-mapped list, appending the original API type to the to-be-mapped list, wherein the step of determining the mapping relationship between the original API type and the target API type in the second product API is specifically: determining the mapping relationship between each original API type in the to-be-mapped list and the target API type in the second product API.

4. The secondary development code cross-product migration method according to claim 1, characterized by, Before the step of generating the adapter type for the original API type, the method further comprises: obtaining an existing adaptation layer code framework; determining whether the existing adaptation layer code framework has an adapter type corresponding to the original API type; when the existing adaptation layer code framework has an adapter type corresponding to the original API type, keeping the existing members in the adapter type unchanged, and only inserting an adaptation member corresponding to the original API type in the adapter type to realize incremental update of the adaptation layer code framework.

5. A secondary development code cross-product migration apparatus characterized by comprising: comprises: a loading module configured to load a source project to be transplanted, wherein the source project is a secondary development project written based on a first product API; a screening module configured to screen source code files to be transplanted from source code files of the source project, wherein the screening module comprises: a construction unit configured to respectively construct a syntax tree and a semantic model for the source code files of the source project; and a screening unit configured to screen the source code files to be transplanted from the source code files of the source project based on the syntax tree and the semantic model, wherein when the screening unit screens the source code files to be transplanted from the source code files of the source project based on the syntax tree and the semantic model, the screening unit specifically performs the following steps: taking an entry command of a target transplantation function as a traversal starting point, obtaining a syntax node and a semantic symbol corresponding to the entry command; and starting from the traversal starting point, performing traversal in a breadth-first manner, and in the traversal process, performing the following steps for each visited type: step S1: locating a declaration node of the visited type based on the syntax tree, and determining a source code file in which the visited type is declared according to the declaration node; step S2: analyzing a dependency relationship of the visited type based on the semantic model; and step S3: adding a type obtained according to the dependency relationship and not yet traversed to a breadth-first traversal queue; and when the breadth-first traversal queue is empty, removing duplicates from the source code files determined in step S1 to obtain the source code files to be transplanted; an identification module configured to identify type references belonging to the first product API from the source code files to be transplanted to obtain original API types; a determination module configured to determine a mapping relationship between the original API types and target API types in a second product API; and a generation module configured to generate an adapter type for each original API type based on the mapping relationship. The generating module is configured to generate an adaptation layer code framework according to the mapping relationship, and the generating module comprises: a generating unit configured to generate an adapter type for the original API type, wherein the inheritance relationship and the member signature of the adapter type are the same as those of the original API type; and a binding unit configured to bind internal members of the adapter type to target API types corresponding to the original API type according to the mapping relationship, to obtain the adaptation layer code framework. The copying module is configured to copy the source code file to be transplanted into a target project. The first processing module is configured to replace, under the premise of maintaining a project hierarchy of the source project, a calling node of the original API type with a calling node of an adapter type and replace a namespace reference with a corresponding namespace in the target project, to obtain a migrated source code file. The second processing module is configured to obtain a secondary development project of the target project based on the second product API, according to the adaptation layer code framework and the migrated source code file.

6. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 4.

7. A computer readable storage medium having stored thereon a computer program, characterized in that: The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 4.

Images