dotnet
Signing in Linux
When I try to sign with dotnet-mage -Sign Application.application -CertFile /root/file.pfx -Publisher "publisher" in Linux it says
Internal error, please try again. Unable to load shared library 'Kernel32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libKernel32.dll: cannot open shared object file: No such file or directory
I found in the source code, that CryptoAPI is only supported in Windows. Are there any alternatives to get manifests signed without Windows?
[Triage] @TheCollegedude can you share some details about your end to end scenarios? ClickOnce application can only be installed on Windows as Linux does not have ClickOnce runtime components.
dotnet-mage is platform agnostic, but it was built from an old Windows-only tool Mage, to run on .NET 5. Some code, like signing, requires tooling that only exist on Windows.
I've updated readme to clarify that dotnet-mage is fully supported on Windows. We are gathering feedback about scenarios for usage of the tool on Linux agents.
This and similar issues are very valuable for planning future work.
[Triage] @TheCollegedude can you share some details about your end to end scenarios?
I have an embedded system that runs on Linux and it updates its firmware bundled together with the client software to access the system. The system acts as a server so that the user can run, download, install or update the client software. Unfortunately, ClickOnce refuses to work if the source has changed. When building the ClickOnce package, I have to specify a location and may not change it later on, unless I sign it again. I would like to re-route the location to the embedded system.
Similar issue here. We are building a large application, deployed on OpenShift, composed of several REST APIs, multiple Blazor web apps and a Word VSTO plugin (which we distribute from a web server hosted in the same platform). We would like to build once (using Azure devops pipelines) and deploy on different environments, each with is own distribution url. We managed to automate the process but the very last step (applying environment-specific configuration and sign the manifests) can't run on the OpenShift platform. As a workaround, we prepare all different possible manifests for known environments at build time, which is obviously not ideal.
