Origin of MSSqlLocalDB and ProjectsV##
I previously had only SQL version 12 of both (localdb)\ProjectsV12 and (localdb)\MSSQLLocalDB
This is when I had VS 2015 Update 1 installed, along with SSDT tools(for database projects).
I installed Update 2 and now have:
Notice MSSQLLocalDB is still on the old version.
However, a coworker did a fresh install of VS 2015 and has this:
So they are on a newer version of MSSQLLocalDB, and I am on an older. Even though we are both up to Update 2 of Visual Studio.
I had hoped to move to using the version independent name of MSSQLLocalDB. The problem is, this won't work if everyone is on different versions, because I have the build setup to deploy the Database project to localdb, which requires use of SqlPackage, which is version specific:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120\SqlPackage.exe
I want to understand where and how MSSQLLocalDB gets installed and updated. I'm pretty sure ProjectsV12/13 comes as part of the Visual Studio install.
What installs MSSQLLocalDB, and what updates it?
Duplicate
The proposed duplicate just describes the MSSQLLocalDB as "the SQL Server 2014 LocalDB default instance name". This doesn't say anything about what it is installed as part of, or what updates it. Thanks
Answer
There are several related questions here.
What version of SqlPackage.exe to use
SqlPackage and all the SSDT tools are backwards compatible to SQL Server 2005. You should use the following 130 version to run against any database. It has the latest bug fixes and can target all publicly released SQL versions:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe
This will work against MSSQLLocalDB regardless of whether it is v13.0 or v12.0.
LocalDB Instances - how are they created and managed
MSSqlLocalDB is a default instance always installed on the machine. The ProjectsV12 and ProjectsV13 are created by SSDT using the LocalDB API. The purpose of having separate versions is
- To keep isolation from the default instance, since this is used by many other processes & project types
- To ensure we have a known version (e.g v13) so that we can reliably publish with the latest SQL Server features to it
Why do you and your coworker have different instances
Your coworker installed VS2015 Update 2 directly, with no previous version installed. This means the older code never created a ProjectsV12 instance on their machine.
What installs MSSQLLocalDB, and what updates it If you've previously installed LocalDB v12.0 (by using SSDT as part of VS2015 RTM or Update 1), it will have connected to & started MSSqlLocalDB. Hence, it created the instance as version 12.0.
If you never started this instance before (e.g. your colleague's example), then when first started it will be run from the v13.0 LocalDB and hence get v13.0 as the instance version.
As far as I am aware, it will not be upgraded from v12.0 to v13.0 at any point.
Does MSSqlLocalDB version matter? This depends. For most testing & ad hoc development this really doesn't matter.
If you care about version, for example if you're creating mdf of .bak files for application use, then you should use the LocalDB APIs to create a specific SQL version. Just download the relevant versioned MSI, install, & use the -version flag during instance creation via the API or command line. This may be the case too if you're using formal SSDT Publish operation instead of F5 deploy, though using the "Allow Incompatible Platform" option should work fine to work around.