Constant redefinition warnings RX4005 when working in VO Windows-Editor

[robert]

Arne,
We can't change the behavior of the resource compiler. And it checks the text of the two defines and this text is different.

Robert

[Chris]

Guys,

I cannot understand where the duplicates come from. If there is not #include styatement, there should be no problem, the VOWED generates single defines... Arne, can you please post the exact contents of such a .rc file? Also can you send a repro sample please?

[robert]

Chris,

I think an earlier version of the VOXporter wrote the defines as 2048 where the current VOXporter and window editor now use the hex format.

Robert

[Chris]

Robert,

OK, but after removing the duplicate defines, there should be no errors any more. But Arne says he still gets those errors...

[ArneOrtlinghaus]

If there are changes in the VOXPORTER that saves the constants as hex exactly as the VO Editor, then probably the problem has been resolved on your side and we are still using an old version and have to update it.
I will check with my colleague and tell you.

[Chris]

Hi Arne,

Just to make sure we are on the same page:

- You start getting those warnings, only after you make a change in the window from the WED, is that correct? Normally the WED should not do this, it should delete the previous #defines and create the new ones. For this reason I asked you to send an .rc file to have a look into it, maybe it gives an idea why this happens

- When you delete the duplicate #defines in the .rc, are you still getting the duplicates again when making another save in the WED? I am really surprised if that happens indeed, so would again like to have a look at such an .rc file

- So, what I am trying to say, is that the VOXporter should not have an impact on that, because no matter what the #defines in the .rv file originally look like, the WED should be recreating them correctly every time you save the window. Unless there's something causing it not to, maybe some contents inthe .rc file that it does not expect, so I would really like to see a sample.

[robert]

Chris,
The RC compiles all the resources in one go. So if one form has a define in decimal format and another form in hex format then the warning will be shown.
And I do not think Arne is editing all forms at once.

Robert

[Chris]

Robert,

Ahh thanks, it does indeed...I just realized that I am just hiding those warnings in XIDE

So I guess right now it's not possible at all to disable those warnings, right? Maybe you can also make the build system ignore those warnings in VS as well? Maybe optionally?

[robert]

Arne, Chris,

Let's step back a bit and analyze why we are seeing this problem:
the roslyn compiler allows only one unmanaged resource to be bound to the managed assembly. So we have to combine the various unmanaged resources into one file. We do that by calling the resource compiler with one response file that joins all unmanaged resources. This response file is %TEMP%LastXSharpNativeResourceResponseFile.Rsp
For the standard MDI app this file looks like this:

Code: Select all

#define __VERSION__ 2610
#include "C:Program Files (x86)XSharpincludeNativeResourceDefines.xh"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Menus.EmptyShellMenu.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Menus.EmptyShellMenu_Accelerator.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Menus.StandardShellMenu.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Menus.StandardShellMenu_Accelerator.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Menus.VS_VERSION_INFO.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Shell.IDI_STANDARDICON.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Standard Shell.Manifest.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Help About.HelpAbout.rc"
#include "C:UsersrobertsourcereposVOMDIApp1VOMDIApp1Help About.POWXSHARPBMP.rc"

If there is a definition for a #define on one rc file that is different from the same definition in another rc file than this warning is shown.
Unfortunately the resource compiler does not have a commandline option to suppress certain warnings.
I see a couple of solutions:

1) Suppress the warning RC4005 inside the VS IDE. This is what XIDE is doing and relatively easy. However this would not suppress the warning when building on a build server. And I think Arne is using a build server too.

The call to RC.EXE is driven by a component inside XSharp.Build.Dll. I could do several things in here:

2) Analyze each rc file and find the #define lines in these files and add extra lines to LastXSharpNativeResourceResponseFile.Rsp to #undef each define that was defined. This would cause the RC compiler to start "fresh" with each RC file and would still produce warnings when one RC file has two conflicting #define lines.
This is a bit work and could slow down native resource compilation a bit (I am not sure if you would notice that though) but is a very clean solution

3) Intercept the RC .EXE output and filter out lines with warning RC4005. This would work but would also suppress legitimate warnings when a single .rc file has a conflicting define

4) Compile each .rc file individually into a .res file and add a step that merges these .res files into one large compiled resource (We would have to figure out how to do that of course). The advantage is that a change to a single rc file would no longer trigger recompiling all RC files, but of course this new tool has to be tested.

5) Switch to a new (open source) resource compiler (for example http://www.angusj.com/resourcehacker/) so we have more control over things

The simplest solution is 1), suppress in the IDE.
I think the cleanest solution that also works on build servers is 2).
Number 3) is easier to implement that number 2) and has less impact on compilation time, but will suppress legitimate warnings too.
Ideally I would want to go to 4) or 5).

Please let me know what you think about this.

Robert

[Chris]

Robert,

Based in what you said, maybe the best solution is to make the VO editors automatically add the #undefs at the end of each .rc files, for each #define that they emit? I just tried doing it and it seems to work well! If you agree, I will commit those changes.