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: *URGENT* DotNetCoCreateObject not working with .Net Framework 4.0
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
‎Aug 09, 2010
02:20 PM
*URGENT* DotNetCoCreateObject not working with .Net Framework 4.0
Hi
In a basic msi project, I am calling DotNetCoCreateObject in my installscript to instanciate my .Net Csharp dll and call my method in it. It used to always work until we upgrade to .Net Framework 4.0 and build the .Net CSharp project with Framework 4.0 set in the properties on the project in Visual Studio 2010 instead of 3.5.
Now DotNetCoCreateObject throws an exception : -2147219705
Is there another way of calling a method in that dll if DotNetCoCreateObject does not work with .Net Framework 4.0? Is this a known issue?
In a basic msi project, I am calling DotNetCoCreateObject in my installscript to instanciate my .Net Csharp dll and call my method in it. It used to always work until we upgrade to .Net Framework 4.0 and build the .Net CSharp project with Framework 4.0 set in the properties on the project in Visual Studio 2010 instead of 3.5.
Now DotNetCoCreateObject throws an exception : -2147219705
Is there another way of calling a method in that dll if DotNetCoCreateObject does not work with .Net Framework 4.0? Is this a known issue?
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 09, 2010
05:48 PM
Here attached is a simple basic msi project that has one custom action that is called after the SetupInitialization (you just need to run it to see the error, dont need to install anything). The custom action only calls DotNetCoCreateObject and display a messagebox if it fails or not. The .Net dll is added in the support files view.
Also attached is the project build in Visual Studio 2010 with .Net Framework 4.0.
If you go to the properties of the project and change the .Net Framework to 3.5 and rebuild everything, you'll see that the DotNetCoCreateObject will be successfull.
And yes the .Net Framework 4 is installed on the machine.
Please help !!!
Also attached is the project build in Visual Studio 2010 with .Net Framework 4.0.
If you go to the properties of the project and change the .Net Framework to 3.5 and rebuild everything, you'll see that the DotNetCoCreateObject will be successfull.
And yes the .Net Framework 4 is installed on the machine.
Please help !!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2010
09:26 PM
This is a limitation of .NET code support in IS 2010 or older. The unmanaged framework interfaces InstallShield uses in these versions to create/load an instance of the .NET framework CLR does not support any versions newer than 2.0 (which 3.0 and 3.5 are based on). A new interface is provided by .NET 4.0 to load the 4.0 CLR. Supporting this required a code change in InstallShield to use the new interface. As such, support for loading .NET 4.0 assemblies is available in IS 2011 but not older versions due to the scope of the changes required.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 03, 2010
04:03 AM
Hi Josh,
I am a bit puzzled because of three issues:
1) I could not find the limitation you mention in the IS2010 documentation - we have a similar issue here and we searched for a long time...
2) It is not clear to me from your reply whether .NET 3.0 and 3.5 assemblies can be called from InstallScript, or only .NET 2.0 and lower.
3) What sort of .NET calls does this limitation apply to?
Does it only apply to calling methods from InstallScript (using DotNetCoCreateObject), so that I can use a .NET 4.0 assembly as the source for a "Call a public method in a managed assembly" custom action?
Or does the limitation also apply to managed assembly CAs?
Best regards
Matthias
I am a bit puzzled because of three issues:
1) I could not find the limitation you mention in the IS2010 documentation - we have a similar issue here and we searched for a long time...
2) It is not clear to me from your reply whether .NET 3.0 and 3.5 assemblies can be called from InstallScript, or only .NET 2.0 and lower.
3) What sort of .NET calls does this limitation apply to?
Does it only apply to calling methods from InstallScript (using DotNetCoCreateObject), so that I can use a .NET 4.0 assembly as the source for a "Call a public method in a managed assembly" custom action?
Or does the limitation also apply to managed assembly CAs?
Best regards
Matthias
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2010
04:24 PM
It's not in the IS 2010 documentation because .NET 4.0 was not released at that time. Listing all the future technologies with which a release won't work would be cost prohibitive, even if we could find a reliable psychic. 🙂
That said, the rest is all pretty much tied together: .NET 2.0 is shared as the underlying framework through version 3.5, and the way assemblies were loaded into unmanaged processes remained the same. As such, those all work. .NET 4.0 requires new methods, and as such is not supported by IS 2010 in either InstallScript's DotNetCoCreateObject or the Managed Code Custom Action support in MSI projects. If your assembly works when loaded in a .NET 2.0 framework, you should be fine. If it requires .NET 4.0, you will either need to upgrade to IS 2011 or examine other ways of calling this code (such as building and launching an EXE).
That said, the rest is all pretty much tied together: .NET 2.0 is shared as the underlying framework through version 3.5, and the way assemblies were loaded into unmanaged processes remained the same. As such, those all work. .NET 4.0 requires new methods, and as such is not supported by IS 2010 in either InstallScript's DotNetCoCreateObject or the Managed Code Custom Action support in MSI projects. If your assembly works when loaded in a .NET 2.0 framework, you should be fine. If it requires .NET 4.0, you will either need to upgrade to IS 2011 or examine other ways of calling this code (such as building and launching an EXE).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2010
12:57 AM
Hello Michael,
thanks a lot for this information. I was not aware that .NET 4.0 is still that new...
Wouldn't these .NET 4 limitations be worth a KB article - I would even consider them a "Known issue in IS2010"...?
Best regards,
Matthias
thanks a lot for this information. I was not aware that .NET 4.0 is still that new...
Wouldn't these .NET 4 limitations be worth a KB article - I would even consider them a "Known issue in IS2010"...?
Best regards,
Matthias
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 06, 2011
06:16 PM
joshstechnij wrote:
As such, support for loading .NET 4.0 assemblies is available in IS 2011 but not older versions due to the scope of the changes required.
Is Flexera planning any kind of patch for any of the older versions of InstallShield to support loading .NET 4.0 assemblies?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 15, 2012
06:46 AM
You can set assembly: ComVisible(false) to assembly: ComVisible(true). The exception will not come.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)