The AWS SDK for .NET solution is quite large and when you open the solution in Visual Studio it maxes out the CPU even when we are not doing anything in Visual Studio. The CPU never appears to go down. The project files were all converted to the newer SDK based csproj files. The solution can be found in GitHub at https://github.com/aws/aws-sdk-net/tree/master/sdk and open the AWSSDK.Net45.sln solution file. (commit 0b27e0e95e726d47c0b2f43dfa9aeb4cde6fa44b)
There is a single project “generator\ServiceClientGeneratorLib\ServiceClientGeneratorLib.csproj”, which happens to be in the old C# project format, but the solution file was hardcoded to open it with the new .Net Core factory.
I guess that won’t work very well. The problem here is in the dependencies tree (CrossTargetSubscritionHostBase.cs/UpdateProjectContextAsync function). The code computes the TargetFramework, which will be null. I guess the rule won’t exist there. Anyway, the result is it will create a new context on every call, then UpdateProjectContextAndSubscriptionsAsync will clean up old rule subscriptions, and registers a new set. The later one causes the tree to receive a new set of results, and starts the next round of the loop.
Anyway, the dependencies tree code can be a little bit smarter to know nothing has changed.
The AWS SDK for .NET solution is quite large and when you open the solution in Visual Studio it maxes out the CPU even when we are not doing anything in Visual Studio. The CPU never appears to go down. The project files were all converted to the newer SDK based csproj files. The solution can be found in GitHub at https://github.com/aws/aws-sdk-net/tree/master/sdk and open the AWSSDK.Net45.sln solution file. (commit 0b27e0e95e726d47c0b2f43dfa9aeb4cde6fa44b)
There is a single project “generator\ServiceClientGeneratorLib\ServiceClientGeneratorLib.csproj”, which happens to be in the old C# project format, but the solution file was hardcoded to open it with the new .Net Core factory.
I guess that won’t work very well. The problem here is in the dependencies tree (CrossTargetSubscritionHostBase.cs/UpdateProjectContextAsync function). The code computes the TargetFramework, which will be null. I guess the rule won’t exist there. Anyway, the result is it will create a new context on every call, then UpdateProjectContextAndSubscriptionsAsync will clean up old rule subscriptions, and registers a new set. The later one causes the tree to receive a new set of results, and starts the next round of the loop.
Anyway, the dependencies tree code can be a little bit smarter to know nothing has changed.