Jan 23, 2015
07:43 AM
Did you try basing your parent folder on the ROOTDRIVE property? It's not visible in the project, but you can create an InstallScript CA to extract its value and set it to a Directory property. *LE* also, did you check for permissions problems? (that's a bit of a long shot, because I presume you're running it as admin)
... View more
Jan 23, 2015
06:13 AM
Greetings to you, fine people of the Flexera forum, I come to you in the most troublesome of moments with my BasicMSI project(s). I am aware of (some of) the methods to work around the issue depicted in the thread title, but allow me to clarify why they're not viable options: * setup.exe with "required execution level" = "Administrator" this would be the most direct and simple way to deal with the issue, but it's not doable because the installations will be posted on a website for download, and due to security reasons, no .exe files will be uploaded. * no tweaks to the registry (so no "run as administrator" added to the .msi's contextual menu) the clients do not allow manual work on their registry (for security reasons, obviously). also, the reflex will most often be to double-click it, and not [right-click + "run as administrator"] * the "Require Administrative Privileges" on the General Information\Summary Information Stream panel only come into effect when the install execute starts (evidently). And it doesn't even require the admin login, instead stopping the installation with an [i-forgot-what-the-message-said-but-it's-someting-about-"you-are-not-allowed-because-elevated-privileges-are-required"] message. That's a big no-no, because there are a lot of dialogs with input data that will result in a lot of wasted time. * therefore, the only viable solution/workaround that has occured to me so far is running the msi file from an elevated CLI. ... which they would rather avoid. Basically, what the clients want is: * .msi file * when double-clicking it, credentials popup - regardless of the UAC status. Any thoughts? I bid you farewell, gentlemen and gentleladies, Daniel.
... View more
Labels
- Labels:
-
InstallShield 2014
Jul 30, 2013
03:30 AM
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: 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?
... View more
Labels
- Labels:
-
InstallShield 2010
Latest posts by clawdtm
Subject | Views | Posted |
---|---|---|
2718 | Jan 23, 2015 07:43 AM | |
2316 | Jan 23, 2015 06:13 AM | |
3876 | Jul 30, 2013 03:30 AM |
Activity Feed
- Posted Re: Create empty folders in Basic MSI on InstallShield Forum. Jan 23, 2015 07:43 AM
- Posted Force .msi file to request elevated privileges (administrator) on run on InstallShield Forum. Jan 23, 2015 06:13 AM
- Tagged Force .msi file to request elevated privileges (administrator) on run on InstallShield Forum. Jan 23, 2015 06:13 AM
- Tagged Force .msi file to request elevated privileges (administrator) on run on InstallShield Forum. Jan 23, 2015 06:13 AM
- Posted InstallShield 2010 + .NET 4.0 managed code = TargetInvocationException on InstallShield Forum. Jul 30, 2013 03:30 AM