A previous poster listed Liquibase as an option, however they failed to mention Liquibase's ability to define rules which run in particular contexts (Contexts in Liquibase). This allows you to have the schema updates not marked with any particular context and the fixtures for the unit tests marked as a context of test. This way, the fixtures will only be inserted when you run your unit tests.
Here is an example of a Liquibase change set that contains the schema and the fixtures:
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.9" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.9 http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
<changeSet author="avalade" id="1">
<createTable tableName="users">
<column autoIncrement="true" name="id" type="long">
<constraints nullable="false" primaryKey="true" />
</column>
<column name="email" type="varchar(255)" />
</createTable>
</changeSet>
<changeSet author="avalade" id="2" context="test">
<insert tableName="user">
<column name="id" value="1" />
<column name="email" value="test@test.com" />
</insert>
</changeSet>
</databaseChangeLog>
Then, if you're using Spring to manage your DAO's, you could put the following in your Application Context file that you're deploying:
<bean id="liquibase" class="liquibase.spring.SpringLiquibase">
<property name="dataSource" ref="dataSource" />
<property name="changeLog" value="classpath:dbChangelog.xml" />
</bean>
For the Application Context file that you use in your unit tests, configure Liquibase with an additional context property:
<bean id="liquibase" class="liquibase.spring.SpringLiquibase">
<property name="dataSource" ref="dataSource" />
<property name="changeLog" value="classpath:dbChangelog.xml" />
<property name="contexts" value="test" />
</bean>
This way, you can keep all of your database definitions together in one place and only insert your fixtures when you're running your test code.
The .NET runtime does not unload an assembly until the application domain is shut down (typically when the process exits but its possible to create multiple application domains in a single process).
I think you will need to shut down the other services, remove the policy file and the new assembly, then restart all the services involved.
Best Answer
You will find this all much easier if you switch to TeamCity. I've wrestled with so many nant scripts/cruisecontrol config files in the past I'm almost blind from angle brackets.
I cried like the accountant who was shown the first spreadsheet program when I started messing with TeamCity. It will make your life 1000% easier.