I'm struggling to get a ClickOnce setup working successfully with a bootstrapper. I'm building a VSTO add-in, and all worked well with a self-signed cert for development, but now we're setting up a proper certificate and it's failing in interestingly challenging ways.
The deployment uses a separate bootstrapper .exe, which is set as a dependency, to prompt for a few settings. Again, all this worked with a self-signed cert.
So the add-in builds okay, with a few post-build steps on the main component, as per:
"mage.exe" -update "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_
"mage.exe" -update "$(TargetDir)$(TargetName).vsto" -appmanifest "$(TargetDir)$(TargetFileName).manifest" -CertFile "E:\COMODOCodeSign.pfx" -Password _pass_
The build works, the publish works, all looks good.
However, running the setup starts with the bootstrapper's EULA, and after acceptance, then I get the message:
Setup has detected that the file somewheretemp\bootstrapper.exe has either changed since it was published or may be corrupt.
Now, I am not "publishing" the bootstrapper. In the directory where it's stored as a dependency, there's no manifests, and I'm not signing it at all. So I can't see how/where it has decided that's changed.
And although there are answers on the web, they all involve poking through manifests to find differences, and there aren't any manifests for the bootstrapper, and there are no traceable references to the bootstrapper in the signed VSTO manifest. At least, not that I can find with a grep on the published output.
So to the questions:
Any ideas how to proceed?
Should I sign the bootstrapper? (manifests and/or assemblies) -- I did attempt this but it didn't seem to make any difference.
The issue appears to be in Publish > Prerequisites... in the project properties. I'd set it to have an installation folder URL, but I'd not (yet) copied the files there, this was me attempting to test the installer before I got to that point.
As soon as I removed a URL from this field, all worked okay, and the bootstrapper application started correctly. So there might still be a challenge getting web install directories right, but this particular issue is resolved.
Related
I am bringing a WPF to the Windows store using a "Windows application packaging project" since 2 years. Until I freshly installed my development system, everything was fine (as usual). When I open the project in VS2019 and start to build the app-package in the publish section, all processes run through but it stops at package signing with "Error signing ....appx".
After checking the EventLog at "Applications and Services/Microsoft/Windows/AppxPackagingOM" there always are 4 warnings in a row with all the same ID 216 saying "app manifest validation warning declared http://schemas.microsoft.com/developer/appx/2015/build-Namespace is inapplicable"
I have never experienced signing errors especially because I am not using any self signed certificate or sth like that.
Any ideas?
This should be a known issue, the specific discussion is here
You can resolve this issue by uninstalling the KB4535996 patch update.
I am installing my application in a fully offline environment. Our machines will be completely incapable of connecting to the internet during production scenarios.
I am writing a WiX Burn custom bootstrapper, and part of the reason was to install a Microsoft root certificate required for .NET 4.7.2 to install properly on Windows versions earlier than 8.1. My original plan was to use the .NET certificate namespace to do this, but aside from the warning that popped up saying not to, I realized that Burn runs at the current user's elevation level, which means that it would likely fail to install the certificate without acquiring elevated privileges first.
According to a Microsoft document regarding installing certificates for Visual Studio, the preferred way of doing this is to bundle a copy of of certmgr.exe with your program and call it to add the certificate to the root store.
Is it best practice or even possible at all to do this using an ExePackage element? As in, setting the element to call certmgr, set InstallCommand to /add MicRooCerAut2011_2011_03_22.cer /s /r localMachine root, PerMachine to True and let it rip? Or does ExePackage have some kind of special behavior?
Long story short, one of my my employer's clients has an aaS platform that relies on a piece of software that's a ClickOnce app. This particular app is developed by a 3rd party software developer, and licensed to my employer's client company. It also happens to have a large number of prerequisite/dependency applications that need to be installed in order for it to function, but are not deployed as part of the ClickOnce installation. Importantly, because it's developed by a 3rd party and licensed, it's not possible to make any changes to the application itself.
Thus far, actually installing the application on endpoints has been handled by the client company by providing a pre-imaged computer, or when their client wishes to use their own hardware, giving their customer service reps a large zip file containing a bunch of .bat scripts they have to run manually on any computer that's to be used as an endpoint for their service. The batch scripts basically do the job of a bootstrapper and install the prereqs, make necessary system configuration changes and checks, and then call the ClickOnce application installer.
As expected, they don't like this solution, and would like an actual installer, so I've set about creating a bootstrapper with WiX/Burn, but I'm now stuck on how to include the ClickOnce application in my bootstrapper project. I can't seem to find documentation on this online, prompting the question:
Can I bundle a ClickOnce application into a WiX bootstrapper? How?
If it makes a difference, the ClickOnce application is published from one of the client company's servers, so I have full access to both the ClickOnce manifest and all the .deploy files.
You can't make a silk purse of a sow's ear. I think the best you can do is make a dependency installer for a certain version of the ClickOnce installer. No one should expect that a future version of the application would have the same dependencies.
(By that time, though, maybe they'll fix their ClickOnce installer by including dependencies. Or, abandon dependencies that they are having trouble putting into ClickOnce, say those needed for obsolete versions of Windows.)
Once dependencies are installed, you can have the bootstrapper launch the application, which would install or update it. (Logically, this follows the Chain.)
<Variable Name="LaunchTarget" Value="http://example.com/path/product.application"/>
Backing up a bit, you could create an MsiPackage with all of the ClickOnce files, and use a "file://" URI for the LaunchTarget. This would require you to rebuild and redeploy each new version (defeating the nature of ClickOnce), but would isolate you from untested application updates.
Apologies if this has been answered before.
Something happened to my VS2010 SP1 VB.NET environment. I have been successfully working on, compiling and publishing project A via ClickOnce for a while, and then tried to publish project B, and received the error:
Could not find file 'obj\Debug\Program.exe.manifest' in file microsoft.common.targets. When I look at the microsoft.common.targets file, i receive > 101 warnings.
The Help tells me its error MSBuild Error MSB3113.
Now ALL projects behave in the same way, including the one that I was publishing.
Things I have tried:
Create new project in new location. same error during publish.
I moved both projects to a different machine, and both publish without problem.
I reinstalled VS2010 from scratch into a different location on the problem machine, and the error re-appears (problem machine is Vista, ok one is Windows7 prof).
Tried every variation of deployment, unsigned, signed etc. All projects are in VB.NET and it is unclear how to turn off the manifest inclusion via the VS2010 settings. I have tried doing this via changing the project information in the .vbproj file to
<PropertyGroup>
<GenerateManifests>false</GenerateManifests>
</PropertyGroup>
without effect.
The project occasionally build successfully, but then fails to publish. The pattern to this I have not yet fully understood.
Any advice appreciated
Peter
It might be worthwhile to delete the current manifest, and the generate a new one per the instructions found here:
http://msdn.microsoft.com/en-us/library/ms766454.aspx
Or, alternatively,
http://msdn.microsoft.com/en-us/library/ms235229%28v=vs.80%29.aspx
I looked at this answer:
Install a pfx certificate in a users store in Windows using WiX
to install the certificate through wix and seemed to work fine, the certificates (i need two) were installed in the correct location stores and had the correct values for issues to and issued by.
However, when i tried to use them in my installed application, i get keyset does not exist exception.
When i manually install the pfx file using MMC->import from exactly the defined location in wix, it works fine.
The permissions are slightly different in the sense that wix has added owner rights and msiserver permissions and removes the temporary S-1-5-5-0-XXXXX read permission that i cannot manually add.
Does anyone have any idea what would be causing this problem?
This is not a permissions issue but a problem with the way msi's are installed.
To get the required permissions to install a cert, this action has to be run as a deferred action, which runs under the system account.
The system account has no profile which I believe is required to install the cert with the private key (I reckon the private key is temporarily written to the profile before moving to the MachineKey store).
I have managed to get my msi to install the certificate with the private key but it was a bit of a mission...
I created a console app that generates and imports the cert.
Drop this exe in the installation folder as part of the installation.
Using an impersonating CustomAction, spawn an elevated PowerShell command (-Verb RunAs).
Run a script that executes the exe.
As I said a bit of a mission but in now works perfectly! :)