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 filedbschema.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.