Just curious: Why is this very convenient and commonly used Timer class placed in the "System.ComponentModel.TypeConverter" assembly?

[Flithor]

https://github.com/dotnet/runtime/blob/main/src/libraries/System.ComponentModel.TypeConverter/src/System/Timers/Timer.cs

Is the simple answer "historical legacy"?

[huoyaoyuan]

Is the simple answer "historical legacy"?

Yes, and more. There are several different implementations of timer in .NET:

and System.Threading.Timer is the most low-level one. The new TimeProvider is also integrated with System.Threading.ITimer. As you can see in the implementation, System.Timers.Timer is also a wrapper on top of System.Threading.Timer.

[Flithor]

Because this assembly is for TypeConverters, so looks confusing that putting a type that obviously doesn't match the assembly name.
"historical legacy" also means that it is cannot to move it, and the type put into a wrong assembly issues are far less important than compatibility issues.

[huoyaoyuan]

It can be moved without breaking compatibility, just some extra effort is required.

I didn't find a particular reason for the assembly of this type. It's quite orphaned with no dependents found. System.ComponentModel.Primitives has all required dependencies, but doesn't feel "suitable". The answer may be simply "there's no best location" at all.

[Flithor]

Maybe the author of this class: "I don't know where should I to put this, so I just put it here."

[AustinWise]

There was a discussion about this in the pull request that initially checked in the timer. There is also some hints in the issue for adding the type to .NET Core (this is the broken issue number 10000 mentioned in the PR's description).

The short version is yes, it is a historical legacy that was thought to be a temporary solution at the time.

The long version: The type was not initially added to .NET Core as it is redundant with System.Threading.Timer, as @huoyaoyuan mentioned. It was added back in .NET Core 2.0 and .NET Standard 2.0 as part of the push for better backwards compatible when porting .NET Framework apps to .NET Core. The obvious place to put the Timer class would be the System.ComponentModel assembly (since Timer inherits from Component), but that assembly only depends on System.Runtime. The Timer implementation depends on classes that are not in System.Runtime and adding more dependencies to System.ComponentModel could cause a layering issue, so it had to go into a higher level assembly. And the next best fit was System.ComponentModel.TypeConverter. There was some conversation at the time to potentially combine some of the System.ComponentModel assemblies so the location of the type made more sense, but apparently that did not happen.