X10.1 Berlin Manifest Files

FinalBuilder 8.0.0.1750
Delphi 10.1 Berlin

Not necessarily a "bug" - but hoping there is something that can be figured out so these function with the settings in the DPROJ that tell the IDE they are enabled and get used.
It seems the auto-generate isn't handled by FB, and the settings detailing what goes in the below values if the option is enabled/disabled are not handled at all.

Attempting to use Default manifest results in direct insert of manifest - only, with X10.1 Berlin, the default manifest now has MACROS embedded that are not evaluated
$(asmv3_application)
$(dependency)
$(trustInfo)

e.g. the $(dependency) equates to the following when Runtime Themes are enabled
 
     
          <>
              type="win32"
              name="Microsoft.Windows.Common-Controls"
              version="6.0.0.0"
              processorArchitecture="x86"
              publicKeyToken="6595b64144ccf1df"
              language="*"
          />
     
 

the $(trustinfo) equates to the following when Require Admin is NOT checked:
 
   
     
        <>
          level="asInvoker"
          uiAccess="false"/>
       
       
 


Final builder also does not load/use the "Auto-Generate" or check box settings from the .DPROJ file for Berlin projects (have not extensively tested this, as all project have ultimately been upgrades of previous version to Berlin)

The current work around is to hand code a new default_app.manifest and save it to the product folder and use it as a reference in FB instead of the one in the 18.0\bin folder (as was done with previous versions of Delphi)

Hi Kent

In our experience the manifest files generaed by rad studio are not really usable, they miss way too much information and we do not recommend using them. It’s not difficult to create a manifest file, and it really should live in source control with your application rather than relying on rad studio to generate it. FWIW, since we don’t use msbuild, but call dcc directly, we end up having to try and reverse engineer things that the IDE does ‘automatically’, such as typlib compilation etc. We decided against this for the manifest file, since it’s trivial to add a manifest file. 

This is the one we use for FinalBuilder 8 :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
  xmlns=“urn:schemas-microsoft-com:asm.v1”
  manifestVersion=“1.0”>
  <assemblyIdentity
    name=“VSoftTechnologies.FinalBuilder”
    processorArchitecture=“x86”
    version=“8.0.0.0”
    type=“win32”/>
  <description>FinalBuilder is a GUI-based build automation tool for Windows developers.description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type=“win32” name=“Microsoft.Windows.Common-Controls” version=“6.0.0.0” processorArchitecture=“x86” publicKeyToken=“6595b64144ccf1df” language="*"/>
    dependentAssembly>
  dependency>
  <trustInfo xmlns=“urn:schemas-microsoft-com:asm.v2”>
    <security>
        
      
      <requestedPrivileges>
        <requestedExecutionLevel
           level=“asInvoker” uiAccess=“false” />
       requestedPrivileges>
     security>
  trustInfo>
  <compatibility xmlns=“urn:schemas-microsoft-com:compatibility.v1”>
    <application>
      
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
      
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> 
    application>
  compatibility>
 assembly>

We turned of tthe dpiAware stuff because XE7 dpi support is too broken to use. 

HTH

That is kind if what I gathered, and was the ultimate resolution to our build process too - was hoping I was just missing the setting to have it pull from the DPROJ so I don’t get different executables depending on weather it was built with command line (via FB) or Direct Delphi IDE.

I’m also suspecting that some of the manifest settings are different depending on what compiler was used (as you expressed, DPI Aware doesn’t work with XE7 projects), so I upgraded all projects to X10.1 Berlin and pointed FB at a single manifest so I don’t have to maintain different sets.

Hopefully the info posted will help others doing the same thing in their projects