Preliminaries
The ideas and discussions in this article are only relevant if your programming environment is MSVC6 or if you have some MSVC6 workspace project lying around that you are intending to give it a new name. Sample executable uploaded (src update pending).
Introduction
At certain point during a project's implementation cycle, I found myself, in many instances, writing code that is ideal to serve as a base framework for new applications. Usually when that happens, I either start a new CVS branch (bad practice) or manually copy all existing files to a new directory for archive.
A problem appears later on when I attempt to reuse the same project files as a starting point for a new project. I cannot rename an existing MSVC6 project! This seems like a simple task at first. The problem though is that simply renaming the project filename does not automatically cause the workspace project title inside MSVC6 to change. Furthermore, simply changing the filename doesn't necessarily mean the generated executable will be named differently.
A bit of hack reviews that the workspace project title (as shown in the top image) can be renamed by altering a .dsp file. It was discovered that the executable name (debug and release) and all associated libraries are all contained inside a project .dsp (just like a Makefile). Thus a few search and replace on a .dsp file quickly accomplished what we set out to achieve.
The current implementation does exactly that. A search and replace strategy to look for existing workspace project name and replaces it with new name. The output, after running the app, is two new files (.dsp and .dsw).
I would like to emphasize again that this strategy enables all include libraries to remain intact. This is very important especially if you work with lots of third party libraries (I work with directshow, opencv, ipl and and few of my own).
The difficulty in renaming an existing workspace project title is summarized in this post. The suggested solutions seem to be consistent with my own findings. (A quick search on Google will review millions more.)
How it works
STL based search and replace. CString is not portable. Avoid at all cost.
How I use it
Assume that I have a solid working project in CVS.
- To start off a separate project, copy (checkout) the whole project directory - (!) no CVS residual - to another location.
- Rename directory.
- Execute renameDsw.exe to generate new project name and executable name.
Concluding remarks
Depending on your line of work, this little utility could be quite handy especially if you require different compilation and linkage parameters for various builds. For example, say, you have multiple implementations of a LIB file targeted for different machine architectures. Based on an existing working application, you can generate separate projects and add them back to the current workspace as shown below. Each project now, under the same workspace, has different compilation and linkage parameters.
The current implementation utilized a separate MFC app to perform the search and replace task. Other implementations of course are also possible. i.e.: Marcos and App wizard etc...
Finally, I would like to comment on the reasons why I did not consider generating App wizard template. In fact, many of the template code are ideal to go into an App wizard template.
The primary reason that I did not go that route is because I found myself with numerous template applications that are compiling and executing solid. Generating different App wizard template involves investing more time resource for each different working project. I prefer simply copying from CVS and generating a new name from there.
Anyhow, I hope this could benefit someone who is still working with MSVC6 like me.
