Implement support for changing project and package references #49611
Conversation
github-actions
bot
added
the
Area-AspNetCore
|
Thanks for your PR, @@tmat. |
tmat
changed the title
There was a problem hiding this comment.
Pull Request Overview
This PR implements support for changing project and package references in dotnet-watch. The feature allows adding package or project references during Hot Reload sessions, handling the necessary steps of validation, redeployment, and runtime assembly resolution.
Key changes include:
- Enhanced compilation handler to support dependency deployment alongside managed code updates
- Added assembly resolution capability to the DotNetDeltaApplier for newly added dependencies
- Comprehensive test coverage for both project reference and package reference scenarios
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| test/dotnet-watch.Tests/HotReload/RuntimeProcessLauncherTests.cs | Added comprehensive tests for project and package reference addition scenarios |
| test/TestAssets/TestProjects/WatchAppWithProjectDeps/Dependency/Foo.cs | Added console output to support test verification |
| test/TestAssets/TestProjects/WatchAppWithProjectDeps/AppWithDeps/Program.cs | Refactored to support dynamic library calls in tests |
| src/BuiltInTools/dotnet-watch/UI/IReporter.cs | Added message descriptor for project dependency deployment reporting |
| src/BuiltInTools/dotnet-watch/HotReload/IncrementalMSBuildWorkspace.cs | Fixed project reference mapping for newly added projects |
| src/BuiltInTools/dotnet-watch/HotReload/HotReloadDotNetWatcher.cs | Implemented dependency deployment logic and updated flow to apply updates after deployment |
| src/BuiltInTools/dotnet-watch/HotReload/CompilationHandler.cs | Refactored to separate dependency deployment from update application |
| src/BuiltInTools/dotnet-watch/Build/BuildNames.cs | Added constants for dependency deployment target names |
| src/BuiltInTools/DotNetDeltaApplier/StartupHook.cs | Implemented assembly resolution for newly added dependencies at runtime |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| Directory.CreateDirectory(directory); | ||
| } | ||
|
|
||
| File.Copy(sourcePath, targetPath, overwrite: false); |
There was a problem hiding this comment.
What if the file is different? Is it expected that we use the old dependency?
There was a problem hiding this comment.
Yes, if the file exists it might have been loaded already. We could try to overwrite it and catch the exception, but I think that would result in less predictable behavior. The app might load the dependency at any point in time while it's running.
Roslyn will report a rude edit if the assembly version changed. In such scenario we would not get here.
We also don't get here when a referenced project is updated because that produces update delta, not a new binary that needs to be copied over.
There was a problem hiding this comment.
Makes sense! Thanks for the explanation.
|
/backport release/10.0.1xx |
2 participants
Adding a package or project reference requires the following steps:
Redeploying means copying dependencies that were added via package/project reference. These dlls are not present in output directory and need to be copied there.
dotnet-watch executes
ReferenceCopyLocalPathsOutputGrouptarget on these projects.We also need to move managed code update application after dependencies have been built and deployed, otherwise the updated code might start calling to the dependency that's not deployed yet.