I have a C console program in VS2010 that I would like to edit/debug/build as a single project. That is, I would like to write it and debug it as if it were a vanilla console exe, but have it produce a dll as a byproduct. I found the following info on SO (Making a C# project DLL and EXE)
The DLL project should have all your re-usable code. The normal project should be the application you are building, which will reference your re-usable DLL. This way you can build a framework in the DLL project that can be used for any of your future projects.
Elsewhere on SO, I found this: https://stackoverflow.com/questions/7054481/how-to-produce-a-mix-of-dll-and-exe-in-one-c-sharp-project
you can reference a .Net executable as if it were a dll anyway, but you could consider copying the exe file to a dll file with the same name…
You can automate this process using a Visual Studio post-build event for your project. This will handle creating the dll copy each time you have a successful build:
copy “$(TargetPath)” “$(TargetDir)$(TargetName).dll”
It seems like the first option means maintaining 2 difft projects. Is there a reason to do this instead of doing what the second post advises, and just copy my exe whole hog and change the extension from exe to dll?
Hans Passant answered the question, but I can’t mark it as answered because it is a comment. So here is his answer:
“This is possible in a managed language but not in C. A native DLL has different CRT startup code. And a native EXE is not relocatable and doesn’t support exported functions. The bigger question is, if it were possible, what you’d write in your main() function. That you couldn’t write in your EXE project’s main() function. Write unit tests only to test exported functions since that is the only thing available to any code that uses your DLL. Also consider a 3rd project that creates a static library, one you can link both in your DLL and EXE projects”