I have a WIX executable install package which for the sake of simplicity lets just call setup.exe. Using a Powershell script I need to do the following with this package:
1. Deconstruct the setup.exe WIX package.
2. Unpack the setup.msi file contained within.
3. Modify a config file within the unpacked setup.msi.
4. Repack setup.msi with this new config.
5. Reconstruct the setup.exe WIX package.
Currently I can do steps 1 to 4 in the following way:
1. Run dark.exe -x OutputFolder1 setup.exe.
2. Run ms2xml.exe -c OutputFolder2 setup.msi
3. Update the config file.
4. Run xml2msi.exe -m setup.xml
Unfortunately at this point I can't recreate the WIX package using the modified setup.msi even though OutputFolder1 appears to contain all the information that WIX would need to recreate the package.
Therefore is there a way to recreate a WIX package that was deconstructed using dark? Alternatively is there another way to achieve this without using dark?
You need Light.exe to rebuild a bundle. It can't start from a decompiled bundle.
Related
In order to make install scripts and understanding existing ones, I would like to know what happens behind the scenes of the typical:
choco install notepadplusplus
I found the following here:
Installation
Chocolatey uses Nuget.Core to retrieve the package from the source.
Choco determines if it self-contained or has automation scripts - PowerShell scripts (*.ps1 files), and soon to be open to Scriptcs files in the 0.9.10.x timeframe (I know, right?!).
Choco takes a registry snapshot for later comparison.
If there are automation scripts, choco will run those. They can contain whatever you need to do, if they are PowerShell you have the full power of Posh (PowerShell), but you should try to ensure they are compatible with Posh v2+.
Choco compares the snapshot and determines uninstaller information and saves that to a .registry file.
Choco snapshots the folder based on all files that are currently in the package directory.
Choco looks for executable files in the package folder and generates shims into the $env:ChocolateyInstall\bin folder so those items are available on the path. Those could have been embedded into the package or brought down from somewhere (internet, ftp, file folder share, etc) and placed there.
That given,
How can I get the .nupkg package URL? In general it seems like this:
https://chocolatey.org/api/v2/package/package-name
Which is the .nupkg package download directory?
Where is the content of the .nupkg package extracted by default? This is important since chocolateyInstall.ps1 sometime uses Split-Path -Parent $MyInvocation.MyCommand.Definition.
"Scriptcs files in the 0.9.10.x timeframe" is rather cryptic. Can you give some references?
Is Posh v2+ simply short for Powershell or is a specific technology?
There are several executable files in $env:ChocolateyInstall\lib without a link in $env:ChocolateyInstall\bin. For example, the mpv.exe of the mpv player is not linked.
Yes, that download URL seems correct. The download directory is always into the Chocolatey installation folder, then lib\packageName, and this is where contents are extracted to.
Right now, installation scripts are only written in PowerShell. This comment is referring to the ability to write in installation scripts in C#, using the ScriptCS run time. Currently, this isn't yet supported.
Yes, this is just a short way of referring to PowerShell.
In the case of the mpv package, you will notice that there is an mpv.exe.ignore file. The presence of this file in the package prevents a shim being created.
I've been reading about building RPMs, and the process is quite complex. Is there any program/software that works like this:
Download tar.gz file. Extract to directory
cd into directory
Run
RPM file is output into the directory
Does any such program exist? It seems as if it should. After all, when I run make, make install etc, I don't need to specify spec files, provide locations for where the software has to be installed. So why should I have to do all that for creating RPMs?
I've tried using checkinstall, but I keep getting errors like "Directory not found: /root/rpmbuild/BUILDROOT/hello-2.10-1.x86_64/usr"
So is there an easier way?
No. There is no easier way.
Sometimes upstream provide 'make rpm' target. Sometime checkinstall works. But often you have to create the spec file manually.
BTW that error from checkinstall reveals two things:
you are running that command as root. That is very very unwise.
you should create few build directories. Run command rpmdev-setuptree it will create them for you.
After building a package how do you install it on the system?
For example, I'm trying to install Swift language server but I have no idea what to do after swift build. Do I have to copy executables and libraries manually?
In CMake/make world there is always a make install step. Is there anything similar in Swift package manager? There doesn't seem to be an install command or something similar. Am I missing something?
Swift Package Manager produces plain executables, in .build/debug or .build/release directory. You can see the last line in its output Linking .build/debug/<the name of the main module in the Package>.
If not specified otherwise, you can just run the result executable, as any other executable, by typing its path in the command line and providing parameters as needed.
Swift Package Manager does not support custom scripts or targets, like install, deploy etc. If there is a need for installation/deployment automation, it should be done by additional scripts or tools, like Makefile.
When building a NuGet Pack to an output directory, I do not want it to overwrite an existing version
Existing command:
".nuget\nuget.exe" pack "some.csproj" -output "c:\~packages"
I have looked through the documentation and cannot seem to find a switch that does it. I tried using a if exists "c:\~packages\some.nupkg" exit 1 but the problem is I do not have access to the version number in that context, so I cannot predictably provide a version to check for
This is not currently possible using NuGet.exe.
The options are:
Modify NuGet's source code to allow an extra command line option to support not overwriting the existing NuGet package if it exist. The PackCommand could be changed to support this.
Write a utility to generate the correct package version, then check the package exists before running NuGet.exe. The package version information is read from the AssemblyInformationalVersionAttribute taken from the project's output assembly if you are using nuget pack projectfile.
I create some modules without using Module::Starter :(.
I need to build a MANIFEST file to run my tests.
Should I do it by hand, or is there an automated way to build it ?
Run make manifest or ./Build manifest, depending on the build tool.
It will call mkmanifest for you.
You can create manifest using ExtUtils::Manifest package:
perl -MExtUtils::Manifest=mkmanifest -e 'mkmanifest()'
This oneliner will create manifest in current dir. It also will use MANIFEST.SKIP if you have one.
If you install Dist::Zilla, you can set up a simple dist.ini file and then run dzil build. That will create a MANIFEST and other necessary files for releasing a distribution.
Well, there is ExtUtils::Manifest:
mkmanifest
mkmanifest();
Writes all files in and below the current directory to your MANIFEST. It works similar to the result of the Unix command
find . > MANIFEST
All files that match any regular expression in a file MANIFEST.SKIP (if it exists) are ignored.
Any existing MANIFEST file will be saved as MANIFEST.bak.
For example:
$ perl -mExtUtils::Manifest=mkmanifest -e 'mkmanifest()'