I mentioned in one of my comments to simoraman's answer that I had thought of a couple of ways to do this. One of my options was similar to the suggestion in Jalayn's answer to created a duplicate project and generate a DLL, while my other idea was to simply link to the files in the project where there was code I wanted to test. While both options could be made to work, they are less than ideal.

In the second case, I'd have a mess of unit dependencies to manage unless I could really tease apart the architecture to minimize dependencies. This is fine for smaller projects, but larger ones could easily become a real mess to manage. My biggest resistance to this option however is the sheer inelegance of it. Sure I could get it to work, but in doing so I effectively need to break encapsulation to test the internals of an assembly directly via source, rather than testing the via the public interfaces, which in my mind is a big no-no. Likewise having an additional project file would mean either duplicating efforts in two projects at a time, or finding a way to add project file settings automatically to two files at a time, or remembering to copy and rename the project field each time I build. This can be automated on the build server perhaps, but would be a pain to manage in the IDE. Again, it can work, but it's a kludge at best, and a nuisance at worse if you get it wrong.

The best way seems to be to do as whatsisname commented to my question, and to simply include the EXE as a reference in the test project. It turns out that an EXE is effectively treated the same way as a DLL in this case, and I am able to access all of my nicely layered classes to test whatever floats my boat.

I mentioned in one of my comments to simoraman's answer that I had thought of a couple of ways to do this. One of my options was similar to the suggestion in Jalayn's answer to created a duplicate project and generate a DLL, while my other idea was to simply link to the files in the project where there was code I wanted to test. While both options could be made to work, they are less than ideal.

In the second case, I'd have a mess of unit dependencies to manage unless I could really tease apart the architecture to minimize dependencies. This is fine for smaller projects, but larger ones could easily become a real mess to manage. My biggest resistance to this option however is the sheer inelegance of it. Sure I could get it to work, but in doing so I effectively need to break encapsulation to test the internals of an assembly directly via source, rather than testing the via the public interfaces, which in my mind is a big no-no. Likewise having an additional project file would mean either duplicating efforts in two projects at a time, or finding a way to add project file settings automatically to two files at a time, or remembering to copy and rename the project field each time I build. This can be automated on the build server perhaps, but would be a pain to manage in the IDE. Again, it can work, but it's a kludge at best, and a nuisance at worse if you get it wrong.

The best way seems to be to do as whatsisname commented to my question, and to simply include the EXE as a reference in the test project. It turns out that an EXE is effectively treated the same way as a DLL in this case, and I am able to access all of my nicely layered classes to test whatever floats my boat.

I mentioned in one of my comments to simoraman's answer that I had thought of a couple of ways to try and do this. One of my options was similar to the suggestion in Jalayn's answer to created a duplicate project and generate a DLL, while my other idea was to simply link to the files in the project where there was code I wanted to test. While both options could be made to work, they are less than ideal.

In the second case, I'd have a mess of unit dependencies to manage unless I could really tease apart the architecture to minimize dependencies. This is fine for smaller projects, but larger ones could easily become a real mess to manage. My biggest resistance to this option however is the sheer inelegance of it. Sure I could get it to work, but in doing so I effectively need to break encapsulation to test the internals of an assembly directly via source, rather than testing the via the public interfaces, which in my mind is a big no-no. Likewise having an additional project file would mean either duplicating efforts in two projects at a time, or finding a way to add project file settings automatically to two files at a time, or remembering to copy and rename the project field each time I build. This can be automated on the build server perhaps, but would be a pain to manage in the IDE. Again, it can work, but it's a kludge at best, and a nuisance at worse if you get it wrong.

The best way seems to be to do as whatsisname commented to my question, and to simply include the EXE as a reference in the test project. It turns out that an EXE is effectively treated the same way as a DLL in this case, and I am able to access all of my nicely layered classes to test whatever floats my boat.

I mentioned in one of my comments to simoraman's answer that I had thought of a couple of ways to do this. One of my options was similar to the suggestion in Jalayn's answer to created a duplicate project and generate a DLL, while my other idea was to simply link to the files in the project where there was code I wanted to test. While both options could be made to work, they are less than ideal.

In the second case, I'd have a mess of unit dependencies to manage unless I could really tease apart the architecture to minimize dependencies. This is fine for smaller projects, but larger ones could easily become a real mess to manage. My biggest resistance to this option however is the sheer inelegance of it. Sure I could get it to work, but in doing so I effectively need to break encapsulation to test the internals of an assembly directly via source, rather than testing the via the public interfaces, which in my mind is a big no-no. Likewise having an additional project file would mean either duplicating efforts in two projects at a time, or finding a way to add project file settings automatically to two files at a time, or remembering to copy and rename the project field each time I build. This can be automated on the build server perhaps, but would be a pain to manage in the IDE. Again, it can work, but it's a kludge at best, and a nuisance at worse if you get it wrong.

The best way seems to be to do as whatsisname commented to my question, and to simply include the EXE as a reference in the test project. It turns out that an EXE is effectively treated the same way as a DLL in this case, and I am able to access all of my nicely layered classes to test whatever floats my boat.