It is not so weird, I think it is all explained in the links posted above. In short, what the compiler does in order to include version info in the exe/dll files it produces, is to read the assembly info code, translate it to a native resource version information (which is required by the OS) and then embed it into the output. That's what also the c# compiler does.
Problem is that it's allowed to have only one native (Win32) resource per assembly, so if there are other resources already included in the app (like for windows etc), then this mechanism cannot work, and, instead, you need to supply a version info native resource manually, as discussed before. This is never a problem in c#, because c# apps typically do not use native resources for anything else, while those are absolutely necessary in VO ported apps, for DataWindows, Menus end similar VO entities to work at runtime.
Having said that, we have been discussing this today and decided that Robert will give it a try to make the compiler actually merge the assembly info resource with the other native resources needed for VO style apps. This is quite complicated and not guaranteed to work, but will give it a try and if the result is successful, then in one of the next X# builds it will be possible to always provide just the AssemblyInfo.prg attributes for version info. No promises yet, though!
product information in converted VO application
product information in converted VO application
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
product information in converted VO application
Thanks for the heads-up... Looking forward for that features.Chris wrote:It is not so weird, I think it is all explained in the links posted above. In short, what the compiler does in order to include version info in the exe/dll files it produces, is to read the assembly info code, translate it to a native resource version information (which is required by the OS) and then embed it into the output. That's what also the c# compiler does.
Problem is that it's allowed to have only one native (Win32) resource per assembly, so if there are other resources already included in the app (like for windows etc), then this mechanism cannot work, and, instead, you need to supply a version info native resource manually, as discussed before. This is never a problem in c#, because c# apps typically do not use native resources for anything else, while those are absolutely necessary in VO ported apps, for DataWindows, Menus end similar VO entities to work at runtime.
Having said that, we have been discussing this today and decided that Robert will give it a try to make the compiler actually merge the assembly info resource with the other native resources needed for VO style apps. This is quite complicated and not guaranteed to work, but will give it a try and if the result is successful, then in one of the next X# builds it will be possible to always provide just the AssemblyInfo.prg attributes for version info. No promises yet, though!
For now, I will do a lot of typing....
--
Rene
product information in converted VO application
Given, that we await the new Vo-GUI style classes which, AFIAU are based on Winform classes, isn't this a problem which will become obsolete?Chris wrote:... while those are absolutely necessary in VO ported apps, for DataWindows, Menus end similar VO entities to work at runtime.
Having said that, we have been discussing this today and decided that Robert will give it a try to make the compiler actually merge the assembly info resource with the other native resources needed for VO style apps. This is quite complicated and not guaranteed to work, but will give it a try and if the result is successful, then in one of the next X# builds it will be possible to always provide just the AssemblyInfo.prg attributes for version info. No promises yet, though!
If so, i think que este no vale la pena
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
product information in converted VO application
Hi Karl,
AFAIK the new GUI classes will be available only to FoX members.
And personally I don't think all VO applications can be moved to these classes, at least not until bBrowser is also available for these. And maybe there is someone that has added important changes and enhancements to the GUI classes and is not able to port them to the new classes (for example, I have seen heavily extended ListView classes).
So I'm pretty sure .rc files will be around for several years....
Wolfgang
AFAIK the new GUI classes will be available only to FoX members.
And personally I don't think all VO applications can be moved to these classes, at least not until bBrowser is also available for these. And maybe there is someone that has added important changes and enhancements to the GUI classes and is not able to port them to the new classes (for example, I have seen heavily extended ListView classes).
So I'm pretty sure .rc files will be around for several years....
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
product information in converted VO application
The WinForms GUI classes still depend on the .rc files. They are (largely) compatible with the VO GUI classes and the code that the VO WED generates is using resources for the form definitions, so that remains the same.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu