Offical team blog for SSDT, a tool for on and off-premise database development
LocalDB is a version of SQL Server Express created specifically for developers. If you’re new to LocalDB, the Introducing LocalDB blog post is a great starting point to learn more but in summary, LocalDB is a fast, lightweight SQL Server instance that requires minimal management or configuration. SSDT installs and uses LocalDB as a debug database to provide a sandboxed environment for building, testing, and debugging your project. This post will briefly explore the interactions between SSDT and LocalDB that happens behind the scenes.
When you create a new SSDT project, a LocalDB instance is started for you by SSDT based on the name of the solution. For my project AdventureWorks, for example, I can immediately see a newly created LocalDB instance “(localdb)\AdventureWorks” in SQL Server Object Explorer and interact with it much like any other SQL Server instance.
This instance is ideal for developers who have limited or no access to server databases, but still need to validate their projects locally. Additionally, LocalDB can be used with SSDT when developing for SQL Azure as an offline development solution, enabling you to develop and test on your desktop before deploying to the cloud.
As a default, SSDT also sets your database project to target LocalDB during debugging. This means that without any configuration, F5 is already wired to build your database project and deploy it to LocalDB. This lets you rapidly test out project with no special configuration. Of course, if you wish to debug against a different SQL instance you can specify a different connection string in the Debug tab of your project properties.
So by default, when you hit debug or F5, your project will build and publish to LocalDB. You can verify that the objects have been deployed by expanding the LocalDB node in SQL Server Object Explorer and navigating to the recently deployed objects. You can add data to the instance, execute against it, and utilize it to test other applications. When you’re ready to publish your project, you can right-click on your project in Solution Explorer and select Publish or use SqlPackage.exe to publish via the command line.
The LocalDB connection will be managed throughout your SSDT session. The process running LocalDB may shutdown after several minutes of inactive connections, but the instance will be started again automatically as needed. You can also manually reconnect to your instance later as its state is persisted between sessions.
Keep in mind that you can also use LocalDB like other SQL instances by connecting to the default instance (localdb)\v11.0 or creating new instances of your own. See the SQL Server 2012 Express LocalDB documentation to learn more.
Instance creation is not possible in Visual Studio 2010 Shell as there are only BI related projects possible. However you can install Microsoft SQL Server Database Tools (which installs the LocalDB for sandboxing) from withing Visual Studio Shell. It is confusing to place the web installer in the New Project window.
You can install SSDT on the web from msdn.microsoft.com/.../hh297027, or as you mentioned, if you already have SQL Server 2012 and check the SSDT box during setup, you will see a stub project that launches the SSDT installer. The reason that we opted for the web install experience is because we ship frequent updates and wanted SQL Server 2012 users to always be pointed to the latest version of SSDT.
When you edit the "Target Connection String" the project file does not get modified. So, where is this configuration stored? Is there a way to set this value this in a source-controlled environment (TFS) so that all developers share the same configuration?