In general SMO is the preferred approach as it is designed for managing SQL Server instances. Additionally SMO is supported on .NET Core+ whereas SqlDataSourceEnumerator
is only supported on .NET Framework.
Irrelevant of your approach no code is going to be reliable. The only way to know what SQL Server instances are available on a network is to broadcast to all the machines on the network. Besides swamping your network with calls just to find the 1 or 2 servers that are available it is also highly dependent upon the network and remote machines being responsive. Since pinging a machine with no SQL instance will return nothing then the calls are heavily time-dependent. If a machine is particularly business then it may not respond fast enough even if SQL is installed. On top of that you're relying on the SQL Browser service to be running if you want any reliable behavior. That service itself pings the SQL instances that are running. So if there is a delay there then the instance will be ignored. So, as the docs clarify, there is no reliable way to detect all SQL instances on a network. You may get some or you may get all, no guarantees. Whether you're using data enumeration or SMO doesn't change that.
There is no reliable way to find SQL Server instances on a network. Personally I would find such a solution questionable and think you should rethink your design to not require this. For example if you have control over the network then you could make it a rule that SQL server instances are only hosted on machines that have sql
in the name. Then you can scan the network for matching machines. Alternatively you could run some custom code on any machine that runs SQL server that provides back the list of instances when it is called. This requires that SQL instances be "registered" somewhere. Or, just require the user to know where the SQL server instances are at. Dynamically finding anything on a network is going to be unreliable.
As a final caution be aware that your network topology will impact this behavior as well. Security folks tend to lock stuff down so you cannot "browser" network software. This is a great way to attack a network. Additionally proxies that may be added to the network tend to break this kind of code as well.
If you must go this route then SMO would be the preferred approach if for no other reason than it is newer and works with later frameworks.