[dotnet] Allow inspecting source generated files

[nvborisenko]

User description

💥 What does this PR do?

Generated files can be found at obj/... folder. Now we can see what files are generated at compile time.

💡 Additional Considerations

Traditionally IDE should show these files, but it doesn't work in my case. Not sure why.

🔄 Types of changes

• Cleanup (formatting, renaming)

---

PR Type

Enhancement

---

Description

• Enable compiler-generated files inspection in output directory

• Configure generated files to emit to intermediate build folder

• Allows developers to view source-generated code at compile time

---

Diagram Walkthrough

flowchart LR
  A["Compiler Generation"] -->|EmitCompilerGeneratedFiles| B["Enable Output"]
  B -->|CompilerGeneratedFilesOutputPath| C["obj/Generated Folder"]
  C -->|Accessible| D["Developer Inspection"]

Loading

File Walkthrough

Relevant files

Enhancement

Selenium.WebDriver.csproj Configure compiler-generated files output in project          dotnet/src/webdriver/Selenium.WebDriver.csproj Added EmitCompilerGeneratedFiles property set to true to enable compiler-generated file output Configured CompilerGeneratedFilesOutputPath to direct generated files to $(BaseIntermediateOutputPath)\Generated folder Allows developers to inspect source-generated files in the build output directory +5/-0

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No audit impact: The new properties only configure compiler output paths and do not introduce or modify any critical action logic or logging, so audit trail compliance cannot be assessed from these changes alone. Referred Code <PropertyGroup> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)\Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No error handling: The added MSBuild properties do not introduce executable logic or error paths, so robustness of error handling cannot be evaluated from the new lines. Referred Code <PropertyGroup> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)\Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: No input handling: The new configuration solely enables emission of compiler-generated files and sets an output path, providing no context about external input validation or data handling to assess security posture. Referred Code <PropertyGroup> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)\Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Limit generated file emission to Debug builds Conditionally enable compiler-generated file emission only for Debug builds and use a forward slash in CompilerGeneratedFilesOutputPath for cross-platform compatibility. dotnet/src/webdriver/Selenium.WebDriver.csproj [103-106] -<PropertyGroup> +<PropertyGroup Condition="'$(Configuration)' == 'Debug'"> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> - <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)\Generated</CompilerGeneratedFilesOutputPath> + <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)/Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly improves the build configuration by limiting generated files to Debug builds and enhances cross-platform compatibility by using a forward slash, which are both good practices.	Medium
More

[RenderMichael]

the usual convention is /gen, and files can already be inspected by looking at a given analyzer's output

[nvborisenko]

It doesn't work on my end. Having plan B is better.

[nvborisenko]

and honestly it was a reason why I initiated this PR