I think your description of what InstallShield does is incorrect. When you mark something as Register for COM Interop in InstallShield I believe it runs regasm at *build* time (not install time as you said) and adds the created registry entries to the MSI file. Therefore whether you can successfully do a CreateObject is dependent on where you've sequenced the custom action (after registry values are written?).
Since you asked about type libraries, I'll also point out that regasm with the reg option does nothing about them. If you need a type library installing, create one manually and install it. As others have pointed out, there are plenty of other reasons why managed code custom actions can fail. Your assembly might be dependent on other assemblies in the GAC that aren't installed yet. Plus you don't get a vote about the runtime that your assembly will use - if you built it with 1.1 (VS 2003) and 2.0 is on the system you're going to have your 1.1 assembly run in the 2.0 framework because by default COM activation uses the highest runtime on the system. If you want to run some code after the installation but you want it to be part of the installation, do it an a custom action exe installed with your application that gets initiated after InstallFinalize, and this works for managed code much better than invoking it on top of an msiexec process (it's in the application context, you can use exe.config files). Phil Wilson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WenWu Ru Sent: Thursday, November 09, 2006 5:10 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CreateObject in C++ for .NET COM interop? Basically some application specific code needs to be run by the installer after installing or before un-installing the application files. .NET Framework is already installed prior to installing the application. The application is a .NET applcation. "MyCustomActions.dll" contains methods that needs to run application specific business logic, therefore have dependency on .NET. These methods are invoked via custom actions during install (after InstallFinalize) or uninstall. >From: "Mike Dimmick" <[EMAIL PROTECTED]> >To: "'WenWu Ru'" ><[EMAIL PROTECTED]>,<wix-users@lists.sourceforge.net> >Subject: RE: [WiX-users] CreateObject in C++ for .NET COM interop? >Date: Thu, 9 Nov 2006 23:02:45 -0000 > >It's strongly recommended to avoid managed code in custom actions. Best >practice is to keep your custom actions entirely self-contained, which >generally means writing them in C++ and statically linking to the C >runtime library. That's how all of WiX's custom actions are built. > >What does 'MyCustomActions' do? It may be that the tasks it performs >can be performed with native Windows Installer functionality or >existing WiX custom actions that were not available through >InstallShield. > >-- >Mike Dimmick > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of WenWu Ru >Sent: 09 November 2006 15:59 >To: wix-users@lists.sourceforge.net >Subject: [WiX-users] CreateObject in C++ for .NET COM interop? > >Our installer includes a .NET assembly component MyCustomActions.dll, >which is marked with !0.NET COM interop!1 in InstallShield. At >installation, InstallShield runs "regasm MyCustomActions.dll /regfile >MyCustomActions.reg /Codebase" to create registry entries on the target >system to allow COM objects to call the .NET assembly. >MyCustomActions.dll assembly contains a class that is derived from >System.ComponentModel.Component and is marked with [ComVisible(true)]. >A few custom actions written in InstallScript calls CreateObject to create an object instance and invokes the functions. >For example: > > set ojb = CreateObject("MyCustomActions.TestClass1"); > result = obj.TestMethod1(); > >Now that I am converting it to WIX, I need to write the equivalent code >in >C++ for CreateObject. From what I understand, I need to import the >C++ type >library for MyCustomActions.dll and create an interface pointer with >CoCreateInstance. However, MyCustomActions.dll assembly does not >explicitly declare any interface, and currently no type library is >created in the build or install process. How does CreateObject create >the instance and invoke the method? I am hoping that I do not have to >modify the source code and build script for MyCustomActions.dll. > >Thanks, >-WenWu >P.S. Instead of importing the type library, another idea I tried but >failed is to import the ProgID, e.g. #import >"MyCustomActions.TestClass1". Maybe I am not using the correct import >attributes? > >_________________________________________________________________ >All-in-one security and maintenance for your PC. Get a free 90-day trial! >http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http: >//www .windowsonecare.com/?sc_cid=msn_hotmail > > > _________________________________________________________________ Find a local pizza place, music store, museum and more...then map the best route! http://local.live.com?FORM=MGA001 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
