I have created a sample VS 2019 solution containing three projects. The first is an application; the second is a static library; and the third is a dynamic library. By adding references to projects 2 and 3 to project 1, I am able to ensure that the a and so files are passed in project 1’s build process so that I can successfully link to them. But when project 1 is deployed, only its executable seems to end up in the container, and the required so from project 3 doesn’t get included. What option can I use to include this file?
Greetings @MikeGranby,
Just so I have a clear idea of what you’re doing, of your 3 projects you only want 1 container produced, that being the application project container. So you were able to include the library from project 2 but for some reason the same process doesn’t work for project 3’s library, correct? Additionally could you describe the configuration you did to reference project 2 and 3 to project 1?
While I’m not too familiar with Visual Studio itself, I do have some ideas. Perhaps after building project 2 & 3 you could add their output libraries to project 1 via Project > Add Existing Item. Additionally you may also need to change the project properties to link to these libraries if you haven’t already.
Another question I have is, are these libraries for runtime or buildtime of the application? I ask because our extension typically creates an intermediary container for building. This is such that buildtime libraries don’t end up in the final application container, for a lighter solution.
Best Regards,
Jeremias
Correct, I would like all three projects to end up in the same container. My final application will have a couple of dozen executables (all of which will lives in their own projects), plus a number of static and dynamic libraries.
To add the reference, I right-clicked on the References section of project 1, and selected Add Reference. This worked in that it added the .a and .so file as build inputs to the project, allowing them to be linked, but it did not add the .so file to container image. Since the .so is required at runtime, this means that the application can’t execute. (I say it added the files as build inputs, but that wasn’t reliable. It seemed to need a couple of build cycles to pick up the files, with the linker complaining that the input .a and .so didn’t exist the first time around. I have the Build Dependencies set to force the correct build order, but it’s still not reliable.)
Re using Add Existing Item, this is difficult as the .so would exist in multiple forms depending on, for example, whether it’s a debug or release build, and adding a reference to a build output to the project like this isn’t something I’ve seen done before.
All right I ran by this scenario with some other team members internally who are more versed with Visual Studio than I.
Here’s the feedback/suggestion I got. Perhaps try putting the libraries/executables in subfolders of the main one (or create a parent folder for all of them) and build them together. The build system may then need to be modified to integrate the extra folders, (cmake has native support for it, but you can do that with any build system).
Best Regards,
Jeremias