Greetings good people of stackoverflow.
I have made an msi-installer with WIX and some custom actions built in C#. The main reason for this installer is that the original software package we want to silently install, doesn’t support this in a good way. To circumvent this issue, I extracted the files needed and put them in my own installer.
The software itself is an HMI/SCADA system containing two main types: Server and client runtimes. My focus is on the client side. This is needed to run projects made in the SCADA “IDE”.
So, my package installs the client-side SCADA, the project and my custom action creates an ODBC-connection.
The client runtime installs in the exact folders as it would have been with the original MSI i.e in C:\ProgamFiles. The SCADA client project installs in C:\ProgramData. The custom action creates an ODBC using C# and Registry.LocalMachine. The custom action also makes some changes to some textfiles in the SCADA client project in ProgramData.
The installation works well when it’s running from command prompt with “msiexec /quiet /i “Installerproject.msi”.
With all this in mind, there is one customer with an IT department that uses this package to roll out on its user’s machines. They get stuck in SmartScreen and must manually push “Run anyway”. The message is:
Microsoft Defender SmartScreen prevented an unrecognised app from
starting, Running this app might put your PC at risk.
App: “My installer name”
Publisher: Unknown.
I’ve tried use this installer on virtual machines and only with command prompt, and it doesn’t show this message.
I’m not sure what to do. Is the only way to use EV certs? Even if the original software is issued as a trusted publisher? What’s your take on this? I really need some guidance.
Best regards
Thanks Scaler for the nudge to the right direction. I have signed the installer with a CodeSigning certificate.
Related
This is my first time trying to deploy a VSTO add-in to a user's system, and I am running into a security barrier. The add-in was built in Visual Studio 2019 Community Edition and is meant to integrate with Microsoft Excel. The user runs Office 365.
On running Setup.exe, user receives the initial confirmation prompt and clicks "Install." A progress bar briefly appears and runs about 25% of the way, then an error message pops up: "Customized functionality in this application will not work because the certificate used to sign the deployment manifest for [the add-in] or its location is not trusted."
I understand that Microsoft would like me to pay for a signing certificate, but I am hoping to get this to work while avoiding that expense.
This article from Microsoft describes the use of a digital certificate as "an optional step": ClickOnce and Authenticode. This article states that an alternative route is for the user to click the "ClickOnce trust prompt" during installation: Grant trust to Office solutions. But as far as I understand the process, it is halted before it even gets to the ClickOnce trust prompt, so the user never gets that option.
For comparison, the user ran the installation on an older system. On that system he received the ClickOnce prompt, approved the software, and the installation ran successfully to the end. This indicates very strongly that the problem on the newer system is a security setting.
I instructed the user to open Excel and go to Options > Trust Center > Trust Center Settings > Add-Ins and remove the check mark from "Require Application Add-Ins to be signed by Trusted Publisher." There was no check mark to begin with, so that setting was not the issue.
I have instructed the user to go to the command prompt and clean out any remnants of the failed install with rundll32 dfshim CleanOnlineAppCache before each new installation attempt.
I'm at a loss as to where to look next. Any help would be much appreciated.
One relatively easy workaround: you pack the "publish" folder as ZIP file, disable any online checks or deployments (in the project settings, select to publish locally, not to a website. Installing from a website or auto-update won't work without normal certificate). Then give your user that ZIP. User downloads that ZIP, then right-click the ZIP file and checks "Unblock". Then unzips and installs normally. Now any certificate should do. This applies if your user downloads your file from the internet.
So the idea is very simple: Just tell your user to click "Unblock" checkbox before extracting files from the ZIP archive you have sent and running them.
Another solution, you simply tell the user's system to trust your "self-signed" developer's certificate (add your certificate to "Trusted Publishers" store on the user computer). For that you need admin rights. Please note that user's admins probably won't like this idea, unless you and your user work in the same organization. Here are the instructions: https://learn.microsoft.com/en-us/skype-sdk/sdn/articles/installing-the-trusted-root-certificate
The best and easiest of course would be if you buy a normal code signing certificate. They are not that expensive, you can get one from COMODO (SectiGo) for example for something like $70/year though their resellers.
On the target machine. you need to install and trust the certificate used to sign your addin (see Signing tab of your project options)
What is required for the certification process, is it a quick process? Are they certifying me/ my business or the code??
It is a quick process for the process:
Sign with valid certificate when publishing.
Add the publisher into Trusted Publisher before installing when Macro Settings is a high security level.
Finish installing.
You can obtain a certificate for code signing in one of three ways:
Purchase one from a certificate vendor.
Receive one from a group in your organization responsible for creating digital certificates.
Generate your own certificate with MakeCert.exe, which is included with the Windows Software Development Kit (SDK).
I am trying to deploy some MVC4 web apps with secure bindings on Windows Server 2008R2 and WiX 3.6 (stable)
I am desperately trying to get this to work without resorting to writing a follow-up powershell script or my own custom action.
The WiX iis:Certificate extension wants to install the certificate for me first before I can use it. That's not going to work in a production environment. The certificate is not going to be available to the installer at any time in .cer or .pfx form. It will already be deployed on the target machine in the localMachine/my store where you'd normally go when installing manually with the IIS7 snap-in. I will want the installer to be able to reference it by supplying any of the following: thumbprint, Friendly id or perhaps find it matching the web site host header binding pattern.
Is there any way of referencing a pre-installed certificate in WiX script without having the original .pfx file and password at build time or install time? (I got these last two scenarios working fine in test, but it isn't what the client wants).
Thanks.
I had a similar requirement to you so I wrote a post about it:
http://manyrootsofallevilrants.blogspot.co.uk/2013/07/assign-certificate-set-https-binding.html
Well it's been a while since I posted this.
Since then, I got on with it and wrote a custom action in C# to do the heavy lifting. Powershell didn't seem to give me the control of failure modes that I needed.
I can't post the code - since it belongs to my client, but I can say that I used Microsoft.Web.Administration in a similar way to that described in this question: Programatically Import Cert Into IIS. I hope that helps. It wasn't the answer I wanted, but it did solve the problem.
When I install my application on my computer I get a warning that the publisher is not verified. How can I change that? or do I need to worry about that when I distribute my application?
The application is written in Visual Studio 2008 with VB.NET
On the Project Properties window, go to the Signing tab. Create/Import certificates and sign the manifests and/or assembly.
You can find more information here, with helpful links at the "See Also" section.
You can use the signtool command line program to sign exe files or msi files. I believe you might need a certificate from an official authority to change the UAC messages.
There was a challenging situation happened when i was working with install to provide product key validation. I had to use C++ unmanaged code to validate the key. Actually we had the main validation logic written in C# and I had to create a mixed project. Problem was not stopped only with these, it continued. Since I used VC++ code, it expected atleast the VC++ runtime redistributable to be installed in the client machine. I thought of dropping the plan to migrate our install to Wix because of these kind of problems.
But I came to know that there is a nice and very cool feature that DTF is available in Wix to integrate any kind of actions in C#. I used it and could integrate the key validation in couple of hours and till now it is working fine in all client machine I implemented before 6 month.
Do you have any interesting moment or nice experience with DTF?
Search my blog at http://blog.deploymentengineering.com for DTF and you'll find a lot of useful content. I love DTF but I still believe that the best solution is to avoid a CA whenever possible in the first place. C#, like VBScript before it, is so luring that it tends to suck imperative thinking developers into writing CAs when not needed. I believe this is the reason DTF wasn't released for so long.
At my day job my approval is required for anyone who believes they need a CA. I instruct the developers on basic MSI philosphy, how to use DTF, how to attach a debugger and I make it clear that they are on the hook if it ever has any issues. The result is very few but well written CAs in our product line.
I have written several .NET CAs to support our WiX based installs:
Managed Wrapper around HTTPAPI.DLL - supports creating IP/Port SSL bindings and HTTP Url ACLs for use in deploying WCF services. I plan to turn this one into a Wix Extension. It was very interesting learning how to properly handle rollbacks, etc.
SSL Picker dialog that displays all the SSL certificates on the system and allows you to pick one.
SQL Server browser dialog - lets you browse your network for SQL Servers and then browse SQL Servers for Databases. Optionally uses impersonation. This is for crafting a connection string.
I am in the process of writing a set of CAs that will use the Microsoft.Web.Administration assembly to do native installs of web applications on IIS 7 (without requiring the IIS 6 Metabase Compatibilty feature be installed).
First off, the C#/DTF custom actions are still custom actions (no magic here :-)), so you should follow all the various CA guidelines working with this kind as well. It simplifies most of MSI tasks by abstracting low-level API behind the high level well-designed classes. Also, keep in mind that you can use managed code CA only in case the target machine has .NET installed (or install it as a prerequisite). Finally, the dtf.chm documentation which is distributed along with WiX toolset has some simple, but self-explanatory examples.
Hope this helps.
I have exported a COM+ application proxy, which generates MSI and CAB files, and I have successfully installed them on a few different Win XP and Vista machines. However, I have a WinXP box that isn't playing nicely. When I try and run the MSI it gives me the following error message:
"Error registering COM+ Application."
It stops there, not even getting as far as creating the application in COM+. Any ideas on where to look? I'm guessing some dependency is MIA, disabled, or misconfigured, but I can't seem to figure out what's missing from the magic sauce.
Also, if any of you have experience registering the client app proxy manually, that would be swell, too.
peace|dewde
Unfortunately, this particular error can have many causes, mostly IT-related. Most typically, in my experience, it is permissions issues or a corrupted COM+ installation.
I follow a few basic steps for troubleshooting this generic error.
First, make sure that you can view the COM+ applications (in Component Services) on the box. Sometimes you will get an error trying to navigate to the COM+ applications. Searching on the error message will usually lead to a Technet article that describes how to fix the error.
If you can view the COM+ applications, you'll want to double-check that there isn't already a previous proxy installed. Proxies do not upgrade automatically -- you have to remove the old proxy before a newer one is applied.
If you had a previous proxy, it is possible the files, which are located under the "Common Files" folder, were not properly removed.
Use ProcMon to diagnose any permissions errors. I have seen other installers that remove security privileges that are needed to install a COM+ proxy.
You can also generate a log of the MSI installation process. I don't usually find this very helpful, but here is the command-line syntax:
msiexec /i MyProxy.msi /l*v ProxySetup.log
With this combination of techniques, I have always been able to help our customer service team resolve literally hundreds of proxy installation problems.
Not much help, but try looking in the events log for more information.