[MSBUILD SDK] Use custom SDK resolver for integration tests

[jviau]

Issue describing the changes in this PR

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

Additional information

This PR refactors how we bootstrap our SDK for integration tests. Previously our SDK was not used as a "Sdk" at all, but rather an import and then setting up some magic properties to ensure SDK would work. This will become a problem when we start generating the inner project, which is generated with the Sdk="" attribute. So we need a way to resolve our sdk without actually installing it as a nuget package (because that is finicky with iterative testing).

The solution, a custom msbuild SDK resolver! This is a little-known extensibility point of msbuild sdks, where you can set an environment variable point to a folder where MSBuild will scan for SDK resolvers. They must be in a specific layout: {env-var-folder}/{ResolverName}/{ResolverName}.dll.

This PR adds a new project Azure.Functions.Sdk.Resolver (test only, not shipping/production code), which will be scaffolded out into the expected structure -- including the SDK files themselves -- as part of building Azure.Functions.Sdk.Test. With this we can now test our SDK using the attribute Sdk="Azure.Functions.Sdk/99.99.99".

[Copilot]

Pull Request Overview

This PR refactors the test infrastructure to use a custom MSBuild SDK resolver for integration testing. The change eliminates hardcoded SDK file paths and removes the AwesomeAssertions import statements that are now handled through global usings.

• Consolidated module initialization methods into a single Initialize() method
• Introduced a custom TestSdkResolver to automatically resolve the Azure Functions SDK during tests
• Refactored MSBuild test helpers to use SDK-style project references instead of explicit file imports

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/Azure.Functions.Sdk.Tests/ModuleInitializer.cs	Consolidated two initialization methods into one and added resolver path configuration
test/Azure.Functions.Sdk.Tests/LogMessageTests.cs	Removed AwesomeAssertions using statement (now handled by global usings)
test/Azure.Functions.Sdk.Tests/Integration/SdkEndToEndTests.Restore.cs	Removed AwesomeAssertions using statement (now handled by global usings)
test/Azure.Functions.Sdk.Tests/Integration/MSBuildExtensions.cs	Refactored to use SDK-style project creation instead of explicit file imports
test/Azure.Functions.Sdk.Tests/Azure.Functions.Sdk.Tests.csproj	Added global usings and reference to resolver project, updated build target
test/Azure.Functions.Sdk.Resolver/TestSdkResolver.cs	New custom SDK resolver for test infrastructure
test/Azure.Functions.Sdk.Resolver/README.md	Documentation for the new resolver project
test/Azure.Functions.Sdk.Resolver/Azure.Functions.Sdk.Resolver.csproj	Project file for the custom SDK resolver
src/Azure.Functions.Sdk/Azure.Functions.Sdk.csproj	Updated GetSdkFiles target to include build output and handle files without RecursiveDir
DotNetWorker.sln	Added the new resolver project to the solution

Comments suppressed due to low confidence (1)

test/Azure.Functions.Sdk.Resolver/TestSdkResolver.cs:13

• Call to 'System.IO.Path.Combine'.

    private static readonly string SdkPath = Path.Combine(
        Path.GetDirectoryName(typeof(TestSdkResolver).Assembly.Location), "sdk");

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[liliankasem]

Minor comments (sp + docs)