[SOLVED] reg-free .NET COM with uniface on windows 7

Author: wva@gypsilon.de (gypsilon)

Hello My question is not direct related to uniface, but I hope that someone got a similar situation, and can give me some hints. I've got a .NET COM component, which I use as OCX-widget within uniface 9.6. This all works fine. The application runs on a server, and so each client needs to register (regasm) the dll. This I want to avoid, because there are lots of clients. So I looked in all the articles, which describe of how to generate a reg-free COM interop. I followed the steps, die generate a Manifest for the dll, added necessary manifest-Information to uniface.exe (I did also sign uniface.exe which doesn't seem to be necessary so far). After lots of experiments I've got it run on windows8-clients reg-free. Great! Unfortunetaly it doesn't work on windows-7-clients. I did also add the compatibility-switch in the Manifest of uniface.exe Uniface itselfs comes back with a -57, uniface doesn't even look for any signature. Side-By-Side Tracing information seemes to be identical for windows-8 and windows-7 clients. The Fusion-Log gives me some major differences (In windows 7 an access to VC80.CRT fails, while in windows 8 there is no access on it) and a procmon-Trace shows me huge lots of differences. Did someone got similar problems, and has possibly some hints? Thanks Wolfgang

8 Comments

  1. 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


    Author: Stijn Courtheyn (stijn.courtheyn@xperthis.be)
  2. 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:

     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


    Author: diseli (daniel.iseli@uniface.com)
  3. 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


    Author: gypsilon (wva@gypsilon.de)
  4. 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


    Author: sochaz (zdenek.socha@fullsys.cz)
  5. 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:

     mt.exe -tlb:"foo.tlb" -dll:"foo.dll" -out:"foo.manifest"

    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:

    mt.exe -inputresource:uniface.exe -out:uniface.exe.manifest

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

    <dependency>    <assemblyIdentity name="foo" type="win32" version="1.0.0.0"></assemblyIdentity> </dependency>

    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:

    mt.exe -manifest uniface.exe.manifest -outputresource: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. Wink Hope this helps. Kind regards, Daniel


    Author: diseli (daniel.iseli@uniface.com)
  6. The huge thanks, Daniel. This seems very promising... I will pass the info to my colleague. Thanks again and nice weekend, Zdeněk


    Author: sochaz (zdenek.socha@fullsys.cz)
  7. Hi Daniel, As this destroys the digital signing of Uniface.exe,  could this be somehow harmful, ie. affecting licensing or such? Regards RogerW.


    Author: rogerw (roger.wallin@abilita.fi)
  8. 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


    Author: diseli (daniel.iseli@uniface.com)