Archived

This topic is now archived and is closed to further replies.

BriTeg

Visual C++ and linking MFC confusion

Recommended Posts

I''m having troubles understanding/figuring out the best way to link with MFC. I''ve read all the documenation I could find, but I''m still somewhat confused. Here''s my project layout: 1. My main .exe needs MFC. 2. My main .exe supports plug-ins (.dlls) 3. I will be providing a tool-kit (sample plug-in project) so other programmers can write plug-ins for my app. Plug-ins can use MFC if they want, but I don''t want to force them to. I also want to give other developers the choice between using VC++ 6.0 or .Net compilers. 4. Both the main .exe and plug-in .dlls require to link to my own static .lib. This .lib needs a couple of the MFC classes. Monkey-wrench: Visual C++ 6.0 Standard does not allow static linking of MFC, but rather only use of MFC from your app via the MFC .dlls. Pro and Enterprise allow you to statically link with MFC, so you don''t have to distribute the MFC .dlls with your app. OK, now my questions: 1. Since my .lib needs some MFC classes, are these statically linked into the .lib? If not, why not? 2. If a plugin or the main .exe uses the same MFC classes that the lib needs, but the plugin is compiled on VC++ Standard (ie. needing to dynamically link with MFC), will this cause a clash with the same classes already used in the .lib? 3. Will statically linking to MFC in my main .exe clash with dynamically linking to MFC in a plug-in .dll? 4. Are the redistributable MFC .dlls from VC++ 6.0 compatible with those from .Net? If one programmer builds a plug-in that needs MFC on 6.0, and another programmer builds a plug-in that needs MFC on .Net, are both sets of MFC .dlls needed? If so, will they clash? Thanks for any insights.

Share this post


Link to post
Share on other sites