I'm migrating a solution which contains some C# projects from Visual Studio 2008 to VS2013. The migration went fine, with a few adjustments, but there's also a .dbp project (database project, from VS2008), which refuses to migrate / load in VS2013.
The closest project type I found in this newer version is "SQL Server Database Project", I've created one and added my existing .sql script files, but this project type (.sqlproj) appears to be something different. For example, VS 2008's "database project" does not build. Also, I had a hard time trying to add a reference to my existing SQL database running under SQLExpress.
I've also set BuildAction = None to all my script files, and now I can open each of them manually and execute. But still, I'd like to select multiple files and execute them all at once. Seems I'm missing something.
So, is there a way to accomplish that?
I suggest you look at the following article to convert the dbp to dbproj: MSDN
And after that look at the following link to convert dbproj to sqlproj: Tentacle Software Blog
Related
I have a new .net Core 2.0 Web API project (In Visual Studio 2017 Version 15.3.5) where I can´t build the solution if I add a new database project.
error MSB4019: The imported project "C:\Program Files\dotnet\sdk\2.0.0\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I have tried all kinds of solutions
Installed almost everything missing from the Visual Studio Installer
Installed Visual Studio Build Tools 2017
Repaired Visual Studio
Without luck I tried to find Microsoft.Data.Tools.Schema.SqlTasks.targets file on C:\ to the add reference to it in the project file (I then don´t know if that works while building the solution in VSTS).
So why can I add a database project to a normal API project and everything works just fine but not to a .net core one?
Do database projects not work with .net Core? I have searched for information on this but sorry I just can´t find it.
I´m not sure what to do. Hope somebody can help.
Ok I managed to find the Microsoft.Data.Tools.Schema.SqlTasks.targets file on my computer.
I then needed to unload the project and edit it
There I changed this line
<SSDTExists Condition="Exists('$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets')">True</SSDTExists>
to the hardcoded path of my file
<SSDTExists Condition="Exists('C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets')">True</SSDTExists>
And now it builds on my computer and on VSTS.
But why this is like this I don´t know.
I was having the exact same issue building a SQL Server project on an Azure DevOps CI/CD pipeline, and locally on VS Code. On Azure DevOps none of the pre-built build tasks would work for me, and locally I could only compile the SQL Server project on Visual Studio, which was annoying. Your solution didn't work for me, after doing what you suggest, I would get a .dll missing error, related with the first error.
I solved this by avoiding to add a SQL Server project to the solution.
I achieved this by using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from the set of SQL scripts. By adding this second project to the solution, I managed to continue taking advantage of linking the project to a live database through SQL Server Object Explorer on Visual Studio. I gave a more detailed explanation about my implementation in this answer.
I am collaborating on a project with several other people in Visual Studio 2013. We are using Tortoise SVN to share the project so that we are all working on the same files. I was in charge of constructing the database, which I did. But after making the database in the SQL Server Object Explorer under (localdb)\Projects(SQL Server 11.0.3000-THE-DRAGON-DEN\Dragonfett), I can not seem to find the database in the solution folder for the project.
How do I get the database into the project folder?
That is merely a link to a SQL Server database.
If you want the database in the solution folder then you will need some form of project. SQL Server Data Tools (SSDT http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx) is what you are looking for. AFAIK this is installed with VS2012 and VS2013. For VS2010 you will need to install SSDT manually.
Select File->New->Project and in the templates look for SQL Server Database Project under the SQL Server Template group. SSDT has a great import facility which will let you import the contents of an existing database with no fuss. SSDT as a project can then be checked into and controlled by SVN.
Other that that, Installing, configuring and using SSDAT is beyond the scope of the question. I would suggest you do a bit of homework and read up on SSDT and how it works.
I have a SQL Server Scripts 2012 Project with multiple SQL queries and stored procedures.
We use Team Foundation Server 2012 to manage our source code for our Visual Studio Solutions.
How can I check in a SQL Server Scripts 2012 Project into TFS? If it is not possible how can I manage source control on this and allow multiple developers access to it?
You have a few options, here are two that I have used.
1: Download the TFS 2012 MSSCCI Provider:
This plugin allows you to access TFS from Microsoft SQL Server Management Studio. So you can easily add and check in\out those ssmssln and ssmsproj files from TFS.
64bit Download - 32bit Download
Once installed, in SSMS go to Tools-> Options -> Source Control to select the plugin.
If you don't see it then you probably need to install the other bit version.
After you have selected the plugin in the options window of SSMS, you will have a new menu option under "File" that will allow you to Add\Open\Change items in TFS from Sql Management Studio.
To add your Scripts solution using the MSSCCI plugin:
Open the project in SSMS, go to File -> Source Control -> Add Solution to Source Control
2. Add through VS using the "Add files to Source Control"
See here: To add a file that is not in a solution to version control
I'm not quite sure why it would be a challenge to add the sql server scripts to TFS just as any other file in your visual studio solution. I've done this in a lot of projects with great success.
What is a challenge with databases though is to find a good strategy to handle branches and database versioning. I recommend that you have a look at Entity Framework Code First Migrations which handles this very nicely. Another approach is to use Chuck Norris Round house which is a more script based solution:
RoundHouse
https://code.google.com/p/roundhouse/
Code First Migrations.
http://msdn.microsoft.com/en-us/data/jj591621.aspx
If you start from scratch I would recommend the Code First Migrations approach, but if you allready have a lot of .sql files the second can work very well.
The latest versions of MSSCCI still don't seem to work with SSMS 2012 - you'll need an older 32 bit version, here: http://visualstudiogallery.msdn.microsoft.com/en-us/bce06506-be38-47a1-9f29-d3937d3d88d6
Once this is installed you'll be able to see the "Team Foundation Server MSSCCI Provider" in the SSMS Source Control Plug-In selection.
I have Visual Studio 2008 Database Edition, and everything worked great until the first time I tried to load a .dbproj file. These database project files work for the other developers I work with, but when I try to open it, I just get an error message "Object reference ot set to an instance of an object."
It's probably the same problem this guy is having, although he didn't do a good job of describing it and has no solution.
Every other kind of project file loads and builds and runs normally. dbproj files all generate this cryptic error. I just tried a fresh removal and reinstall of Visual Studio 2008 DE to no avail. Could this have something to do with my SQL 2005 installation? (This also works normally through SQL Server Management Studio.)
**
UPDATE
**
Probably even more importantly, this same error occurs when I try to make a new dbproj file. Every other type of project can be created no problem.
You need to tell Visual Studio the correct instance of SQL Server to use for validation.
Tools>Options>DatabaseTools
Change the settings in "Data Connections" and "Design-time Validation Database" to reflect the correct instance.
After many failed re-configurations and re-installations, a member of my team discovered the problem!
Under Tools > Options > Database Tools > Design-time Validation Database, there is an option to set your SQL Server Instance Name. Visual Studio automatically picks this when it's installed.
The key is that Visual Studio doesn't necessarily pick the right one. I happen to have 3 SQL server instances on my machine. SQLEXPRESS (a 2005 instance that Visual Studio installed alongside itself), SQLEXPRESS2005, a 2005 instance I installed, and SQLEXPRESS2008, which I also installed.
Visual Studio had configured itself to connect to the SQLEXPRESS2008 instance, even though it only supports SQL2005 dbproj files by default. By opening this dialogue, and updating the server instance name, the error no longer appeared and I was able to open dbproj files:
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity