Wolfgang,
It will be very difficult to do it the way VO does it, at least without sacrificing performance.
The build process in VS is based on MsBuild and actually runs outside of VS. At the time that the build process compiles the resource items (these are represented with items of type NativeResource in the XSPRoj file) then MsBuild calls a special task special task "NativeResourceCompiler " inside XSharp.Build.DLL "knows" how to create a file NativeResources.Res from the RC files. This task checks for the existence of this file and compares its timestamp with the timestamps of the RC files in the project.
Lets assume you are building MyApp.DLL. Then the task inside XSharp.Build.DLL in theory could read the list of dependencies for MyApp.DLL and use reflection to read all the defines in these and find the defines (constants) in these DLLs and do a search and replace on the RC files. Of course we would not want to change the original file, so we would have to create copies of all RC files introducing the problem that I mentioned in my reply to Dick: error messages from the resource compiler will no longer point to the original files.
But even is that acceptable, there is a second problem:
For the source from MyApp.DLL there is no DLL to reflect (because that DLL is being built) or an older copy of the DLL.
To find all the DEFINES in this source the NativeResourceCompiler task therefore would have to read all source files in the project and extract the info for the defines.
In VO this is not an issue because at the time when the resources are compiled all the source has been parsed (not necessarily) compiled and all the info is available.
The only thing that I can think of at this moment is that the VS project system would write all the defines for a project into a separate file which could be read by the NativeResourceCompiler task. However that would not work on Build Servers, because on these machines there is NO VS running.
And of course the problem remains that the error messages will point to the wrong files.
To help solve the problem we have done the following for RC files that are generated by the form editor and menu editor: we do not #include a file with defines, but we write all the #defines directly in the RC files. We even write the defines for the windows styles so there is no dependency on any external file:
Code: Select all
#define DIALOG_PUSHBUTTON1 100
#define DIALOG_MULTILINEEDIT1 101
#define DS_3DLOOK 0x00000004
#define DS_MODALFRAME 0x00000080
#define ES_AUTOHSCROLL 0x00000080
#define ES_AUTOVSCROLL 0x00000040
// etc
MySuperDialog DIALOGEX 3, 3, 265, 146
STYLE DS_3DLOOK|WS_POPUP|WS_CAPTION|WS_SYSMENU|DS_MODALFRAME
CAPTION "Designed Dialog"
FONT 8, "MS Shell Dlg"
BEGIN
CONTROL "Close", DIALOG_PUSHBUTTON1, "BUTTON", WS_CHILD|WS_TABSTOP, 155, 109, 66, 20
CONTROL "", DIALOG_MULTILINEEDIT1, "EDIT", WS_CHILD|ES_MULTILINE|WS_TABSTOP|WS_BORDER|ES_AUTOVSCROLL|ES_AUTOHSCROLL|ES_WANTRETURN, 13, 9, 221, 86, WS_EX_CLIENTEDGE
END
I think the only real problem are the RC files of type ICON, CURSOR, BITMAP and similar. They can no longer use a DEFINE for their name but need to use the correct literal.
If you can think of a smart solution that should take care of this (without sacrificing performance), then please let me know.
For versioninfo resources I would use the following approach:
- define the version numbers in a separate header file
- include that header file in your version resource
- include the same header file in the assemblyinfo.prg to set the managed version information.
We have done something like that for the versioning of GUI classes in the SDK in the Vulcan days.
Code: Select all
#include "BuildNumber.h"
VS_VERSION_INFO VERSIONINFO
FILEVERSION FILEVERSION_NUMBER
PRODUCTVERSION VERSION_NUMBER
FILEFLAGSMASK 0x37L
#ifdef _DEBUG
FILEFLAGS 0x3L // VS_FF_DEBUG + VS_FF_PRERELEASE
#else
FILEFLAGS 0x0L //
#endif
FILEOS 0x00040000L
FILETYPE 0x2
FILESUBTYPE 0x0L
BEGIN
..
..
END
and inside Assemblyinfo.prg
Code: Select all
#include "BuildNumber.h"
[assembly: AssemblyVersionAttribute( VERSION_NUMBER_STR )]
[assembly: AssemblyFileVersionAttribute( FILEVERSION_NUMBER_STR )]
... etc
Robert
.