Anyone know how to modify a .manifest file?

[Zepher]

We have a program called AviMark that is used as a database for the Veterinary Hospital that I do IT work for and they just bought a Surface Pro 4 to use as a mobile tool for the Doctors to use to look up patient info.

the issue we are having is that Avimark does not render properly on the Surface Pro due to the high resolution screen, all the text is really tiny at all resolutions and scaling options and the "OK", "Cancel", and "Help" buttons don't show up on any of the dialog windows that pop up.

The only way I can get it to work right is using a .manifest file that does the dpiAware setting and then the Surface Pro renders at a legible scale and all buttons show up.

The problem is is that there is already a .manifest file that the program uses and I have been trying to incorporate the dpiAware settings into the other file and while the dpiAware settings work, it causes the terminals to give a side-by-side error and the program doesn't open up.

Here is the code I need added,

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">

<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0" processorArchitecture="*"
      publicKeyToken="6595b64144ccf1df"
      language="*">
    </assemblyIdentity>
  </dependentAssembly>
</dependency>

<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="Microsoft.VC90.CRT"
      version="9.0.21022.8"
      processorArchitecture="amd64"
      publicKeyToken="1fc8b3b9a1e18e3b">
    </assemblyIdentity>
  </dependentAssembly>
</dependency>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel
        level="asInvoker"
        uiAccess="false"/>
    </requestedPrivileges>
  </security>
</trustInfo>

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">false</ms_windowsSettings:dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

</assembly>

and this is the stock .manifest file,

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" processorArchitecture="*" version="6.0.0.0" name="AVImark"></assemblyIdentity>
  <description>AVImark Veterinary Practice Management Program</description>
<!--
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
-->  
  <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
    <ms_asmv2:security>
      <ms_asmv2:requestedPrivileges>
        <ms_asmv2:requestedExecutionLevel level="asInvoker"></ms_asmv2:requestedExecutionLevel>
      </ms_asmv2:requestedPrivileges>
    </ms_asmv2:security>
  </ms_asmv2:trustInfo>
</assembly>

I need to know how to merge them so that it all works right.

 

[modi123]

Where did all that manifest info come from that you need added?

Typically the app would need to have the manifest edited in the project and then recompiled. Editing after the fact produces questionable results. Have you just asked the company to make the changes and email you a copy for the SP4?

 

[heatlesssun]

Did you modify the registry?

SSMS in High-DPI Displays: How to Stop the Madness

 

[Zepher]

Did you modify the registry?

View attachment 7612

SSMS in High-DPI Displays: How to Stop the Madness

Ya, I modified the registry with that entry on the machines. I'll check it see if the entry is exactly the same.

Where did all that manifest info come from that you need added?

Typically the app would need to have the manifest edited in the project and then recompiled. Editing after the fact produces questionable results. Have you just asked the company to make the changes and email you a copy for the SP4?

that extra code came from a Microsoft help page for fixing pretty much the issue I am having with the program and the SP4.

I talked with the company that makes the program, but the tech support person I talked with didn't seem to know what I needed done.

 

[modi123]

Then escalate it. Again .MANIFEST files come from the project's solution. Kicking things in there may not even work unless rebuilt.

 

[Zepher]

I've got the software setup here on my server for testing purposes and I can change the manifest file to have only the dpiAware info in there and all instances will run with no issues.
I have the app running on the SP4, my laptop, my workstation, on the server, and in the VM that is running the main app.

When I was testing it in the office, the SP4, Server, and my laptop would all fire up with the dpiAware manifest file, but 3 of the other machines in the office gave the side-by-side error.

I didn't have a chance to call the company and see if I can escalate the issue and see if they figure this issue out. What I don't understand is that they recommend the SP series of tablets PC's to use as roaming tools,
but the shit doesn't work right with their default applications settings.


this is in my garage where I am testing this stuff right now,

 

[Absalom]

Messing around with hacks to force external manifests over internal will always be a YMMV scenario. A large project may consist of many DLLs, each possibly embedding its own manifest, which just exacerbates the problem.

If you're getting a side-by-side error, then your issue might be more complicated than just a manifest override. You could have a runtime library conflict or dependency issue. What's the error specifically?

For example, if a VS project was built with debug settings, then it will behave strangely (as in not working at all) if deployed on machines that do not have VS installed (MS doesn't like it's debug runtimes redistributed).

I notice in your target manifest that you are explicitly targeting the VC 9.0 runtime. Are you certain the application was built against this specific version of the runtime? Unless you know with 100% certainty, then you shouldn't be messing with the manifest in this way. This is why it's preferred to let the VS tools generate the manifest.