能否通过Azure Pipeline YAML阶段从文件夹结构生成.sln与.csproj文件？

Absolutely feasible! While this approach of generating temporary project files isn't the most elegant solution, it works perfectly for your specific scenario—where you're using Git subtree to include Unity utility/system modules that lack their own .sln/.csproj files, and you need to trigger docFX documentation builds when the submodules' main branches update.

Here's how you can implement this in your Azure Pipeline, step by step:

Core Idea #

Unity scripts are standard C# code at their core. We can use the .NET CLI to quickly generate temporary .csproj files for C# files in your target submodule folders—no need to rely on Unity's full project structure.

Step-by-Step Implementation in Azure Pipeline #

1. Add a Step to Generate Temporary .csproj Files #

Add a script task (PowerShell or Bash, depending on your agent's OS) to your pipeline that iterates through your submodule folders and generates a .csproj for each one.

Example PowerShell script:

# Iterate through all submodule folders (adjust the path to match your repo structure)
Get-ChildItem -Path ./Submodules -Directory | ForEach-Object {
    $modulePath = $_.FullName
    $moduleName = $_.Name
    
    # Move into the module directory
    Set-Location $modulePath
    
    # Generate a .NET class library project file
    dotnet new classlib --name $moduleName --output . --force
    
    # Clean up the auto-generated Class1.cs (we'll use your existing scripts instead)
    if (Test-Path "Class1.cs") {
        Remove-Item "Class1.cs"
    }
    
    # Optional: Add Unity assembly references if your scripts depend on UnityEngine
    $csprojContent = Get-Content "$moduleName.csproj" -Raw
    # Update the hint path to point to your UnityEngine.dll location in the pipeline agent
    $unityReference = '<Reference Include="UnityEngine"><HintPath>C:/Program Files/Unity/Hub/Editor/2022.3.10f1/Editor/Data/Managed/UnityEngine.dll</HintPath></Reference>'
    $csprojContent = $csprojContent.Replace('</ItemGroup>', "$unityReference`n</ItemGroup>")
    Set-Content "$moduleName.csproj" $csprojContent
    
    # Return to the root directory
    Set-Location $PSScriptRoot
}

2. Configure docFX to Use These Temporary Projects #

Update your docfx.json to include paths to the generated .csproj files in the metadata section:

{
  "metadata": [
    {
      "src": [
        {
          "files": ["Submodules/**/*.csproj"],
          "exclude": ["**/bin/**", "**/obj/**"]
        }
      ],
      "dest": "api"
    }
  ]
}

3. Chain the Pipeline Steps #

Make sure your pipeline runs in this order:

• Pull the main repo and its subtree content
• Run the script to generate temporary .csproj files
• Trigger the docFX documentation build
• (Optional) Clean up the temporary .csproj files after documentation generation to avoid polluting your repo

Key Considerations #

• Unity API Dependencies: If your submodule scripts use Unity namespaces (like UnityEngine), ensure the pipeline agent has access to the required Unity assemblies. You can either copy them to a known path in the agent or reference them directly from the Unity installation directory.
• File Filtering: Exclude test files, examples, or non-code files when generating the .csproj to prevent docFX from parsing unnecessary content.
• Performance: For large numbers of submodules, consider parallelizing the .csproj generation, or only process submodules that have changed (use Git diff to detect updates).

Alternative Approaches (For Your Ongoing Research) #

While the temporary .csproj approach works, long-term you might want to explore:

• Adding minimal, docFX-only .csproj templates to each submodule (these won't interfere with Unity's project structure)
• Writing a Unity tool to export assembly metadata from submodules for docFX to use

内容的提问来源于stack exchange，提问作者Thomas Greener