We also have some .Net dll's that we use in the Uniface application. We build the .Net dll's with com exposing, so we have the tlb files. In the client runtime installer we registrate the dll's It works fine for XP, 2003, 7, 8.1, 10, 2012 versions of Windows

stcourth said We also have some .Net dll's that we use in the Uniface application. We build the .Net dll's with com exposing, so we have the tlb files. In the client runtime installer we registrate the dll's It works fine for XP, 2003, 7, 8.1, 10, 2012 versions of Windows

Wolfgang is trying to use the .NET control reg-free, which means that it should not be necessary to register it on the client. The required definitions for using the control are hereby specified in the manifest. More info about this topic can be found (e.g.) here:

• Registration-Free Activation of .NET-Based Components: A Walkthrough

 In the end we've figured out that the described problems goes away when creating a COM instance of the .NET control before instantiating it in the OCX Container widget. It seems that the OCX Container cannot instantiate a reg-free .NET control by itself. But when the required object is first instantiated by the COM Call-Out interface (e.g. newinstance "<SignatureNameOfControl>", vHandle) then the OCX Container has all the required information to instantiate the control successfully. Hope this helps. Regards, Daniel

A big thank to Daniel. This was my last missing link to get the application reg-free. The newinstance is only necessary for windows 7 clients. For windows 8 you can use it optionally, but it works also without the newinstance. You need the newinstance only once in the application (e.g. at startup, the handle is just a dummy). Once instantiated, all controls in all forms work as expected. Wolfgang

Hello, we are trying to achieve a similar functionality. Even though it's not a .NET component, we have our own ocx control (developed in Delphi) and want to use it as a reg-free ocx. It seems that registration of ocx is a problem for some customers. My colleague was trying to solve it but was not very successful. The main problem is that he needs to modify the manifest file of uniface.exe. It seems that you solved this... could you please give me a hint as what needs to be done to do so? I suppose it shouldn't matter if it's .NET or Delphi component as long as it's ocx (activex). It would be great to bypass the necessity of regsvr32 the ocx (dll) on every single client machine. Kind regards, Zdeněk

Hello Zdeněk, You can use the tool mt.exe that is part of the Microsoft Windows Software Development Kit (SDK) or Microsoft Visual Studio to update the internal manifest of the uniface.exe. And the article "Registration-Free Activation of COM Components: A Walkthrough" describes in general how to get a COM component working reg-free. I don't remember the exact steps, but you basically need to generate a manifest for your Delphi component that will allow reg-free activation. The specific mt.exe command should like this:

Where foo.dll is the Delphi Component and foo.tlb the Type Library for the Delphi Component. In case you don't have a separate .tlb file then it's possible that the Type Library is embedded into the dll. The generated manifest (e.g. foo.manifest) then needs to be copied to the same directory where the Delphi component is located. In case the Delphi component already has an internal manifest then you need to replace the internal manifest (you also can use mt.exe for this). And now we come to the manifest of the Uniface.exe. In order to activate the Delphi component reg-free you need to add a assembly dependency to the Uniface manifest. First we export the existing manifest:

Then you need to add the dependency to the manifest uniface.exe.manifest. For example:

Note: Instead of "foo" you of course need to specify the Assembly Name of your Delphi component. And update the internal manifest of the uniface.exe:

This is just a simple narration of the required steps (which I wrote down from memory). And you also need to copy the Delphi component and the generated manifest to the Uniface bin directory so that it can be loaded by the uniface.exe. After you've updated the uniface.exe you might get a security warning when trying to start your application. The uniface.exe is signed and when you change the exe file the signing is not valid anymore. In case you want to avoid the security warning at start-up then you additionally need to re-sign the uniface.exe. i don't have the exact steps handy, but you should find the required info by doing a quick search on the Internet. Hope this helps. Kind regards, Daniel

The huge thanks, Daniel. This seems very promising... I will pass the info to my colleague. Thanks again and nice weekend, Zdeněk

Hi Daniel, As this destroys the digital signing of Uniface.exe,  could this be somehow harmful, ie. affecting licensing or such? Regards RogerW.

rogerw said Hi Daniel, As this destroys the digital signing of Uniface.exe,  could this be somehow harmful, ie. affecting licensing or such? Regards RogerW.

Hi Roger, Changing the internal manifest of the Uniface.exe (or making the digital signature invalid) should not have an effect on licensing (or other things). The only side-effect I'm aware of is that you get an additional (Windows) security warning when try to start a Uniface app (that has an invalid signature). And if you want to avoid this then you need to sign the Uniface.exe yourself. Hope this helps. Regards, Daniel