On WPF installer project build generates setup.exe and it is being signed using Signtool on PostBuldEvent. It does show Publisher as unknown on UAC popup at the very last step of setup.exe.
Can someone help me to fix this ?
MSI vs Setup.exe: You should sign the MSI file as well as the Setup.exe file.
Certificate Type: What kind of certificate are you using? I believe you need a digital code-signing certificate from a recognized issuing authority (DigiCert, Thawte, etc...).
EV-code signing certificate (please visit this link).
Why do I still see publisher unknown with the UAC prompt?
Get a code signing certificate
Signtool.exe: If you have a valid certificate, are you using the /d option to the command line of signtool.exe when signing your MSI?:
signtool.exe /d "Your Software Name"
How to add publisher in Installshield 2018
Trust Yet Verify: When you have signed the file, right click it and select "Properties" to make sure the file is actually successfully signed. Look for the tab "Digital Signatures" (or equivalent in your own language):
Administrative Installation: Sometimes people forget that they have run an MSI through an administrative installation. This is essentially a file extract from the MSI resulting in a new MSI without the embedded CABs in the output location (more). This extracted MSI will not be signed - even if the original MSI was signed. This extracted source is used in many companies to keep the installation files on a networks share available for repair and inspection (and during application packaging to inspect the package content - and other purposes).
Post-Processing MSI: This is actually a very common issue: you must never touch a file that has been digitally signed. If you edit it after the signature has been applied this invalidates the signature. The whole point of digital signatures is to verify that the file you look at is the one that was signed by the vendor. In other words that the file has not been changed in transit to you (tampering, malware infection, etc...). More on this important issue here (attempted humor in there). Note that the tampering might happen via automation scripts and not by manual editing, hence one must always check for this cause.
Other Issues: There are also some other possibilities. The signed file could be corrupted during download or from malware attack and such things. Far beyond the question, but just mentioned for whoever might find this.
Links:
Is it possible to define a Windows Installer-uninstaller filename?
Installshield Custom Dialogue Installer
How can i generate windows certificate so my msi doesn't shows warning to users
Further Links:
Windows printscreen not working on Software Installation
WIX-Installer MSI Publisher Unknown
Everything you need to know about Authenticode Code Signing
Related
Ok, I'm out of my element but here goes anyway.
I need to do a silent install of a vendor supplied windows program. The vendor supplied an MSI file to use with the install. I created a bat file to run msiexec that contains the following line:
msiexec /i "C:\archibussilent\afm\ARCHIBUS 19.msi" /L*V C:\archibussilent\log\msi_SETUP.log
When I execute the bat file an error dialog pops up that says:
"This installation cannot be run by directly launching the MSI package. You must run setup.exe"
and the msiexe error log says:
MSI (c) (80:B0) [15:48:02:588]: Note: 1: 1729
MSI (c) (80:B0) [15:48:02:589]: Product: ARCHIBUS 19 -- Configuration failed.
MSI (c) (80:B0) [15:48:02:590]: Windows Installer reconfigured the product. Product Name: ARCHIBUS 19. Product Version: 19.3.30032.003. Product Language: 1033. Manufacturer: ARCHIBUS, Inc.. Reconfiguration success or error status: 1603.
The error # is 1603 which implies a permissions problem but I've checked the access privileges and don't see any problem.
Is it true that I can't run msiexe without running Setup.exe?
Any help is appreciated - Thanks.
The "you must run setup.exe" is a vendor authored requirement not specific to MSI in general. They may have had a good reason for it or they may have just authored it as a gate check to not have to test other scenarios.
You'll have to edit the MSI with ORCA and look at the LaunchCondition and InstallExecuteSequence tables to figure out how they implemented. Then you can create a transform to bypass the check or possible pass a property in such as SETUPEXEDRIVEN=1 to simulate being called from setup.exe. (One particularly large and well known installer development product passes this into their MSI when you create a setup.exe with it.)
The setup.exe may be serving a purpose. For example it might be authored with a manifest requiring elevation or it might be downloading and installing prerequisites or possible making sure the MSI is cached in a given location for future installation transactions.
Also I assume you want to add a /QB or /QN to make the install go silent. You'll like also need to have already elevated the cmd session prior to calling since MSI doesn't support UAC prompts when installing silently.
This is most likely an Installscript MSI file made using Installshield. This is a non-standard MSI file featuring more advanced GUI and a few other advantages. In my opinion this is a particularly problematic type of setup due to a few serious bugs without suitable workarounds. I consistently recommend this project type to never be used. It is especially problematic for corporate deployment.
These setups feature a number of command line parameters for the setup.exe file. As Chris states you can probably run it via a transform and set the property SETUPEXEDRIVEN=1 and you may try to use setup.exe /a to run an admin install (More info: purpose of an admin install). This will extract all cab files (if any) from the MSI and put the files on a "network installation location" for use in corporate networks - essentially a smaller MSI with the setup files next to it. I have seen setups that then will allow to be run directly from the MSI - just give that a shot too.
As to the reason why these setups require setup.exe to launch:
In prior editions of Installshield the Installscript language runtime had to be installed prior to launching an Installscript based MSI. This appears to no longer be the case since Installscript is now run without a runtime.
The setup.exe is there to install any updates to the Windows Installer Engine (msiexec.exe), and for that to be possible a setup.exe launcher is needed. Such an update is rarely required, and should today be done via Windows Update.
A number of legacy features, such as being able to access the Internet (!) via the setup.exe (highly undesirable for corporate use), download runtimes and components and extract temporary files are also done via the setup.exe.
And there are other features too, most of which are undesirable for corporate deployment.
Here is a previous answer from me on a similar issue featuring a link to a PDF with actual sample command lines.
I have a simple Windows Form application(WPF) with entity framework. After compiled, only a few files generated:
EntityFramework.dll
EntityFramework.xml
MyApp.exe
MyApp.application
MyApp.exe.config
...
Then I just copy following files to a network shared folder:
EntityFramework.dll
MyApp.exe
MyApp.exe.config
Then I can double click on MyApp.exe from developer computer the launch the app, but can not launch from another end user computer.
How to resolve this problem?
When you double click, app is not launching means certainly it is crashing so type the command eventvwr in run or cmd it'll open the Event viewer in that go to Windows Logs and Click on Application, you can see different levels of logs in that just find the last error log view the details it might help you
Have a look in the event log on the target computer and look at the error that is actually being reported.
It could be a missing installation of the correct version of the DotNet framework as suggested in the comments above, or it could also be that the execution policy of the target computer is preventing the user from running from a network drive (As a developer you probably have admin rights on your local pc allowing you to do this).
Whatever the actual cause you are always better to use some form of installer, rather than this form of putting files on the network (commonly known as xcopy deployment).
Probably the best solution is to use Visual studio to generate you a click once installer and publish it to your network drive. This will then copy the application locally on the users pc and run it from there.
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building
I have a .NET winform application that requires to register a native dll during installation. My question is how can I register a dll (regsvr32 ABC.dll) as part of MSI installion process? Similary how can I un-register a dll as part of un-installation process?
Nice answer from Chris Painter, adding for reference: how to register DLL's properly in wix 3.9. And one with WiX-focus: Registering COM EXE with WIX.
Self-Registration considered harmful
The proper way to register a COM file is to extract the COM registry information from the file and add to the appropriate family of COM tables in the MSI. Most MSI tools have features to support this COM extraction, see separate section towards the end of the answer for details.
This MSI SDK article lists several variations on the general issues with self registration described below, as well as describing some further details - particularly with regards to per-user registration of COM data, and run-from-source scenarios.
Extracted COM data will ensure reliable installation of your COM server as well as support for advanced MSI features such as "advertisement", "rollback", resiliency and "elevated privileges". You can read more about these advanced MSI benefits in this summary that has become somewhat popular on serverfault.com: corporate benefits of MSI.
It is also possible to use the built-in SelfReg table in Windows installer to register the file using regsvr32.exe as part of the installation process (or even invoked as a custom action), but this is considered bad practice for a number of reasons:
Rollback: Windows Installer is unable to properly handle rollback unless the COM data is extracted and embedded in the MSI. The result is that a failed setup may not clean up its COM footprint correctly and the MSI does not put the machine back in the original state properly. The rollback of COM data really does work like "auto-magic" tracking every change in the registry whether it be addition, modification or deletion and is reliable when done right.
Security: The self registration process of a COM server may in certain cases perform unorthodox tasks such as modifying the system's network settings or perform other crazy maneuvers that have nothing to do with COM and are hard to identify and debug. I have personally seen, in disbelief I might add, COM registration change system-wide network settings without any warning, and for no obvious reason. It might have been just an optimization for an application, but this is rarely acceptable when it changes the whole system affecting all other software. Though an EXE file run in admin mode can do the same and be equally faulty, self-registration may go under the radar and be less obvious as a security issue. This is a core reason why large corporations and Microsoft best practices insist on not allowing self-registration as it may interfere with business critical systems.
Chained dependencies: Some COM files may need to be registered in a specific order on the system to register successfully. In other words file B can't register until file A has been registered. I have honestly never seen this in real life, but it is technically possible, and I have seen dependencies on language dlls (resource only dlls) cause COM extraction to fail. Though slightly different, it is still a dependency issue. MSI does not allow specification of the registration order (probably due to the database origin of MSI, rows are unordered). If you extract the registry data properly on the build computer and put it into the MSI, these chained dependencies will not cause an application error.
Permission problems: Windows Installer has advanced features to elevate the privilege level of the user installing the MSI to allow all information to be registered without permission problems (no messing about with temporary admin rights). If you use the SelfReg table you are more likely to run into registration problems caused by permission or privilege peculiarities on the local system (in my experience this is particularly evident for self-repair operations). Permission problems like these occur more and more as new versions of Windows steadily put new obstacles in place for the successful deployment of software (UAC prompts, self-repair lockdown, impersonation changes etc...).
Resiliency: If another application destroys your COM registry entries, the COM data embedded in your MSI will reinstall the COM component with all associated registry entries via self-repair if proper COM extraction is used to make the package. This means that your application should always be able to launch with its COM servers properly registered. However, this can also trigger the dreaded repetitive sequence of self repair cycles that many experienced computer users have seen (here is a simpler and shorter explanation). In other words COM extraction can be riddled with problems as well, but just using self-registration would leave your application broken, and also prone to security errors being triggered if you run repair, modify or self-repair of your product (the self registration operation may run without elevated rights and hence fail to complete if the repair is run as a restricted user). This means the errors are impossible to fix for most normal users. It is all they know how to do if the product isn't working.
Advertisement: Advertised products are available to the user via shortcuts and registry entries, but not presently installed on the machine. An "on demand" installation can be invoked in a handful of ways - referred to as advertised entry points (recommended Symantec article), one of which is the invocation of an advertised COM server. No install will be triggered unless the file is properly advertised in the registry and a crucial trigger of "self repair" is hence missing if you use self-registration.
Installation Tool Support for COM Registration
The extraction of COM data and entry into MSI tables is a fairly involved task, and most tools on the market such as Installshield, Advanced Installer, and Wise (Wise is now off-market, unfortunately) have automated solutions for this.
In Installshield you simply enable a component flag called "Extract COM data on build", and Wise has a similar flag on the component level. WiX can extract the COM registry data using a tool called heat.exe and the generated WiX-code can be inserted into your source WiX file (there may be new features for this by now that I am not aware of). I am not aware of any features in Visual Studio that will extract the COM data automatically, but it looks like Chris Painter provides a possibility in his answer.
Check out RegSpy2 if Heat doesn't work for you (Phil Wilson - the author of "The Definitive Guide to Windows Installer" wrote RegSpy and someone extended it to RegSpy2). Also check this: Register ActiveX exe server using WiX (my answer towards the bottom for regspy.exe command line use).
Erroneous COM data inserted into an MSI - particularly for repackaged applications in corporate environments - is one of the leading causes of "unexpected cyclical self-repair". Please see this long article for explanation of this issue: How can I determine what causes repeated Windows Installer self-repair? (bullet point 3 in section "Some typical self-repair problem scenarios" describes this issue).
Several other installation tools exist with similar extraction features: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc
vsdrfCOMSelfReg is not a best practice. Try vsdrfCOM instead. This will "extract" ( or try, vdproj is a POS sometimes ) the COM metadata from the DLL and author it into the correct COM tables. This is better then hoping an out of process call to DllRegisterServer will work at install time.
Now that MSI is natively aware of your COM resources, it will handle install and uninstall for you.
Scroll down to Rule 19 in the Tao of Windows Installer to see what the MSI team said:
Using the self-registering capabilities of certain DLLs is highly discouraged. Any activity performed by the self-registration (e.g. addition of registry entries) is out of the control of the Installer, so cannot be part of advertisement, repair and is not removed on uninstall. Instead you should have the Installer manage the data for you by using the appropriate tables in the MSI database.
Select the file you want to register and in the Properties window set the Register field to vsdrfCOMSelfReg. This will author an entry in the SelfReg table which will automatically register / un-register your DLL.
http://msdn.microsoft.com/en-us/library/aa371608(VS.85).aspx
I'm trying to figure out the easiest and most secure way to Authenticode sign binaries in one of my projects.
The easiest way I can see to do this is to grab the result of compilation--a completed install package containing all my binaries--extract the assemblies from it, sign them, then repack these signed assemblies in the MSI which then gets signed.
Lots of information out there about unpacking files from an MSI, but nothing about re-packing them. How can I do it?
Editing my original response....
If you want to embed signing into your unattended build process, you can just use the MSBuild SignFile task, which wraps the authenticode signing APIs http://msdn.microsoft.com/en-us/library/ms164304.aspx
Alternatively just use a call to SignTool.exe.
You will need to install your Software Publishing certificate onto the machine using certmgr.exe or the certificates mmc snapin. Once it's installed into the local certificate store you just reference it using the SHA thumbprint, which you can find on the certificate properties or by just listing the cert in certmgr.exe.
We have to regularly update our certificates so we have additional steps in our build to re-import the certificate locally at the start of the build, and pull in the certificate hash. I would advise against storing the hash in source control in case you have to go back and build an old version - it should be part of your environmental configuration, e.g. an env var or something else that can be decoupled from your source code.
Also, don't forget to timestamp the signed files so that the validity of the signature can be guaranteed. I would also advise you to decouple signing from timestamping. Timestamping is a network operation that can occasionally go wrong, so it's useful to be able to discriminate between a signing failure and a timestamping failure, since a timestamping failure is only an issue for gold builds that might be released publicly.
You don't state what your build system is, but the (overly simplified) flow my projects go through are as follows (I use nant tasks for pretty much everything, triggered from CruiseControl.net)
Grab everything from source control
Build clean project
Grab unsigned files
Using signtool.exe sign all relevant files (e.g. exe, dll, ocx)
Build MSI (with WiX)
Do some custom post-build tasks on the MSI
Digitally sign the MSI
(Depending on build parameters) Compress MSI with a bootstrapper
Sign the bootstrapper
Upload to a staging area
Email Dev+QA teams that build is ready for testing.
If it fails anywhere along the way, then just email the Dev team.
You should be able to do this with MSBuild, Nant, or a variety of other tools. It'll probably involve a little custom work in places, but the end result is a reliable build system that requires zero human interaction with the build (unless someone wants to 'force' a build, even that is just clicking a button on a webpage or something)