This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Troubles with DotNetCoCreateObject
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 02, 2008
07:44 PM
Troubles with DotNetCoCreateObject
I can't figure out how to use DotNetCoCreateObject.
I have verified my assembly and supporting files are all going to SupportDir (temp folder under user's LocalSetting folder).
Here is the code I'm using:
My assembly has 'Make COM visible' checked. Do I need to worry about Namepace?
The above code catches the following error:
Number: -2147219705
Description: [nothing]
Source: ISRT._DotNetCoCreateObject
I added a UseDLL() call prior to the DotNetCoCreateObject to make sure the dll is accessible, and that call is successful.
I'm running this code from the Installing event. Is that ok?
I've been staring at this code for hours and can't make any progress. Any suggestions would be very much appreciated. Thanks.
I have verified my assembly and supporting files are all going to SupportDir (temp folder under user's LocalSetting folder).
Here is the code I'm using:
dllPath = SUPPORTDIR ^ "DBInstall.dll";
exeClass = "DBInstall.AInstall";
try
set oInstall = DotNetCoCreateObject(dllPath, exeClass, "");
catch
/**/ MessageBox("oInstall ERROR: " + Err.Number + " ERROR Description: " + Err.Description + " ERROR Source: " + Err.Source, SEVERE);
endcatch;
My assembly has 'Make COM visible' checked. Do I need to worry about Namepace?
The above code catches the following error:
Number: -2147219705
Description: [nothing]
Source: ISRT._DotNetCoCreateObject
I added a UseDLL() call prior to the DotNetCoCreateObject to make sure the dll is accessible, and that call is successful.
I'm running this code from the Installing event. Is that ok?
I've been staring at this code for hours and can't make any progress. Any suggestions would be very much appreciated. Thanks.
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 02, 2008
08:42 PM
What project type is this?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 03, 2008
10:14 AM
Christopher Painter wrote:
What project type is this?
If you are talking about the assembly I'm attempting to like to, it is a VB.net 3.5 sp1 class library application. Created with VS2008. This assembly is used to install the database by launching a RedGate Packager 6 executable.
If you are talking about the InstallShield project, I'm not sure. It installs .Net, a database and an application.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 05, 2008
02:01 PM
It should say in the title bar if it's a Basic MSI, InstallScript MSI or InstallScript project type.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2008
12:56 AM
Is .NET Framework installed on the machine? If so, what version(s)?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2008
09:19 AM
I figured out the issue. The problem turned out to be embarassingly simple on my part. I did not include the Namespace in the Assembly+Class parameter for the method.
Now I have to figure out how to retrieve the Username and Password provided for SQL Server in an earlier step in the setup...
Thanks again for your help.
Now I have to figure out how to retrieve the Username and Password provided for SQL Server in an earlier step in the setup...
Thanks again for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 06, 2008
09:47 AM
While dotNetCoCreateObject() is nice, I would really encourage you to consider WiX's DTF instead. It'll encapsulate your .NET Class as a Type1 CA which you can easily consume in your InstallScript MSI project type.
http://blog.deploymentengineering.com/2008/07/reasons-dtf-is-better.html
http://blog.deploymentengineering.com/2008/07/reasons-dtf-is-better.html