We have used Visual Studio 2010 database projects for several internal or single-user projects since they were first introduced and they have worked perfectly for us so far. Now we use them for the first time with a “boxed” product that needs to be packaged for installation on arbitrary customer sites.
All that I have seen so far suggests that I send the file .dbschemaplus the tool vsdbcmdand its requirements as part of my MSI, and then run this tool as part of the installation.
Is this really the easiest way to accomplish this task? We are doing this for our initial beta testing, but so far it seems like a quick hack rather than a good long-term deployment strategy. In particular, before installing our software, we are forced to install both SQL Server CE 32-bit and SQL Server CE 64-bit on a computer. Each attempt to pack what we only need in MSI failed because we lacked an assembly from a particular architecture.
The other thing we looked at was sending the output files sqlcmdthat are created when we “deploy” the project at build time, but this includes the name of the hard-coded server of our internal development server (and its non-SQLCMD variable, like the database name) , that is, we had to edit the .sql script during server installation. Again, this works, but it seems like a bad idea in general.
Our final approach, and what we are likely to end up doing for production, if I can't come up with something beter, is to create creation and update scripts manually based on the deployment results, and then include a custom tool with ours which executes scripts (through SqlClientor sqlcmdor something similar) based on user interaction, but this, apparently, causes great damage to the goals of the database projects.
Are there any other ways to create and build a DB2 VS2010 project for automatic deployment on different servers that does not involve installing two versions of SQL CE and sending part of Visual Studio using our installer?
source
share