I have been developing an application which has an app.config file with a SQL Server connection string (code first Entity Framework). Since the solution I'm working on it in source control (TFS), it's shared; so I decided to make an alias for use in the connection string. That way, others developing on this project can use their own local database without changing the configuration file (and then checking their connection string changes back in and irritating the rest of the dev group). The alias that I created for my local laptop points to the SQL 2012 instance.
I opened up SQL Server Configuration Manager and created an alias to my 2012 instance (.\SQL2012). However, when the update-database command is executed, the database was deployed to the root instance (SQL 2008), and not the 2012 instance that I wanted it deployed to (as identified in my SQL Alias). I restarted the SQL Server service, but still got the same result when I called the update-database command again.
What I didn't realized is that I was using the SQL Server 2008 version of SQL Server Configuration Manager, not the 2012 version. The 2008 version won't show the 2012 services but 2012 version will show all services.
To better explain, this screenshot is what I see when I run the 2008 version:
and this is the screenshot from the 2012 version:
Notice that 2012 version displays the SQL Server 2012 instance of the services. Because I was using the 2008 version of the Configuration manager, I was unknowingly restarting the root server (2008) service, not the 2012 service.
After I restarted the 2012 instance, all worked just fine.
As far as Entity Framework is concerned, it seems to me that should expect an error that an instance can't be found when using the update-datebase command. It would have been nice to see an error at a minimum (i.e. "Cannot find SQL instance, defaulting to root").
See https://msdn.microsoft.com/en-us/library/ms174212.aspx for exact locations of the specific version of SQL Server Configuration Manager.
