We have a large production database that is using a custom version control that allows for seamless upgrades when the schema changes (each change script is versioned). Everything works well.
Can we use the data-tier application programming model side-by-side within an existing database? We would like to try the DAC approach without converting our database to a Data-Tier application. It would be ideal to segregate the data-tier application from the rest of the database at a schema level. Let's say we have three schemas, dbo, my and dac. We would like to continue managing dbo and my by hand and use dacpacs to automatically migrate everything in the dac schema.
We've tried a few tests and it seems like Data-Tier Application Framework does not like competition - it detects objects outside of its scope as "manual changes" and tries to drop them upon the import. Is there a way of changing this behavior?
The answer here is "more or less, but with some work". Ideally the DAC framework is intended to model an entire database but can be configured in a number of ways to overcome this.
One way is to ensure "drop objects not in source" is set to false in any publishing configuration. This is in the advanced publish settings and can be configured on the command line etc. The downside of this is that when you delete an object in the dac schema it won't be dropped in the
For a more complete solution you would need to use a deployment contributor to filter any steps relating to schemas other than "dac". The starting point is "Solution 2: Filtering at deployment time" in the DacFx tutorial I wrote (source code here). This shows how to filter out Create steps - you'd actually want to extend that to drop steps too. The benefit is more control and a better match to your solution, the downside is needing to write some custom code and include that in your setup.
Note that whatever you do, you'll still find that schema compare and other tools show the alternative schemas. You can configure schema compare to filter out those other schemas, and save the comparison file with those settings for use in the future.
In addition, you do need to be disciplined about not having references to the other, manually managed schemas from dac schema. There is support for writing custom code analysis rules to enforce this, or you could just enforce it through code reviews etc.