cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
anchal123
Level 3

CoCreateObjectDotNet throws error code: -2147219705

Hi....

I have used CoCreateObjectDotnet to call a .net dll function. Below is the code:

function CreateABC(hMSI)
OBJECT tnaObj;
begin

try

set Obj=CoCreateObjectDotNet(INSTALLDIR^"Products\\ABC\\service\\ABC.Service.exe", "ABC.tAuthority");

if (!IsObject(Obj)) then
//MessageBox("CoCreateObjectDotNet object creation failed",INFORMATION);
SprintfBox(INFORMATION,"CoCreateObjectDotNet object creation failed",Err.Description,Err.Number);
else
Obj.GenerateForABC() ;
endif;
catch
SprintfBox(INFORMATION,"CoCreateObjectDotNet Error","ERROR: %s NUMBER: %d",Err.Description,Err.Number);
endcatch;


end;

I have created a custom action which calls this method and put that in installation sequence. Now I created the setup for my application.

When I install this setup on some machine where visual studio is installed it works fine. But if I install the same setup on machine where .net framework 1.1, 2.0, 3.0 and 3.5 are installed but visual studio is not the setup doesn't work. It throws error with code -2147219705.
I have commented function call code and checked that error comes while creating object for class containing function.

As I am very new to installshield i don't have any qlue to resolve it. Can anyone help me or give me some work around to solve this problem.

Thanks in advance,
anci
Labels (1)
0 Kudos
(13) Replies
MSIYER
Level 8

Did you create the dll?
0 Kudos
anchal123
Level 3

ABC.Service.exe is having that function.
0 Kudos
MSIYER
Level 8

Has it got the COM VISIBLE attribute set?
0 Kudos
anchal123
Level 3

Yes , I put COMVisible in assembly.info and above tAuthority class also...I have Checked in Installshield Tool-> Options -> .Net also

regsm is pointing to
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe

InstallUtilLib is pointing to
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtilLib.dll

deployment machine has everything in place still its not working there 😞
0 Kudos
MSIYER
Level 8

Try using DotNetCoCreateObject instead of the one you are using and let me know.
0 Kudos
anchal123
Level 3

Already tried...but same issue
DotNetCoCreateObject("dll path", ""Class name", "");

Does these two methods requires any special installation of .net framework on deployment machine, bcoz as i said it works on machine where visual studio is installed..
0 Kudos
MSIYER
Level 8

Try installing vcredist 2005 or 2008 or 2010(according to the VS installed on successful machines) on any of the machines where it fails and try the install. Any of them, if missing, will cause issues.

NOTE:
vcredist 2010 will not be enough for apps that need vcredist 2008 or 2005. So installing vcredist 2010 will be of no use. You have to install vcredist 2005 for apps that need it even if your machine has vcredist 2010 already installed.
0 Kudos
anchal123
Level 3

I tried installing all versions 2005, 2008 and 2010 of vcredist but none semms to be working ...still stucked with same issue :mad:
0 Kudos
MSIYER
Level 8

What is the class name?
If it is tAuthority, try using just that tAuthority in the parameter rather than using ABC.tAuthority.
0 Kudos
anchal123
Level 3

but ABC is namespace name....still i tried but no luck
0 Kudos
MSIYER
Level 8

Questions:

a) Are you calling any other .NET assembly prior to this call to CoCreateObjectDotNet()? If yes, what .NET version does that depend on?
b) Are you calling the same .NET assembly prior to this particular call?
c) As you are calling this dll from INSTALLDIR, I assume that you are installing it into the system. Are you calling it at the right point in the execution sequence?
d) The file has to be present on the system for the call to be successful. So have you sequenced your CA after InstallFinalize or such actions?

Provide the answers to these queries. Also, perform the following steps if you feel you are doing the other things right:

vcredist installation was suggested in desperation. But I would suggest you open ProcMon.exe and look at the version of .NET being used by the installer.
A mismatch in the version being used at run time can be the issue.

Run ProcMon.exe first on a machine where your installation succeeds. Note the version of .NET being used. Then repeat the step on the machine where it fails.

You know what version your assembly was compiled in?

Even if you do not know, Procmon.exe readings on the machine where your installation succeeds will tell you the correct version of .NET needed.
0 Kudos
anchal123
Level 3

HI...

I have checked .. actually the issue is with one of the dll getting deployed on other machine.. It is .net C++ dll which require some dependent libraried to be installed on system...I run redist_vc86 also as suggested by u still it doesn't come up....can i include the same in installer...what are redistributables for that?
0 Kudos
mweintraub
Level 3

I saw this thread before when I was researching if IS 2010 will support .NET 4.0 DLLs..... but now that I've actually converted my previously working .NET 3.5 DLL to 4.0, I get the same error (-2147219705).

So, what version of .NET is that DLL compiled with?
0 Kudos