Consider to have an option to disable loading additional TFM in a super large solution

[lifengl]

When many projects in the solution have multiple TFMs, the current way to load all of them into memory and runs design time builds and builds language model is not scale well. Instead of running out of memory or make the IDE very slow, may suppressing some design time support, but fully support TFMs during build can be an option.

[davkean]

Yep, this requires a little design to figure out.

[davkean]

I'll make this the temporary opt-out. We need a long term design for the real fix which might be to dynamically load/unload configs based on usage.

[steffenloesch]

This would help us a lot I think. It would be great to have a way to select what 'main TFM' should be, and to adjust that based on editing needs. It would be acceptable for us to require a restart of VS for the changes to become effective.

[davkean]

@steffenloesch The main TFM will be the first, that's how we use it for all others that don't understand "multi-targeting".

[steffenloesch]

So when a developer wants to switch the main TFM to get a better IDE experience for that TFM, she'd have to reorder the TFM list, right? We can probably work with that.

[davkean]

I think I have a design for this and turns out to be pretty easy:

• In TargetFrameworkProjectConfigurationDimensionProvider, when this option is set; we'll return just the first TFM from the list <TargetFrameworks/>. The rest of the IDE will still think it's in multi-targeting mode, and hence things like solution build will continue to work (where it clears "TFM" to build from the outer), but all the other features will just think they are playing with a single TFM.

[davkean]

This design is harder than we think; we still an evaluation & design-time build to make NuGet restore happy, so we can't just turn off the configuration.

[davkean]

@steffenloesch: Note for 15.7 Preview 5 - we've made a change that prevent us from loading an additional config for projects if <TargetFrameworks></TargetFrameworks> is defined within the project itself: https://github.com/dotnet/project-system/pull/3482.

[Pilchie]

Unfortunately, moving the remainder to 15.8.

[steffenloesch]

Thanks for the updates! @davkean can you be more specific about what we need to do to avoid unnecessary loading? Does this change only work if the TargetFrameworks are explicitly defined in the csproj itself, or do you also support defining it in Directory.Build.props, say? Your last post can be read as "TargetFrameworks needs to be set to empty", which doesn't make sense to me. Do Platform and Configuration also have to be explicit in the csproj itself for getting efficient loading?

[davkean]

The optimization applies if TargetFrameworks appears within the project itself, it shouldn't be empty. We've yet to come up with a design for looking in Directory.Build.props.

[steffenloesch]

Follow-up question for @davkean: Is it sufficient for this optimization that first target framework is defined explicitly in the csproj, but others are not? In other words: if my project file contains <TargetFrameworks>net472;$(MyOtherTargetFramework)</TargetFrameworks>, would it benefit from the perf improvement that came in with VS 15.7 Preview 5?

[davkean]

Yes, we will handle that correctly.

[steffenloesch]

@davkean PR #3482 mentions "Configuration and Platform are only read if the solution didn't provide a default". What entries need to be present in the sln file to provide a default? Is it entries in GlobalSection(ProjectConfigurationPlatforms) like this? GlobalSection(ProjectConfigurationPlatforms) = postSolution {79243C18-8A45-41DC-A39E-03FBD110BD13}.Debug|x64.ActiveCfg = Debug|x64