Compile dependent dll into exe?
-
I have some a solution with a class library project containing some common code and a couple of Windows application projects. I have referenced the Common class library using a project reference. The copy local option is set to true. Setup this way the app.exe file produced by the Windows application projects will only run if the common.dll file is in the same directory. Is there a way, or what is the best way, to compile the common.dll into the exe so that it will be self sufficient and can be distributed without the common.dll?
-
I have some a solution with a class library project containing some common code and a couple of Windows application projects. I have referenced the Common class library using a project reference. The copy local option is set to true. Setup this way the app.exe file produced by the Windows application projects will only run if the common.dll file is in the same directory. Is there a way, or what is the best way, to compile the common.dll into the exe so that it will be self sufficient and can be distributed without the common.dll?
Since you have two distinct projects, you get two distinct assemblies, that is two distinct deliverables. It may sound strange collecting code for reusing and in the same time embedding it into the exe: this will force you to redistribute the exe instead of just the dll in event of some change in the common code. I'm not your consellour, you may have a lot ot good reason for: it is not my intention to say otherwise. Well, I think you cannot achieve your goal with just the help of Visual Studio, 'cause this is not the way distinct assemblies was designed to cooperate for. You have to brake the reference, copy your dll file into the same directory of the project files (that is, where code files are) and bring it into the project just like an image you may have compiled into exe. The you have to change the compile option: view the proerty of the file (it is just a file now: you and I know it is a quite special file, but Visual Studio don't care it). You have a property like "Generation Option" (I have italian version of the tool, let me be quite free in the traduction) which you can set to: - None (file will be left there) - Compile (you cannot compile non-code file) - Content (the file should be copied to the output dir, say /bin/debug, this not always happens) - Embedded (the file will be included into the asembly) Your option is the last. Now that your assembly is embedded, you have to use Reflection to: - find it into the assembly - load in memory from the assembly - instance what you need and invoke method by reflection It should be a good idea to incapsulate all these operation into a Wrapper that will always and solely deal with reflection and embedded common.dll. I have to say that this is a hard way: debug will become a little triker, for instance, you will not have compile-time error. You will always knows error on-the-fly at runtime. And handling those error may become a little plumbing. This was to be said, but if still remain a reason to do it, well: have a nice coding :) Just a memento :) This is what I know for true, it doesn't mean it is the only option that exists :) Sorry for my bad English too.
Parsiphal
-
Since you have two distinct projects, you get two distinct assemblies, that is two distinct deliverables. It may sound strange collecting code for reusing and in the same time embedding it into the exe: this will force you to redistribute the exe instead of just the dll in event of some change in the common code. I'm not your consellour, you may have a lot ot good reason for: it is not my intention to say otherwise. Well, I think you cannot achieve your goal with just the help of Visual Studio, 'cause this is not the way distinct assemblies was designed to cooperate for. You have to brake the reference, copy your dll file into the same directory of the project files (that is, where code files are) and bring it into the project just like an image you may have compiled into exe. The you have to change the compile option: view the proerty of the file (it is just a file now: you and I know it is a quite special file, but Visual Studio don't care it). You have a property like "Generation Option" (I have italian version of the tool, let me be quite free in the traduction) which you can set to: - None (file will be left there) - Compile (you cannot compile non-code file) - Content (the file should be copied to the output dir, say /bin/debug, this not always happens) - Embedded (the file will be included into the asembly) Your option is the last. Now that your assembly is embedded, you have to use Reflection to: - find it into the assembly - load in memory from the assembly - instance what you need and invoke method by reflection It should be a good idea to incapsulate all these operation into a Wrapper that will always and solely deal with reflection and embedded common.dll. I have to say that this is a hard way: debug will become a little triker, for instance, you will not have compile-time error. You will always knows error on-the-fly at runtime. And handling those error may become a little plumbing. This was to be said, but if still remain a reason to do it, well: have a nice coding :) Just a memento :) This is what I know for true, it doesn't mean it is the only option that exists :) Sorry for my bad English too.
Parsiphal
Thank you for the thorough reply. You have confirmed what I suspected. I will just duplicate the common code into both application projects. It seems like the simplest way to go. - Preston