Code emitted by the generator has implicit dependencies on certain fundamental libraries, such as System.ClientModel and Azure.Core. Because the generated code uses these libraries extensively, it is often bound to a specific version of the libraries. For the initial generation, a project file is emitted which references the needed dependencies. After the initial run, the generator does not make changes to the project file.
For Azure libraries, this is reasonable because dependency versions are managed centrally, and the versions of the fundamental libraries are kept synchronized to the version needed by the generator. For unbranded libraries, however, this leaves a gap. Because unbranded libraries cannot assume the Azure SDK environment, the package references in the project file track the versions of dependences. These are not centrally managed and, thus, not synchronized with the versions needed by the generator.
This creates a challenge for unbranded library authors when running code generation. The generator expects certain versions of dependencies but does not maintain those versions in the generated project file. It also does not advertise the needed dependency versions, so project authors are not aware of them. This results in a scenario where a project may be left unable to compile after running code generation.
Challenges
Because library authors own the project file and may customize it to meet their needs, it is not feasible for the generator to assume that it can be safely updated.
Proposed solution
The generator should advertise its dependencies when code is generated. Because code generation is inherently a command line tool, writing out an explicit and clear section with dependency information to the console window should allow library authors to understand the generator's needs.
Along with the name and version of the dependency, the generator should also include the date that the version reference was last changed. This would allow library authors to more quickly identify and react to changes.
Examples from prior art
The npm package manager shows updates in the following format:
It also generates a dependency tree on demand:
The Angular CLI emits dependency information in the following format:
jsquire
commented
4 months ago
Problem statement
Code emitted by the generator has implicit dependencies on certain fundamental libraries, such as
System.ClientModelandAzure.Core. Because the generated code uses these libraries extensively, it is often bound to a specific version of the libraries. For the initial generation, a project file is emitted which references the needed dependencies. After the initial run, the generator does not make changes to the project file.For Azure libraries, this is reasonable because dependency versions are managed centrally, and the versions of the fundamental libraries are kept synchronized to the version needed by the generator. For unbranded libraries, however, this leaves a gap. Because unbranded libraries cannot assume the Azure SDK environment, the package references in the project file track the versions of dependences. These are not centrally managed and, thus, not synchronized with the versions needed by the generator.
This creates a challenge for unbranded library authors when running code generation. The generator expects certain versions of dependencies but does not maintain those versions in the generated project file. It also does not advertise the needed dependency versions, so project authors are not aware of them. This results in a scenario where a project may be left unable to compile after running code generation.
Challenges
Proposed solution
The generator should advertise its dependencies when code is generated. Because code generation is inherently a command line tool, writing out an explicit and clear section with dependency information to the console window should allow library authors to understand the generator's needs.
Along with the name and version of the dependency, the generator should also include the date that the version reference was last changed. This would allow library authors to more quickly identify and react to changes.
Examples from prior art
The
npmpackage manager shows updates in the following format:It also generates a dependency tree on demand:
The Angular CLI emits dependency information in the following format: