Origin of MSSqlLocalDB and ProjectsV ##

I previously had only SQL version 12 of both (localdb)\ProjectsV12 and (localdb)\MSSQLLocalDB This is when I installed VS 2015 Update 1, as well as SSDT tools (for database projects).

I installed Update 2 and now have:

enter image description here

Note. MSSQLLocalDB is still in the old version.

However, a colleague performed a new installation of VS 2015 and has the following:

enter image description here

So, they are on a newer version of MSSQLLocalDB, and I'm older. Although we are both up to Update 2 from Visual Studio.

I was hoping to switch to using a version-independent name MSSQLLocalDB. The problem is that this will not work if everyone is on different versions, because I have a build installation to deploy the database project in localdb, which requires the use of SqlPackage, which depends on the version:

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 is installed and updated. I am sure that ProjectV12 / 13 is included with the installation of Visual Studio.

What installs MSSQLLocalDB and what updates it?

Duplicate

The proposed duplicate simply describes MSSQLLocalDB as the "default instance name of SQL Server 2014 LocalDB." This does not mean that it is installed as part of or that it is updating. Thanks

+6
source share
1 answer

There are several related questions here.

What version of SqlPackage.exe to use

SqlPackage and all SSDT tools are backward compatible with SQL Server 2005. To work with any database, you must use the following version 130. It has the latest bug fixes and can focus on all publicly released versions of SQL:

 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 They Are Created and Managed

MSSqlLocalDB is the default instance, always installed on the machine. Projects V12 and ProjectsV13 are created by SSDT using the LocalDB API . Assigning Individual Versions

  • To isolate from the default instance as it is used by many other processes and project types
  • To make sure we have a known version (e.g. v13) so that we can reliably publish it with the latest SQL Server features

Why do you and your colleague have different instances

Your colleague installed VS2015 Update 2 directly, without the previous version installed. This means that the old code never created an instance of ProjectV12 on its machine.

What installs MSSQLLocalDB, and what updates does it have If you previously installed LocalDB v12.0 (using SSDT as part of RTM version VS2015 or Update 1), it will connect and run MSSqlLocalDB. Consequently, he created the instance as version 12.0.

If you have never started this instance before (for example, your colleague example), then at the first start it will be launched from v13.0 LocalDB and, therefore, will receive v13.0 as the version of the instance.

As far as I know, it will not be updated from v12.0 to v13.0 at any time.

Does the version of MSSqlLocalDB matter? It depends. For most tests and special developments, this really does not matter.

If you need a version, for example, if you create mdf from .bak files for using applications, then you should use the LocalDB API to create a specific version of SQL. Just download the appropriate version of MSI, install and use the -version flag while creating the instance using the API or command line . This may be the case if you use the official SSDT publication, instead of deploying F5, although using the "Allow incompatible platform" option should work fine.

+8
source

All Articles