You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Class Library projects in Visual Studio, package restores are performed in the foreground, which causes Visual Studio to become unresponsive.
For example, changing the destination will cause Visual Studio to become unresponsive while files are deleted from their old location one by one. In addition, the file deletions are performed via the system shell, which may pop up the progress dialog from File Explorer, and that also causes mouse/keyboard focus to be lost temporarily, so I cannot continue work in another window during this operation.
To Reproduce
Steps to reproduce the behavior:
Create a new Class Library project (SDK-style) in Visual Studio. Not sure if the target framework matters, mine has multi-targeting: net6.0;netstandard2.1;net472
Add a new file named libman.json with the following content and save it:
We can share behavior across all CPS projects for handling files additions/removals. CPS is much more efficient for bulk edits - they work from the file system automatically, so we don't have to do batched edits on the UI thread in VS. This is something we should take advantage of for as many project types as possible, not limited to DotNetCoreWeb.
Addresses aspnet#710
jimmylewis
added a commit
to jimmylewis/LibraryManager
that referenced
this issue
Sep 19, 2023
We can share behavior across all CPS projects for handling files additions/removals. CPS is much more efficient for bulk edits - they work from the file system automatically, so we don't have to do batched edits on the UI thread in VS. This is something we should take advantage of for as many project types as possible, not limited to DotNetCoreWeb.
Addresses aspnet#710
We can share behavior across all CPS projects for handling files additions/removals. CPS is much more efficient for bulk edits - they work from the file system automatically, so we don't have to do batched edits on the UI thread in VS. This is something we should take advantage of for as many project types as possible, not limited to DotNetCoreWeb.
Addresses #710
Describe the bug
In Class Library projects in Visual Studio, package restores are performed in the foreground, which causes Visual Studio to become unresponsive.
For example, changing the
destination
will cause Visual Studio to become unresponsive while files are deleted from their old location one by one. In addition, the file deletions are performed via the system shell, which may pop up the progress dialog from File Explorer, and that also causes mouse/keyboard focus to be lost temporarily, so I cannot continue work in another window during this operation.To Reproduce
Steps to reproduce the behavior:
net6.0;netstandard2.1;net472
libman.json
with the following content and save it:destination
tolib/tom-select2
and save the file again. Visual Studio will now become unresponsive.Expected behavior
The restore operation should happen in the background, just like projects targeting
Microsoft.NET.Sdk.Web
.Screenshots
This demonstrates what I mean by "deleting one by one using the system shell":
![image](https://private-user-images.githubusercontent.com/5132940/244405205-fefb9f8e-19c8-4ffb-b3d9-ea7472192d8f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTkxMzE5OTMsIm5iZiI6MTcxOTEzMTY5MywicGF0aCI6Ii81MTMyOTQwLzI0NDQwNTIwNS1mZWZiOWY4ZS0xOWM4LTRmZmItYjNkOS1lYTc0NzIxOTJkOGYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDYyMyUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA2MjNUMDgzNDUzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NDVhNDkzMDQzZTIxM2E1NzQ3MWY3MTE2MTMwZDQ1YmE1YWI4OTE3NWM3MmMwNTI1NzEzY2U4YjhmNzFkYzAwNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.Ec6CLf9HyLHwFHgN8WF94TQk2WY2xqGA9vZ2vy_bVcM)
Additional context
The text was updated successfully, but these errors were encountered: