Problems like this show us that the people who make SQL server have never actually used their product. This is such a glaring omission that one has to wonder what else they simply forgot to do correctly (I've got a list of about 30 other maddening issues like this that I've had to overcome to make this work as other DBs do out of the box; including the fact that we need a lousy wizard to do this in the first place [if I had the time I've spent waiting for this wizard to connect and enumerate the same tables for the same DB, every time, back...I'd have time for a nice vacation]).
I'm very lazy and don't want to type
EXEC sp_msforeachtable ... twice every time I do this. My work around has been to leave the constraints on the production server and remove them from the dev server. This will prevent the error but this method does have a few VERY BIG side effects. First, you will no longer be able to just restore a full backup to your dev server (unless you're OK with removing them all again). Second, this works best when you are sure that the consumers of your data also enforce these constraints (or do not care about them). In my case, we only have one consumer (our website) so we've built these constraints into the site code as well (ie before we delete a user record we delete all phone records for that user first). Yes, this essentially negates the need for constraints in the first place and doubles the work that I need to do but it also gives me a chance to verify that my code works with or without DBMS based constraints (the fact is that they are still on the prod server only as a contingency plan). You could call this a flaw in my design but I'd rather call it a workaround for a flawed DBMS. At any rate, it's still quicker and easier to do this anywhere else than from within MSSQL because it is unable to cope with it's own design.