Antview ocx manifest file that will work for reg free Com in VB6

[Kevin.Byrne@opiesoftware.com]

I have tried and tried to get a working manifest file so i can use the antview OCX inside vb6 without registering the ocx. 
I have found some examples for older versions but they are not working for me I need it for 1.1.316.0 (or current) Has anyone gotten reg free com to work with a current ver of antview? 

Thank you in advance for any help

[wila]

Hi,

The question came also in by email and I have replied there in more details, including an adjusted .manifest file that had a bunch of lines removed that are not needed.

Officially we only support the traditional registration of our ActiveX control, so the registration that you see with the regsvr32 command.
The reason is that the manifest file might need changes after an update of the control.
This means that we don’t test with “reg free” com and in case of issues we might ask you to change the registration to use traditional registration.
 
Having said all that.. it should work.
In fact, the version of the manifest file that was send by email worked fine after updating the version numbers to 1.1.330.
A few things to keep in mind are:
- Put the .ocx in the same folder as your application's binary
- Put the .manifest file(s) in this same folder as well
- Put the webview2loader.dll in this folder as well (careful with win32/win64 bitness, there are two identically named versions of this dll)

That's pretty much it.

Attached are the .manifest files I used for testing with release 1.1.330
 
The Demo.exe-without.manifest file is the original manifest file of the binary that was used to test with which would be used in case of using the regsvr32 way of registering the control.
--
Wil

[Batduder]

I need a manifest file for the v2 DLL instead of the OCX.  I tried this:

Code:

<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="AntView-2.0-x86.dll"
      version="2.0.459.0"
      processorArchitecture="x86"
    />
  </dependentAssembly>
</dependency>

I put that in my EXE's manifest file (cwatch.exe.manifest). However, that blocks the program from running now. I suspect that either the version is not correct, or I need a public key. But where do you get the public key??

Does anyone have an example for the V2 DLL?

[wila]

Hi,

And there's one of the reasons that this is still unsupported, it needs a completely different manifest as all the GUID's have changed and there's a number of new interfaces that needed to be added (and obsolete -unused- ones removed).

Did a bit of testing here and the attached manifest worked for me.
Note that the same applies.

- Put the AntView-2.0-x86.dll in the same folder as your application's binary
- Put the .manifest file(s) in this same folder as well
- Put the webview2loader.dll in this folder as well (careful with win32/win64 bitness, there are two identically named versions of this dll)

You'll have to adjust your application's manifest file in the same way as the demo.exe.manifest file to include the manifest file from AntView.

Note that on each release interfaces might have been added and those new interfaces won't work until that new interface has been added to the manifest file.

Hope this helps,
--
Wil

[Batduder]

I tried your suggestion above, but Microsoft Visual Foxpro 9 is still unhappy and wants the control registered.

1. On the target/test PC, I unregistered antview-2.0-x86.dll and WebView2Loader.dll just to be sure of where I was starting
2. I put a copy of AntView-2.0-x86.dll (32 bit) in the same folder as my app binary on the target/test PC.
3. I put a copy of WebView2Loader.dll (32 bit) in the same folder as my app binary on the target/test PC.
4. I modified my app's manifest file to add the AntView 2.0 dependency and a bit of the security stuff.
5. Ran the app
6. Same results, Foxpro wants AntView 2.0 to be registered.

I am running on Windows 11 on the target/test PC.


If I manually register the DLLs with regsvr32 it works fine. But as stated, I cannot do that during a "patch" install on customer's machines.

Here is my manifest file for the app:

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        version="1.0.0.0"
        type="win32"
        name="Microsoft.VisualFoxPro"
        processorArchitecture="x86"
    />
    <description>Visual FoxPro</description>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Common-Controls"
                version="6.0.0.0"
                language="*"
                processorArchitecture="x86"
                publicKeyToken="6595b64144ccf1df"
            />
        </dependentAssembly>
    </dependency>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity type="win32" name="AntView-2.0-x86.dll" version="2.0.459.0" />
        </dependentAssembly>
    </dependency>
    <v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
        <v3:security>
            <v3:requestedPrivileges>
                <v3:requestedExecutionLevel level="asInvoker"></v3:requestedExecutionLevel>
            </v3:requestedPrivileges>
        </v3:security>
    </v3:trustInfo>
    <v3:application xmlns:v3="urn:schemas-microsoft-com:asm.v3">
        <v3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>True</dpiAware>
        </v3:windowsSettings>
    </v3:application>
</assembly>

[wila]

Hi,

Today I have been investigated this for a bit.

As it turns out VFP will embed a manifest file into the build exe.
This got me baffled for a while as I wasn't understanding why windows kept on ignoring any and all manifest files I put next to the exe file. It wasn't until I used ResourceHacker (see https://angusj.com/) to inspect the binary and find it already had a manifest file embedded, that things started to make sense.
So I used ResourceHacker to remove the embedded manifest file from the exe file and low and behold.. I got an error that my manifest file was corrupt.
Not a surprise as I had tried too many things.

Eventually I got to a manifest file similar to yours and while the binary now starts without errors, the AntView control doesn't function. Turning on logging for the AntView control shows to me that it is having issues with registering events, but what exactly is wrong is unclear to me at this stage.
With VFP something is working differently for sidebyside registration when compared to registering the control normally and I'm not sure what it is and if it is fixable.

So... for now I'm going to look into the alternative solution I discussed with you by email.
--
Wil

[Batduder]

Thanks Wil. I am seeing the same thing. I can easily register the control manually and then it works fine. I also used your register program and that works fine too. But if I try the manifest method, Microsoft Visual Foxpro is never happy and it cannot find the control. For now I am calling your register program (with elevation) from my software-patch code. It's a bit awkward because there are two choices (1.1 and 2.0) but it DOES work.

I still am running into two problems that makes it hard to choose which control to use:

1. Version 1.1 gives a javascript stack overflow error when you pass an address to google maps via a URL

2. Version 2.0 leaves a large gray area on top of the Foxpro form when you open it. It appears that Foxpro has trouble with the first-time render. The control, in my app, is supposed to be on a tabbed control page (in Foxpro it's a "pageframe" control) but appears outside the pageframe with the proper offsets but from the top left of the form, NOT the top left of the pageframe page. Once you go to the page that has the control, this all fixes itself until you close and re-open the form again. I have a feeling the .ocx control does not do this but I will confirm.

[wila]

Thanks Wil.  I am seeing the same thing.  I can easily register the control manually and then it works fine. I also used your register program and that works fine too.  But if I try the manifest method, Microsoft Visual Foxpro is never happy and it cannot find the control.  For now I am calling your register program (with elevation) from my software-patch code. It's a bit awkward because there are two choices (1.1 and 2.0) but it DOES work.

I still am running into two problems that makes it hard to choose which control to use:

1. Version 1.1 gives a javascript stack overflow error when you pass an address to google maps via a URL

2. Version 2.0 leaves a large gray area on top of the Foxpro form when you open it.  It appears that Foxpro has trouble with the first-time render.  The control, in my app, is supposed to be on a tabbed control page (in Foxpro it's a "pageframe" control) but appears outside the pageframe with the proper offsets but from the top left of the form, NOT the top left of the pageframe page.  Once you go to the page that has the control, this all fixes itself until you close and re-open the form again.  I have a feeling the .ocx control does not do this but I will confirm.

A follow up on the above as we've taken the discussion further by email.
We don't know why FoxPro applications do not want to work with reg free manifest. For now, we've created a command line interface to the RegisterAssistant application which allows the customer to more easily register the control without having to use an installation script.

We've been unable to reproduce the javascript stack overflow using a URL provided. For the moment, we're chalking it up on something specific related to the customer environment. AntView does not really touch the javascript engine in the control, so why it would work different with version 2 is a mystery. If you encounter this, we would suggest deleting the profile data (see UserDataFolder) and try again.

The first time render issue in the FoxPro IDE when the AntView control is in a pageframe control is still open.
The customer worked around it by moving the control off screen and position it on opening the tab.
--
Wil

[Batduder]

>>The first time render issue in the FoxPro IDE when the AntView control is in a pageframe control is still open. The customer worked around it by moving the control off screen and position it on opening the tab.

Yes just to explain a bit more. When there is an AntView control on a page in a Foxpro PageFrame, then upon opening the IDE to edit that form, the AntView control shows up on top of the form in the wrong position. It is just a gray box - a rendering error. You cannot select it or move it.

My workaround was to place the control far off the bottom of the page (y=1000). And then when the form is opened at run time, the first thing I do in the form's INIT method is to move the control back up to its proper position. This work-around works well for both run time and IDE editing.