i have implemented successfully custom actions in my visual studio setup project to encrypt app.config file and also to capture user input through textboxes. However my project has 3rd party dll references which I want to merge. I have done merging using redgate smart assembly and after that when I build the setup project using the merged obfuscated assembly there is an error during installation( unable to get installer type for assembly error 1001).
Can you show me how to encrypt app.config and capture user input via custom dialog using Installshield
InstallerClass Custom Actions ( InstallUtil ) are very fragile and should never be used. The problem you are having is most likely that your custom action assembly has a reference to an assembly that can no longer be found on the disk since it's been merged into another assembly.
This problem would happen with InstallUtil CA's whether it's being called by a Visual Studio Setup Project or an InstallShield Basic MSI project because the problem isn't in MSI, it's in your CA.
I would reccomend you look at WiX Deployment Tools Framework (DTF). It's a far cleaner way of implementing managed code custom actions so that the CA and all of it's dependencies appears as a single native DLL to the Windows Installer. At runtime the native stub extracts all the files, runs your .NET code and marshals all of the MSI API calls between the two sides for you.
It's very clean and it can be used in Setup Projects, WiX, InstallShield and other MSI authoring tools because the output is a simple Win32 DLL with exported stdcall functions. ( Msi Type 1 Custom Action Spec )
Related
I have been referencing the following tutorial for creating a Setup Project for WiX v3, however, most WiX tutorials on the internet are targeting a C# application as its base project. I am currently building a Visual C++17 Win32 application that I want to deploy (i.e. create a setup *.msi installer) using WiX, given how powerful WiX is.
Unfortunately, adding a reference to my C++ project yields a yellow bang exclamation point:
Moreover, when trying to reference an icon file, for example, in the Product.wxs file using $(var.TimeTrack.ProjectDir)\TimeTrack.ico reports that it is an "undefined predecessor variable." I have tried unloading the WiX Setup Project and tried validating that the yellow banged Visual C++ project reference is referring to the correct path in the *.wixproj file. The include path appears to be correct:
<ItemGroup>
<ProjectReference Include="..\TimeTrack\TimeTrack.vcxproj">
<Name>TimeTrack</Name>
<!-- More not shown. -->
</ItemGroup>
I did a bit of digging and I cam across this StackOverflow posting that indicated that WiX is dependent on .NET framework. In addition, there seems to be a lot of very old postings (e.g. example 1) on this topic and I just am not entirely sure if I am just misunderstanding something here. According to this post, the WiX project cannot refer to any C/C++ code, but this appears to be referring to "Custom Actions," which appear to be an entirely different topic (?).
All in all, am I doing something wrong or is WiX not capable of deploying C++ applications? Is WiX only meant for deploying C# applications?
WiX has a development dependency on .NET but not an install time dependency.
Files are files. WiX doesn't care if they are C, C++, VB, PowerBuilder, Delphi, .NET, NodeJS, Electron or whatever.
The main differences for .NET vs C/C++ is:
1) .NET typically requires you to check that .NET is installed or author a bootstrapper to install it.
2) .NET core can typically be packaged with the app privately without a system wide installation of .NET core.
3) C/C++ typically requires installing the VCRedist via a bootstrapper or statically linking the files into your application.
4) .NET is "AnyCPU" where as C/C++ is compiled for the platform. MSI is compiled for the platoform. This means for .NET a single x86 MSI can deploy a .NET app that might run 32bit or 64bit depending on how it was built. For C/C++ you might need to create a 32bit MSI and a 64bit MSI for your app.
I have a FOSS tool that helps with learning and authoring WiX. You can read about it here:
http://www.github.com/iswix-llc/iswix-tutorials
The tutorials only hav C# examples but pull requests are welcome. Create your C/C++ application and use a postbuild copy command to stage the files to the Installer\Deploy folder and everything else is mostly the same.
I'm creating a basic MSI installshield 2014 project. I've added a custom action which calls a public method present in a managed .Net assembly (MyCSharpAssembly.dll). Now my managed dll in turn calls a method present in an unamanged/native assembly (MyUnamanagedCPlusPlusAssembly.dll) written in C++. I used DllImport methodology to load the native assembly at run time.
I added the native dlls into support files ( [SUPPORTDIR]) based on the accepted answer of this thread. I also see those native assemblies getting copied in the temporary working directory of installshield when I run the MSI output. Still, it doesn't work? When installer runs I simply get following error in the logs-
Failed to load assembly. Dll not found.
This essentially means CLR/.net run-time is unable to see the native assembly dlls at run time. Does anyone have any idea on to specifically load native dll dependencies during installation process?
I have a redistributable msi my program needs to be able to run. So far I've created a launch condition. The condition it uses is under "Search Target Machine". This needs a component ID.
This page suggests I can only determine the component ID via MSI Spy, a tool that as far as I can tell is no longer available: https://msdn.microsoft.com/en-us/library/1s08hzfe(v=vs.80).aspx
I must use a Visual Studio Setup Project, and I must distribute the 64 bit end user runtime of slimdx from http://slimdx.org/download.php.
How can I successfully get a component ID, or alternately how can I bundle an msi as a prerequisite?
MSI Spy seems an odd choice! The "standard" tool for looking in MSI files is Orca, supplied in the Windows SDK/Kit, install from Orca.msi. There are others if you search.
Look in that MSI and go to the Component table, look for a component id that is always installed (if that can be determined) and use that guid.
Ths might help with the custom prereqs:
Adding Custom prerequsites to visual studio setup project
and support for custom prerequisites in setup projects has never bneen particularly good, even when the Bootstrap Manifest Generator was around.
This might be useful if you can figure out how to alter the manifest file to add your custom prerequisite, which is what the BMG tool did.
How to install redistributable with visual studio setup?
I have a Visual C# Project that is fairly basic (no more than 100 lines) but it includes some 3rd party DLL references. Running the project on the computer it was developed on has it run just fine.
In Microsoft Visual C# 2010 Express, I go to Project->Publish <project name> and it builds some files including a setup.exe installer.
When I move those files to another computer and run the setup.exe, it correctly installs the program.
But when I run the program, it simply closes out saying:
ProjectName.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
The command window also appears for a brief second with some errors, but it's hard to make out what it is saying. It looks something like:
Unhandled Exception: System.Runtime.InteropServices.COMException: Retrieving the COM class factory for the component with CLSID { ....... } failed due to the following error: .....
I'm unable to get the command window to stay, so I cannot get the full message. But I assume this is due to the other computer not having those 3rd party DLLS.
How can I have Visual C# 2010 package everything including DLLs so this error does not appear? Or if that may not be the actual issue, how can I stop the command window from instantly vanishing? (I do not know the full list of DLLs required)
Or if the DLL is a registered DLL under C:\Windows\system32, is the project never going to build that into the package? Is there a way to see what it depends on?
Visual Studio 2010 Express doesn't create fully functional installers, but only ClickOnce installers, and those also with limited functions. This kind of installer can't register COM DLLs.
What seems to be wrong in your case is that you are using a COM DLL which isn't registered on the target system. You could try to check that in your own program (like trying to create the class and catch any exceptions that are thrown by the CreateObject function), and call RegSvr32.exe /s in order to register it. Or you just do this when the program starts the first time, before you create any object from the DLL... haven't tried that, though.
You could also make sure that you register the DLL manually on the target system before you run your program.
Moreover, when .Net uses a COM DLL, it usually creates a compatibility assembly which wraps the COM DLL and makes it accessibly to .Net. In case the DLL you use is only this compatibility assembly, you might have to locate the COM DLL it depends on manually on your system and to include it explicitly in your project's files.
In order to debug, it should be enough to put try / catch blocks around CreateObject. If that doesn't help, try adding an eventhandler for the event that is raised when an exception isn't handled by the application (this might be different according to the kind of application you create).
Specifically, I am using Wise Installation Studio to install several shared .NET 2.0 assemblies into the GAC. These are being used by some legacy COM application files as well as other application assemblies.
I have the flag for "Generate COM interop registry keys for .NET assembly" set.
Reference counting appears to be working for removing the actual assembly from the GAC, but the COM registration information is getting removed with the first uninstall via ARP.
I am wondering if there is some work around for this, if I would be better off installing the assembly to Common Files, or if there are any other suggestions out there?
How I could read on the http://www.ssw.com.au/ssw/standards/wisesetup/WiseStandards.aspx page using of "Generate COM interop registry keys for .NET assembly" allow you just add a set of registry keys to MSI. As in all Windows Installer Setups it is important to define to which MSI component a registry key or a file belong. If you make these registry keys as a part of the same components as the file and the assembly, the keys will be removed always together with the assembly. If multiple setups use the same component GUID, then only if you uninstall the last setup used the component, the component will be uninstalled.