I have a solution with two projects. One for project for the production code and another project for the unit tests. I did this as per the suggestions I got here from SO.
I noticed that in the Debug Folder that it includes the production code in executable form. I used NUnit to run the tests after removing the executable and they all fail trying to find the executable. So it definitely is trying to find it. I then did a quick read to find out which is better, a DLL or an executable. It seems that an DLL is much faster as they share memory space where communication between executables is slower.
Unforunately our production code needs to be an exectuable. So the unit tests will be slightly slower. I am not too worried about that. But the project does rely on code written in another library which is also in executable format at the moment.
Should the projects that expose some sort of SDK rather be compiled to an DLL and then the projects that use the SDK be compiled to executable?
Just because it’s an executable file doesn’t mean it’s being loaded as a separate process.
In .NET you can load an EXE file as an assembly just as easily as a DLL. That’s what’s happening in this case (I’d imagine, anyway) – no cross-process communication, no problem.
If you’re genuinely testing something which should logically be an executable, then that’s fine.