.

There are two ways to create separate locale specific DLLs. One is to have a single DSP with locale specific configurations. The other is to have a separate DSP for each locale. The advantage of the single DSP is that it is slightly faster to create and there are fewer projects to keep track of. The advantage of having a project for each locale is that the configurations end up being matched across the main and all resource projects.

A word of warning- one of the silly little things that Microsoft's Developer's Studio likes to have when building a complicated workspace with a lot of project is for the configurations to share the same name. If you try to build a Proj1 with ConfigA as the active project and that project is dependent upon Proj2 but Proj2 doesn't have a ConfigA of its own, then Developer's Studio will simply choose the default configuration. If that default configuration doesn't happen to play well with Proj1 then that's just too bad. The lesson from this is to make darn sure that all of your projects' configurations follow a naming convention and there is never a case where Developer's Studio has to deal with unmatched configuration names.

That brings us back to our honking big single DSP that is going to be tasked with the support of all locales. We can’t really mix the resource DSPs with the main DSPs because the resource DSP's are going to have configurations that don't exist in the main DSPs. This means we end up with separate workspaces for the main and resource builds. There will be more on this later.

All projects have to exist somewhere. In this example, let's assume that each of the individual resource DLL projects live under main project that the resource is to service. To help keep the difference between a main project and its resource project clear, the resource project is the base module’s name plus ‘res’ appended to it. For example, if the main project is Center.dsp then its resource DLL project will be CenterRes.dsp.

One other little thing to keep in the back of your head before we cruise on. Where is the project's RC file? Normally, every project gets its own. In a resource only DLL, such is not the case. Instead, the resource only DLL shares the RC that is in the main project. The reason for doing this is so that the main project can make use of the RC during normal development. For example, if a dialog were to existing only in the resource DLL then it would be a lot harder for the main project to construct a class to handle the dialogbox template. By having the RC file continue to live in the main project and letting it be shared with the resource DLL, this sort of problem goes away.