Reputation: 2170
Probably a pretty fundamental question. When developing a single-project-solution in MSVC++ everything makes a lot of sense, every file is visible to the compiler. When moving to a multiple project solution, none of the interface elements governing project dependence seem to make sense (coming from a .net background.)
For starters it appears setting up project dependencies with that terminology seems to only imply what order the projects are compiled in. There is no more function attached to the definition and addressing objects or methods of one project from another will not work. #including the headers of the dependency doesn't seem to work either, so the dependent project cannot see the files of its dependency. Copying a link of a header from one project to another doesn't work either, where for two projects under the 'Header Files' section, the same file is referenced in both locations. Even with this header references do not work and the files are unconnected. The only way of creating a functional dependency is to add the dependency's paths to the linker/compiler search path of the dependent or worse, simply copying the files of one project to another.
Either I'm missing something or the .NET Visual Studio IDEs have succeeded at what the VC++ IDE has badly failed at.
Edit:
For the sake of asking a specific question, take the following steps for creating a solution in VC++ and I ask if the missing step(s) can be filled in:
Preferably fill in the missing step(s) with the most most modern/industry standard/best practice method that best maintains project modularity as intended.
From this I would expect to independently be able to extrapolate and create classes, enumerations etc. in the DLL class and access them all in the executable project, so long as I can find out how this is intended to be done.
Upvotes: 1
Views: 193
Reputation: 179779
In step 2, as per the usual C++ rules, declare the method in the header. Read up on __declspec(DllExport)
since the default is that methods are internal to the DLL.
In step 5, as per the usual C++ rules, include the header. Visual C++ needs to know where the header is coming from, so you need to reference the source project. Details vary between Visual Studio versions.
In step 6, you call the method in the normal way. Since it's now declared as __declspec(DllImport)
, the compiler will leave it to the linker, and the linker will get it from the correct DLL.
Upvotes: 1