If I understand correctly 'The Publisher Could not be verified..' alert appears in Windows7 and XP when you're trying to run digitally unsigned .exe or .msi file.
So, I created installer for my project (I use InstallShield 2012 Limited Edition for this purpose), built it and got Setup.exe. I didn't use any certificate to digitally sign my setup.exe.
May be I missed smth, but I cannot understand why I'm not getting Unknown Publisher Security Warning when launching my unsigned setup.exe and trying to install my app on my Win7 box?
The warning is only displayed if the EXE is manifested to request elevation. If you build it with the AsInvoker setting it won't need to therefore no prompt.
However, assuming it's a Per-Machine install, it'll prompt for elevation when you transition from the InstallUISequence to the InstallExecuteSequence.
Related
I have been building AutoCAD OEM based applications for years now. Just recently, I stumbled upon some freak error I have not been able to resolve.
With the AutoCAD OEM platform, there is an Installer Wizard that creates an installer for the (gargantuan) application. The application installer is started (of course) with calling the setup.exe.
With the last AutoCAD OEM versions up until AutoCAD OEM 2022, the signing of the setup.exe has been no problem at all.
Now, with the current AutoCAD OEM 2023 version, the signing of the setup.exe does not work anymore. When trying to sign the setup.exe, the error 0x800700C1 returns. This is a very generic error message, and googling after this does not bring any helpfull results.
error message of signtool.exe
Before signing the setup.exe, I always use the delcert tool (delcert-sign-strip-tool), which always works as intended.
When using this on the current setup.exe, delcert returns an error message:
error message of delcert tool
It seems that delcert succeeded, but when trying to sign the file again, it fails again with the same error message:
error message of signtool.exe
Looking with dumpbin on the headers, I noticed that the setup.exe for AutoCAD OEM 2023 is a x64 file:
dumpbin for setup.exe of AutoCAD OEM 2023
Whereas the previous versions setup.exe has been an x86 file:
dumpbin for setup.exe of AutoCAD OEM 2022 and lower
This seems to be a random correlation but may be the source of this problem.
Has anybody experienced a similar problem (not neccessarily in the AutoCAD ecosystem)?
Thanks,
Jens
I have purchased a certificate from http://www.ksoftware.net/ which I use to sign a .CAB file used for installation of our software on windows mobile 6.5 devices. However, even after signing the .CAB, when attempting to install the application on the device (via the CAB) the device alerts "Unknown publisher". These CAB files are downloaded from a webservice and are supposed to be installed automatically using wceload and its silent install options, but this fails since the CAB is not recognized as signed (once I have manually installed a particular CAB file, wceload will succeed for that CAB in the future).
Initially I only had the certificate set in the visual studio 2008 deployment properties, and the applications signing properties. I also tried using signtool.exe, and thereafter cabsigntool.exe to sign all the other files in the CAB too. None of these methods work. When checking the CAB's properties in Windows 7, the file does have a security certificate attached, but any attempt to install on the device gives the annoying "unknown publisher" popup box.
Is there anything I am missing? What could be causing the devices to still see the CAB files as unsigned? The signing does not seem to work with plain exe's either.
Please note I do know the security settings can be changed in order for the prompt not to come up, but I am interested in solving the security certificate problem.
I assume the root certificate of the sign is not know on the device:
Did you verify that the certs are WindowsMobile compatible?
We have few windows services developed using .Net framework 1.1(VS2003).For each windows service an msi installer(set up project) is created to make installation easier.These installers are able to install windows services successfully in windows XP.But these installers unable to install windows service in WIN7 though I have admin privileges on the machine in which I am trying install them.While I am trying to install the windows service in win7, Through msi installer,installation is progressing till 90%.After that it is neither completing nor throwing an error.I am unable to understand what the problem is.
I tried following ways.
1.Opened cmd window in admin mode and tried to execute the msi with the command msiexec -i --Din't work
2.Right clicked on the actual exe(windows service exe) file and tried to run it in admin mode.--Din't work
3.Changed the UAC to never notify, restarted the machine and then tried to install--Din't work
4.Right clicked on both exe and msi and open their properties and changed the compatibility to lower version of windows and tried to install--Din't work
One thing I have noticed is that for all the custom actions of our windows service installer, primary output of our main project(exe) was given as input.I build the msi installer by removing all the custom actions.Then i tried to install it in win7.Then it was installed.But during the installation system not prompted for account details (which is the actual case while installing windows service) and also the service was not appeared in services manager window.
I spent somuch time to identify the cause and resolution.But I dint find any posts on this issue.I suspect that the problem is with custom actions.But not sure.If the problem is with custom actions please let me know how to overcome it.
Please provide a resolution for this issue or share me if there are any links which talks about this.
FWIW, .NET 1.1 isn't supported on Win7. Also I'm guessing you are using InstallUtil custom actions to drive the setup of your .NET Windows Service. These are very fragile and you can eliminate all those brittle points by refactoring and using the ServiceInstall ServiceControl tables in MSI.
I'm using a very old version of InstallShield Express 4 to package my VB6 application. Installing it on XP, it works great. But when I install it on a Windows 7 box, not using the "run as administrator", everything seems to be read-only. I can't edit an INI file because access is denied. The application just doesn't function properly. It's almost like it can't even access the folder. And it's installed in the default "program files" folder. I uninstall the application, reinstall using the "run as administrator" option, set compatibility of the short cut to "run as administrator", and everything works fine.
My question is this something inherited in VB6 where the application has to run as administrator or is it an InstallShield issue? And if it is an InstallShield Express issue, would the latest version of InstallSheild Express 2012 fix this? I would prefer the user not have to worry about installing or running the application as an administrator.
Nothing is specifically wrong with your VB6 application. I would say it's the older version of InstallSheild which might be the problem in this case.
The feature is called User Access Control (UAC) that has been introduced in Windows Vista and the following Microsoft operating systems to prevent arbitrarily write access into %ProgramFiles% by applications. You can still perform it manually (by copying and pasting files into %ProgramFiles%) but UAC will prompt for your permission.
To make sure your application behaves expectedly, save application settings in %APPDATA% or in registry, NOT in %ProgramFiles% directory. During installation or uninstallation of your program which requires write access into %ProgramFiles%, you'll have to run it as administrator (unless of course you have UAC disabled which is a massive security risk and strongly recommended against).
Yes, there is something specifically wrong with your VB6 app. It is storing its data in the wrong place. Your application cannot access the program files folder, unless it is running as administrator. This is due to User Account Control, as explained in gsabil's answer.
Here are some solutions (the best one last)
Always run the VB6 app as administrator.
Turn User Account Control off. This opens some security holes and is not recommended
Make your install program change the permissions on your installation directory, granting write access for all users. This is rather a hack, but it could be a fast way to get your program working
Change your application (not your install program) so that it stores its data in %AppData% rather than in the installation directory. This is preferable. Here is some detailed advice on how to do this in VB6
I'm writing a batch script that needs to install Microsoft Lync if the user does not already have it installed. Then, it will install my custom Lync UI after that. What is the best way to check if Lync is installed considering:
This will run at user logon and should be fast
The user could be using a 32bit or 64bit Windows (XP or 7)
Check if the files either exists in program files or Program files(x86)