.NET not detecting any SQL Server instances

Question

I have been developing a C# / SQL Server application on a Windows 8.1 device for a while, using .NET 4.5.1 and SQL Server 2012 Express. It all worked flawless. Recently, Visual Studio 2015 has been released and I decided to upgrade. I also decided to upgrade my SQL Server 2012 as well, so I backed everything up, uninstalled it and installed SQL Server 2014 Express. After configuring everything and restoring the database backups everything still worked locally as the database connection data was still present in the stored application settings.

When I tested the application on another device I found out that it could no longer connect to the SQL Server instance and it couldn't detect it either using

System.Data.DataTable instances = SqlDataSourceEnumerator.Instance.GetDataSources();

The application couldn't detect the SQL Server instance on my development machine either, which I think is rather strange as it's running local . Several other devices could, however, detect the SQL Server so I don't think it's a firewall related program. The SQL engine service and the browser services were both active.

I decided to upgrade to Windows 10, reset it (clean install, did not install any SQL Server programs) and run my application again, as there are other computers in my network running SQL Server, hoping it would detect those. It didn't. The GetDataSources() method returns an empty DataTable within a split second, while other devices take a few seconds to detect the instances and return a correct list.

Even more stupid is that ODBC Data Source Administrator does detect those network instances, making me think it is a .NET related program.

Summary: two devices do not detect any SQL Server instances (even local), while the other devices in the network do.

Answer 1

I have decided to go with this ODBC implementation as it is working correctly and an async/await update can be implemented so it won't block the UI.

Before choosing this implementation, I also poked around with another project using the SqlDataSourceEnumerator class, which worked perfectly. Its Target framework property was set to .NET Framework 2.0. I discovered that the SqlDataSourceEnumerator gives the expected results (on my machine) when the .NET target version is 3.5 or lower. Something in the .NET implementation has probably changed over time, causing it to stop working in some specific conditions.

Edit: on my machine I have installed SQL Server 2012 again, and everything (except for the detection, will use ODBC) is working fine again. I want to thank everyone for their input.

Answer 2

As an addition to this, we have had a similar problem after a VS2015/.Net 4.6 install. Our devs use SQL Express 2012 x64 (the default instance mostly or a named instance in some cases, but default for Express is a named instance called SQLEXPRESS anyway) and an alias to remove any machine name variation from connection strings (production uses DNS entries). The aliases were set to use TCP/IP and the server name was localhost\\instance.

But 4.6 nerfed the use of aliases and entity framework could not connect and nor could SSMS when using the alias. If I removed 4.6 and repaired 4.5.2, which seemed to get damaged by the 4.6 install, then we could use the alias in SSMS and our app, provided we used VS2013 since 2015 requires 4.6. This rather negated the point of trying to upgrade.

I don't know exactly what caused the problem but I do know that using the FQDN of the computer you are using in the alias works. Obtaining the port number of the instance and explicitly setting it in the alias also solves the problem, but if you are using dynamic port allocation (and you do by default) then this will break pretty quickly. Alternatively, if you have a single, default installation of a full edition of SQL server it seems to carry on working fine with the alias just set to localhost , (local) or . .

My best guess is some change in .Net 4.6 affects the SQL Browser service in some way since this should take care of routing requests to the right instance if they are using a dynamic port. Of course, it could be argued that you should always set a static port number explicitly, but who does that as a matter of course? I had toyed with raising it on Connect just in case this was some sort of bug, but I'm not sure.

EDIT

Raised a Connect issue because I think it is genuinely affecting SQL Browser.

https://connect.microsoft.com/VisualStudio/feedback/details/1719418