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: InstallShield 2010 + .NET 4.0 managed code = TargetInvocationException
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
Jul 30, 2013
03:30 AM
InstallShield 2010 + .NET 4.0 managed code = TargetInvocationException
Hi guys,
I've already searched the forum for similar problems, but everything I found was lacking one problem detail. But I'll get to that later.
The issue is pretty much similar to the one in this old post.
Main idea: I'm using an InstallShield 2010 Professional to build a basic MSI installation for a .NET 4.0 application.
(Side note: Until last year, the application was a .NET 3.5 one, therefore .NET Framework v3.5 was a prerequisite, and everybody was happy - since IS2010 has quite a bromance with .NET 3.5. But after the main application switched to .NET 4.0, we tried to eliminate completely 3.5 from the prerequisites list - the only one keeping it there being the .msi.)
After also building my .dll (with the managed code methods for some custom actions) with .NET 4.0, I first ran into the problem where the methods were not visible to the .msi -- fixed by making the .net project COM visible (VS project properties -> Build -> "Register for COM interop").
Apparently, though, that was just the beginning of the adventure, since the bitter side of the story came only after that, when trying to actually run the installation. What happens is that when it comes to running the first managed code custom action, the installation halts.
Log excerpt:
I am aware that this kind of problem is quite common for people still using InstallShield 2010 (not working with .NET 4.0).
The actual question is whether anyone has found some solution to this? Has anyone managed to convince an .msi built with InstallShield 2010 to successfully work with .net 4.0 assemblies?
I've already searched the forum for similar problems, but everything I found was lacking one problem detail. But I'll get to that later.
The issue is pretty much similar to the one in this old post.
Main idea: I'm using an InstallShield 2010 Professional to build a basic MSI installation for a .NET 4.0 application.
(Side note: Until last year, the application was a .NET 3.5 one, therefore .NET Framework v3.5 was a prerequisite, and everybody was happy - since IS2010 has quite a bromance with .NET 3.5. But after the main application switched to .NET 4.0, we tried to eliminate completely 3.5 from the prerequisites list - the only one keeping it there being the .msi.)
After also building my .dll (with the managed code methods for some custom actions) with .NET 4.0, I first ran into the problem where the methods were not visible to the .msi -- fixed by making the .net project COM visible (VS project properties -> Build -> "Register for COM interop").
Apparently, though, that was just the beginning of the adventure, since the bitter side of the story came only after that, when trying to actually run the installation. What happens is that when it comes to running the first managed code custom action, the installation halts.
Log excerpt:
MSI (c) (2C:B4) [12:43:47:721]: Doing action: LocalIP
Action 12:43:47: LocalIP.
Action start 12:43:47: LocalIP.
MSI (c) (2C:78) [12:43:47:900]: Invoking remote custom action. DLL: C:\Users\d00014\AppData\Local\Temp\MSI7D68.tmp, Entrypoint: m7
InstallShield: Loaded CLR successfully
InstallShield: Loading assembly FMSInstallerFramework from resource 4097
InstallShield: Calling method with parameters []
InstallShield: Loading Assembly System.Windows.Forms
InstallShield: Couldn't resolve assembly by name System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
InstallShield: Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
at FMS.Packaging.Product.PrintersManagementControllerAgent.LocalIP.ReturnLocalIp()
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Windows\syswow64\MsiExec.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = DEVEL\d00014
LOG: DisplayName = System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
(Fully-specified)
LOG: Appbase = file:///C:/Windows/syswow64/
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
LOG: Attempting download of new URL file:///C:/Windows/syswow64/System.Windows.Forms.DLL.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/System.Windows.Forms/System.Windows.Forms.DLL.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/System.Windows.Forms.EXE.
LOG: Attempting download of new URL file:///C:/Windows/syswow64/System.Windows.Forms/System.Windows.Forms.EXE.
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at InstallShield.ClrHelper.CustomActionHelper.CallMethod(EntryPointInfo info)
at InstallShield.ClrHelper.CustomActionHelper.RunAction(UInt32 installHandle, Int32 entryNumber, Int64 instanceHandle)
InstallShield: Managed code threw an unhandled exception.
CustomAction LocalIP returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 12:43:48: LocalIP. Return value 3.
MSI (c) (2C:B4) [12:43:48:990]: Doing action: SetupCompleteError
I am aware that this kind of problem is quite common for people still using InstallShield 2010 (not working with .NET 4.0).
The actual question is whether anyone has found some solution to this? Has anyone managed to convince an .msi built with InstallShield 2010 to successfully work with .net 4.0 assemblies?
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 30, 2015
04:15 PM
Hi
I found a solution.
I added a new Property with this value
Name: IS_CLR_VERSION
Value : v4.0.30319;v2.0.50727;v1.1.4322;
Regards
I found a solution.
I added a new Property with this value
Name: IS_CLR_VERSION
Value : v4.0.30319;v2.0.50727;v1.1.4322;
Regards
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)