Do you put unit tests in same project or another project?

In my opinion, unit tests should be placed in a separate assembly from production code. Here are just a few cons of placing unit tests in the same assembly or assemblies as production code are:

1. Unit tests get shipped with production code. The only thing shipped with product code is production code.
2. Assemblies will be unnecessarily bloated by unit tests.
3. Unit tests can affect build processes like automated or continuous build.

I don't really know of any pros. Having an extra project (or 10) isn't a con.

Edit: More Info On Build and Shipping

I would further recommend that any automated build process place production and unit tests into different locations. Ideally, the unit test build process only runs if the production code builds, and copies the product files into the unit tests directory. Doing it this way results in the actual bits being separated for shipping, etc. Additionally, it is fairly trivial to run automated unit testing at this point on all tests in a particular directory.

To summarize, here is the general idea for a daily build and testing and shipping of bits and other files:

1. Production build runs, placing production files into a specific "production" directory.
   1. Build production projects only.
   2. Copy compiled bits and other files into a "production" directory.
   3. Copy bits and other files into a release candidate directory, aka a Christmas release directory would be "Release20081225".
2. If production build succeeds, unit test build runs.
   1. Copy production code to "tests" directory.
   2. Build unit tests to "tests" directory.
   3. Run unit tests.
3. Send build notifications and unit tests results to developers.
4. When a release candidate (like Release20081225) is accepted, ship these bits.

Separate project, but in the same solution. (I've worked on products with separate solutions for test and production code - it's horrible. You're always switching between the two.)

The reasons for separate projects are as stated by others. Note that if you're using data-driven tests, you might end up with quite a significant amount of bloat if you include the tests in the production assembly.

If you need access to the internal members of the production code, use InternalsVisibleTo.