One pager writeups #11045

maridematte · 2024-11-27T14:44:02Z

These are the one pagers for 3 features.

Evaluation performance with @rainersigwald.
PerfStar improvements with @AR-May.
VS and SDK decoupling with @baronfel

documentation/specs/proposed/decoupling-vs-sdk.md

jaredpar · 2024-12-03T00:02:05Z

documentation/specs/proposed/decoupling-vs-sdk.md

+ - Decoupling the Dotnet SDK from VS.
+
+
+The reason we are persuing this is for a better experience when using or writting Roslyn analyzers and MSBuild Tasks. Currently tooling authors need to target NetStandard2.0 for their projects to be recognized by VS. Another options is to multi-target but it takes a lot more effort and time spent on that. Another aspect is the user experience, if the Roslyn version for VS analyzers and generators doesn't match the one in Visual Studio, they do not work.


This paragraph seems to be combining what TFM analyzers need to target and SDK / VS analyzer tearing. Think we should split up those concerns.

I agree. Roslyn analyzers/generators targeting netstandard2 are one concern, multitargeting tasks is another, SDK tearing is a third.

documentation/specs/proposed/decoupling-vs-sdk.md

documentation/specs/proposed/evaluation-perf.md

Co-authored-by: Jared Parsons <[email protected]>

documentation/specs/proposed/parfStar.md

baronfel · 2025-01-08T20:41:46Z

This LGTM to merge.

rainersigwald · 2025-01-08T20:49:55Z

documentation/specs/proposed/decoupling-vs-sdk.md

@@ -0,0 +1,40 @@
+# Decoupling VS builds of .NET SDK projects
+The experience of building a .NET SDK project can differ significantly depending if the project was built using Visla Studio / MSBuild or `dotnet build`. The build can produce different diagnostics, use different language rules, etc... and that is because building a .NET SDK project from Visual Studio mixes components from MSBuild and the .NET SDK. This means core tooling, like the compiler, can be substantially different between the two types of build. This leads to customer confusion and hard to diagnose problems, as well as increased code workload. To solve this want to ensure that when building a .NET SDK project we use the components from the .NET SDK to do so.


Suggested change

The experience of building a .NET SDK project can differ significantly depending if the project was built using Visla Studio / MSBuild or `dotnet build`. The build can produce different diagnostics, use different language rules, etc... and that is because building a .NET SDK project from Visual Studio mixes components from MSBuild and the .NET SDK. This means core tooling, like the compiler, can be substantially different between the two types of build. This leads to customer confusion and hard to diagnose problems, as well as increased code workload. To solve this want to ensure that when building a .NET SDK project we use the components from the .NET SDK to do so.

The experience of building a .NET SDK project can differ significantly depending if the project was built using Visual Studio / MSBuild or `dotnet build`. The build can produce different diagnostics, use different language rules, etc. This is because building a .NET SDK project from Visual Studio mixes components from Visual Studio and the .NET SDK. This means core tooling, like the compiler, can be substantially different between the two types of build. This leads to customer confusion and hard-to-diagnose problems. To solve this want to ensure that when building a .NET SDK project we use more components from the .NET SDK to do so.

I cut "code workload" because I don't think I know what it is.

rainersigwald · 2025-01-08T20:50:20Z

documentation/specs/proposed/decoupling-vs-sdk.md

+## Goals and Motivation
+
+We are aiming for:
+ - Consistent end-user eperience for build in either DotNet CLI or Visual Studio.


Suggested change

- Consistent end-user eperience for build in either DotNet CLI or Visual Studio.

- More consistent end-user experience for build between .NET CLI and Visual Studio.

rainersigwald · 2025-01-08T20:50:35Z

documentation/specs/proposed/decoupling-vs-sdk.md

+ - Decoupling the .NET SDK experience from Visual Studio 
+ - Decoupling the .NET SDK from VS.


How do these differ?

Suggested change

- Decoupling the .NET SDK experience from Visual Studio

- Decoupling the .NET SDK from VS.

- Decoupling the .NET SDK experience from Visual Studio

rainersigwald · 2025-01-08T21:27:00Z

documentation/specs/proposed/decoupling-vs-sdk.md

+ - Decoupling the Dotnet SDK from VS.
+
+
+The reason we are persuing this is for a better experience when using or writting Roslyn analyzers and MSBuild Tasks. Currently tooling authors need to target NetStandard2.0 for their projects to be recognized by VS. Another options is to multi-target but it takes a lot more effort and time spent on that. Another aspect is the user experience, if the Roslyn version for VS analyzers and generators doesn't match the one in Visual Studio, they do not work.


I agree. Roslyn analyzers/generators targeting netstandard2 are one concern, multitargeting tasks is another, SDK tearing is a third.

rainersigwald · 2025-01-08T21:27:28Z

documentation/specs/proposed/decoupling-vs-sdk.md

+
+## Impact
+There are a few area of impact:
+ - .NET SDK style project builds will be more stable between VS and CLI builds, as the tooling will not be devided between different versions.


Suggested change

- .NET SDK style project builds will be more stable between VS and CLI builds, as the tooling will not be devided between different versions.

- .NET SDK style project builds will be more stable between VS and CLI builds, as the tooling will be less divided between different versions.

(there will still be tearing on core targets for the medium term)

rainersigwald · 2025-01-08T21:48:10Z

documentation/specs/proposed/perfStar.md

+MSBuild currently does not have a lot of performance data outside of Visual Studio performance tracking, which has a lot of variables that are beyond the team's control. PerfStar enables us to measure our performance without interference of elements that the team does not own. As such, we can measure the performance of in-development features and how it will impact build times, as well as have concrete numbers when working on performance improvement tasks.
+
+## Impact
+Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about taking performance improvement work, as well as future and implementation of new features.


Suggested change

Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about taking performance improvement work, as well as future and implementation of new features.

Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about performance improvement work, as well as implementation of new features. In turn, those decisions will accrue value to users via higher build performance.

rainersigwald · 2025-01-08T21:48:53Z

documentation/specs/proposed/perfStar.md

+Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about taking performance improvement work, as well as future and implementation of new features.
+
+## Risks
+The risks associated with our dependencies is about Crank, which is owned by the ASP.NET team and we use it to help us with machine setup to run the performance tests. 


I'd extend this: PerfStar is a service, even if it's one primarily for our own use, and introduces a bunch of risks related to service maintenance.

rainersigwald · 2025-01-08T21:49:11Z

documentation/specs/proposed/perfStar.md

+    - Around 1 dev week.
+2. The PowerBI reporting is working and updating the new information
+   - Around 2 dev weeks.
+3. New performance tests for new features, and writting docs on how to write those tests. Next feature planned for tests: BuildCheck.


Suggested change

3. New performance tests for new features, and writting docs on how to write those tests. Next feature planned for tests: BuildCheck.

3. New performance tests for new features, and writing docs on how to write those tests. Next feature planned for tests: BuildCheck.

rainersigwald · 2025-01-08T21:49:35Z

documentation/specs/proposed/perfStar.md

+   - Around 3 dev days per feature.
+4. Analyze stability of performance tests, and fix any noise found. This will be done through multiple iterations of the same test in the same machine, as well as updating the PowerBI report to handle the new data.
+   - Around 2 dev weeks.
+5. Add more tests using `msbuild.exe` for build instead of `dotnet build`.


Suggested change

5. Add more tests using `msbuild.exe` for build instead of `dotnet build`.

5. Add more tests using `msbuild.exe` for build in addition to `dotnet build`.

rainersigwald · 2025-01-08T21:49:56Z

documentation/specs/proposed/perfStar.md

+7. Add more test cases. For example, build time with different verbosity levels.
+   - Around 1 dev week.
+
+There are more improvements form PerfStar, but these are not established for .NET 10 yet as they depend on the team's feedback to PerfStar.


Suggested change

There are more improvements form PerfStar, but these are not established for .NET 10 yet as they depend on the team's feedback to PerfStar.

There are more improvements form PerfStar, but these are not planned for .NET 10 as they depend on the team's feedback to PerfStar.

maridematte added 4 commits November 25, 2024 18:42

Rough notes from meetings

1757325

decoupling write-up complete

a0a1c8b

evaluation performance investigation

8a79695

perfStar pager

73ca8c3

jaredpar reviewed Dec 3, 2024

View reviewed changes

baronfel and others added 3 commits December 4, 2024 08:35

Update documentation/specs/proposed/decoupling-vs-sdk.md

2cc45bb

Co-authored-by: Jared Parsons <[email protected]>

Update documentation/specs/proposed/evaluation-perf.md

929788c

Co-authored-by: Jared Parsons <[email protected]>

Some PR comment fiexes for decoupling paper

d2f54fa

slang25 reviewed Dec 11, 2024

View reviewed changes

documentation/specs/proposed/parfStar.md Outdated Show resolved Hide resolved

maridematte marked this pull request as ready for review December 12, 2024 15:01

AR-May mentioned this pull request Dec 17, 2024

PerfStar NET 10.0 investments #11164

Open

Rename parfStar.md to perfStar.md

9e3e2c8

baronfel approved these changes Jan 8, 2025

View reviewed changes

rainersigwald reviewed Jan 8, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

One pager writeups #11045

One pager writeups #11045

maridematte commented Nov 27, 2024

jaredpar Dec 3, 2024

rainersigwald Jan 8, 2025

baronfel commented Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

rainersigwald Jan 8, 2025

		- Decoupling the Dotnet SDK from VS.


		The reason we are persuing this is for a better experience when using or writting Roslyn analyzers and MSBuild Tasks. Currently tooling authors need to target NetStandard2.0 for their projects to be recognized by VS. Another options is to multi-target but it takes a lot more effort and time spent on that. Another aspect is the user experience, if the Roslyn version for VS analyzers and generators doesn't match the one in Visual Studio, they do not work.

		@@ -0,0 +1,40 @@
		# Decoupling VS builds of .NET SDK projects
		The experience of building a .NET SDK project can differ significantly depending if the project was built using Visla Studio / MSBuild or `dotnet build`. The build can produce different diagnostics, use different language rules, etc... and that is because building a .NET SDK project from Visual Studio mixes components from MSBuild and the .NET SDK. This means core tooling, like the compiler, can be substantially different between the two types of build. This leads to customer confusion and hard to diagnose problems, as well as increased code workload. To solve this want to ensure that when building a .NET SDK project we use the components from the .NET SDK to do so.

	- Consistent end-user eperience for build in either DotNet CLI or Visual Studio.
	- More consistent end-user experience for build between .NET CLI and Visual Studio.

		- Decoupling the .NET SDK experience from Visual Studio
		- Decoupling the .NET SDK from VS.

	- .NET SDK style project builds will be more stable between VS and CLI builds, as the tooling will not be devided between different versions.
	- .NET SDK style project builds will be more stable between VS and CLI builds, as the tooling will be less divided between different versions.

	Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about taking performance improvement work, as well as future and implementation of new features.
	Perfstar's impact is focused on the team. We will be able to track performance with concrete numbers. Because of that the team will be able to take more informed decisions about performance improvement work, as well as implementation of new features. In turn, those decisions will accrue value to users via higher build performance.

	3. New performance tests for new features, and writting docs on how to write those tests. Next feature planned for tests: BuildCheck.
	3. New performance tests for new features, and writing docs on how to write those tests. Next feature planned for tests: BuildCheck.

	5. Add more tests using `msbuild.exe` for build instead of `dotnet build`.
	5. Add more tests using `msbuild.exe` for build in addition to `dotnet build`.

	There are more improvements form PerfStar, but these are not established for .NET 10 yet as they depend on the team's feedback to PerfStar.
	There are more improvements form PerfStar, but these are not planned for .NET 10 as they depend on the team's feedback to PerfStar.

One pager writeups #11045

Are you sure you want to change the base?

One pager writeups #11045

Conversation

maridematte commented Nov 27, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

baronfel commented Jan 8, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment