Reputation: 2336
I often need to open several solutions with SSDT projects. These solutiuon have the same name and have minor differences, namely they are just from different branches in source control system. But these solution are always trying to use the same (localdb) instance in order to virtualize the databases of their projects. This leads to conflicts, freezes and necessity to end process of Visual Studio.
So the question is the following: is there a way to configure the name of (localdb) instance in order to open and virtualize the set of SSDT projects in solutions with the same name?
Upvotes: 4
Views: 3738
Reputation: 13
Configuration of Target Database for Debug and Build Process (F5) can be done in :
Project Properties - Debug - Target Connection string.
So you can point your branch projects with the same name to different database instances of your choice.
Upvotes: 1
Reputation: 84
I'm pretty sure that if the databases are at least named differently, that several instances of Visual Studio shouldn't have problems working with a single shared (localdb)\ instance. I tried it and didn't have problems other than database contention (even when the solutions and databases were named the same).
Granted, I can see how it could be useful to be able to work with several different instances hosting identically named DBs. For example, you are working at the same time in various code branches: trunk, some hotfix branch, and a feature branch.
I can't think of a very graceful way of doing this, but here are the parts you could use to put it together:
1) Use the "sqllocaldb" utility to create each of the localdb instances you need. You could do this in the pre-build event or just do it as a one-time thing on developer systems. Ex.
sqllocaldb.exe create "myinstance1"
2) The problem is configuring it... if you are using the "Debug" deployment from VS (deploying when you hit F5) you will have to manually change it for each different solution you are working in. If you use "Publish Profiles" you could have a profile for each different DB instance, but you would have to manually deploy the DB before debugging your app.
Do you rely on localdb for Team Build and automated integration testing as well? That could change things.
Here is some additional info: http://msdn.microsoft.com/en-us/library/hh510202.aspx.
Upvotes: 2