-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Fix the Aspire ServiceDefaults project template #33025
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR enhances the integration test for the maui-aspire-servicedefaults template by adding build verification and an additional property assertion to ensure the template generates a valid, buildable project with all required MAUI and Aspire configurations.
Key Changes:
- Adds a build verification step to ensure the generated project compiles successfully
- Adds an assertion to verify the
<UseMauiCore>true</UseMauiCore>property is present in the generated project file
| // Verify the project actually builds | ||
| Assert.IsTrue(DotnetInternal.Build(expectedProjectFile, "Debug", properties: BuildProps, msbuildWarningsAsErrors: true), | ||
| $"Project {Path.GetFileName(expectedProjectFile)} failed to build. Check test output/attachments for errors."); |
Copilot
AI
Dec 5, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build verification is happening before checking if the project file was created correctly (line 332). This ordering can make debugging failures more difficult, as a build failure due to a missing/incorrectly-named file will have a less clear error message than an explicit file existence check.
Consider moving this build verification to after the file existence checks (after line 345, before the property validation section) to match the test's logical flow: first verify template generation succeeded (file exists), then verify the build works, then verify the content is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| // Verify the project actually builds | ||
| Assert.IsTrue(DotnetInternal.Build(expectedProjectFile, "Debug", properties: BuildProps, msbuildWarningsAsErrors: true), | ||
| $"Project {Path.GetFileName(expectedProjectFile)} failed to build. Check test output/attachments for errors."); |
Copilot
AI
Dec 6, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build verification is performed before verifying that the project file actually exists. If the project file doesn't exist (line 332-333 check), the build step will fail with a potentially confusing error message. Consider moving the build verification to after the file existence checks (after line 345) to ensure better error messages and test clarity.
This pull request improves the integration test for the Aspire Service Defaults template by adding more thorough validation of the generated project. The changes focus on ensuring the template produces a buildable project and that the project file contains all required properties.
Enhancements to integration test coverage:
maui-aspire-servicedefaultstemplate can be successfully built, catching issues early in the test process.<UseMauiCore>true</UseMauiCore>property, in addition to the existing Aspire-specific properties check.