using dbschema.exe

After declaring and compiling your domain (i.e.
your domain object classes), you use dbschema.exe
to derive an sql-script from it. This sql-script in
turn sets up your database for persisting instances
of the domain object classes.

The canonical way to develop a re-motion application
is to have

a domain project with all the domain object classes
a sample project or test project for exercising those domain object classes,
typically a console application
(eventually, you will also have a web project, but this is beyond the
scope of this page)

This is called the canonical project structure. If you have
not read the page canonical project structure yet, please
do so. The following explanation will assume the
canonical project structure.

If you have a sample project that will use the domain
object classes, you can use the application's App.config
(App.config) for telling dbschema.exe what the
name of the database is. If you don't specify an App.config
file, dbschema.exe will generate a USE DatabaseName –
for first experiments this is easy to fix manually, of course.

The output file, the sql script for setting up the database,
is named (SetupDB.sql). It does not matter where you store it,
but we invoke dbschema.exe in the solution root, i.e.
the parent directory of all sub-projects. For the PhoneBook
project, this invocation looks like this:

Remotion\net-3.5\bin\debug\dbschema.exe /basedirectory:PhoneBook.domain\bin\debug /verbose /config:PhoneBook.Sample\App.config

The /basedirectory is the directory with the domain assembly (can be more than one)
The /verbose switch gives you more comprehensive error messages in the case something goes wrong
The config switch specifies which configuration file dbschema.exe shall use

If everything works out, dbschema.exe has no output.
Both /verbose and /config are optional. As explained above, dbschema.exe
will generate USE DatabaseName instead of USE PhoneBook (for example),
so that you have to fix the database name manually.

See also