I am installing an major upgrade of product in my system.
Folders and registry entries will be updated for this.
I would like to take snapshot of folder structure and registry before/after installing update so that i can compare them easily.
Is there any tool or simple powershell module available to do this?
I hope testers would have done this while doing installation testing. If you have followed any good approach ,please update us.
One of the best tools I've come across for before/after registry comparisons is called RegShot:
http://portableapps.com/apps/utilities/regshot_portable
The 1.8.3 version supports 64 bit registries:
http://sourceforge.net/projects/regshot/
Yet another tool is called ZSoft Uninstaller:
http://portableapps.com/apps/utilities/zsoft_uninstaller_portable
This one is tailored toward software installation analysis.
Both of these can perform registry and file system before/after comparisons.
Well, practically, I think you'll have to limit the paths you want to "monitor". You can use the PowerShell provider for registry very easily. For example:
Get-ChildItem -Path HKCU:\SOFTWARE -recurse | Out-File HKCU_Software.reg
More information here. Then, you can make a diff (before, after) using a tool like DiffMerge. Same principles for directories.
However, once again, beside a shallow check, I don't think that approach is realistic.
Don't know your context, but Microsoft's Attack Surface Analyzer might be useful.
I recommend RegistryChangesView by NirSoft.
It could be particularly good for you as you mentioned PowerShell modules in your question, and RegistryChangesView has documented command-line options. RegistryChangesView also supports exporting the comparison to a .reg, HTML, or CSV file etc.
I'm still looking for a tool that can directly output the difference in the form of PowerShell commands; until then, I can export to a .reg file and then run it through a .reg-to-PowerShell-commands converter.
Other options include the classic Regshot which has also been forked as Regshot Advanced. However, personally, I go with RegistryChangesView because I think it has better documentation/command-line options.
Related
I'm writing my first KDE plasmoid using QML. The hello world example uses a metadata.desktop file, while this KDE Plasmoid tutorial talks about a metadata.json instead and says that the metadata.desktop is 'discouraged' now and a desktop file should be converted to json using desktoptojson.
However, when I browse the globally installed plasmoids under /usr/share/plasma/plasmoids/ they all have both the metadata.desktop and metadata.json.
First question: So, what is really recommended? Just the metadata.json? Or both?
And, I wasn't able to find the desktoptojson tool. I'm using Linux Mint and the ./kdesrc-build --initial-setup for debian based systems says that it's "This is woefully incomplete and not very useful" ... I read that "most users of this [i.e. desktoptojson] utility will use the CMake macro kservice_desktop_to_json as part of the process of building a plugin.". However, I haven't found the documentation yet how to use this.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
Thanks!
First question: So, what is really recommended? Just the metadata.json? Or both?
In the current source code, most stock KDE applets such as the task manager use metadata.json's and have dropped the metadata.desktop's. It may be that the desktop files you have locally are left over from old versions, the new format was installed but the old one was never deleted.
Second question: In case one should maintain both files (for whatever reason), should I use desktoptojson to keep them in sync? And if yes, how?
The man page on Arch you linked to has all the information. The tool is part of the package kservice. Find the equivalent in the repository for your distribution. Then, to use it
as part of a CMake macro:
add_library(myplugin MODULE ${myplugin_SRCS})
kservice_desktop_to_json(myplugin myplugin.desktop)
directly on the command-line:
desktoptojson -i myplugin.desktop -o myplugin.json
The title tells it all:
Does breezy fully replace bzr, at least in msys2?
E.g., by aliasing.
I found little info on this:
https://github.com/NixOS/nixpkgs/issues/80740
Yes, Breezy is a full replacement for Bazaar. It's derived from the Bazaar codebase, and compatible with the Bazaar command-line interface.
There are a large number of changes to the internal API, but unless you use third-party plugins or use scripts that use the bzrlib API, that should not be relevant to you.
We've also dropped support for a number of older platforms (e.g. Windows '95 and '98). I don't think msys2 was ever explicitly supported as a platform, but we're happy to help fix any issues you may run into. See https://www.breezy-vcs.org/pages/support.html for ways to reach out to us.
You can read more about the rationale for the fork here:
https://lists.ubuntu.com/archives/bazaar/2017q2/076170.html
https://www.jelmer.uk/breezy-intro.html
I've been trying to set up a WiX component such that the user can specify that the installer should not upgrade that component on a MajorUpgrade. I had the following code, but this means that if the condition is met then the new version is not installed, but the old version is also removed.
<Component Id="ExampleComponent" GUID="{GUID here}">
<Condition>NOT(KEEPOLDFILE="TRUE")</Condition>
<File Id="ExampleFile" Name="File.txt" KeyPath="yes" Source="File.txt"/>
</Component>
Ideally, if the user specifies "KEEPOLDFILE=TRUE", then the existing version of "File.txt" should be kept. I've looked into using the Permanent attribute, but this doesn't look relevant.
Is this possible to achieve without using CustomActions?
A bit more background information would be useful, however:
If your major upgrade is sequenced early (e.g. afterInstallInitialize) the upgrade is an uninstall followed by a fresh install, so saving the file is a tricky proposition because you'd save it, then do the new install, then restore it.
If the upgrade is late, then file overwrite rules apply during the upgrade, therefore it won't be replaced anyway. You'd need to do something such as make the creation and modify timestamps identical so that Windows will overwrite it with the new one. The solution in this case would be to run a custom action conditioned on "keep old file", so you'd do the reverse of this:
https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/
And it's also not clear if that file is ALWAYS updated, so if in fact it has not been updated then why bother to ask the client whether to keep it?
It might be simpler to ignore the Windows Installer behavior by setting its component id to null, as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
Then you can do what you want with the file. If you've already installed it with a component guid it's too late for this solution.
There are better solutions that require the app to get involved where you install a template version of this file. The app makes a copy of it that it always uses. At upgrade time that template file is always replaced, and when the app first runs after the upgrade it asks whether to use the new file (so it copies and overwrites the one it was using) or continue to use the existing file. In my opinion delegating these issues to the install is not often an optimal solution.
Setting attributes like Permanent is typically not a good idea because they are not project attributes you can turn on and off on a whim - they apply to that component id on the system, and permanent means permanent.
I tried to make this a comment, it became to long. I prefer option 4 that Phil describes. Data files should not be meddled with by the setup, but managed by your application exe (if there is one) during its launch sequence. I don't know about others, but I feel like a broken record repeating this advice, but hear us out...
There is a description of a way to manage your data file's overwriting or preservation here. Essentially you update your exe to be "aware" of how your data file should be managed - if it should be preserved or overwritten, and you can change this behavior per version of your application exe if you like. The linked thread describes registry keys, but the concept can be used for files as well.
So essentially:
Template: Install your file per-machine as a read-only template
Launch Sequence: Copy it in place with application.exe launch sequence magic
Complex File Revision: Update the logic for file overwrite or preservation for every release as you see fit along the lines as the linked thread proposes
Your setup will "never know" about your data file, only the template file. It will leave your data file alone in all cases. Only the template file it will deal with.
Liberating your data files from the setup has many advantages:
Setup.exe bugs: No unintended accidental file overwrites or file reset problems from problematic major upgrade etc... this is a very common problem with MSI.
Setup bugs are hard to reproduce and debug since the conditions found on the target systems can generally not be replicated and debugging involves a lot of unusual technical complexity.
This is not great - it is messy - but here is a list of common MSI problems: How do I avoid common design flaws in my WiX / MSI deployment solution? - "a best effort in the interest of helping sort of thing". Let's be honest, it is a mess, but maybe it is helpful.
Application.exe Bugs: Keep in mind that you can make new bugs in your application.exe file, so you can still see errors - obviously. Bad ones too - if you are not careful - but you can easily implement a backup feature as well - one that always runs in a predictable context.
You avoid the complicated sequencing, conditioning and impersonation concerns that make custom actions and modern setups so complicated to do right and make reliable.
Following from that and other, technical and practical reasons: it is much easier to debug problems in the application launch sequence than bugs in your setup.
You can easily set up test conditions and test them interactively. In other words you can re-create problem conditions easily and test them in seconds. It could take you hours to do so with a setup.
Error messages can be interactive and meaningful and be shown to the user.
QA people are more familiar with testing application functionality than setup functionality.
And I repeat it: you are always in the same impersonation context (user context) and you have no installation sequence to worry about.
I'm writing a command-line utility in Go that (as part of its operation) needs to get a password from the user. There's a great gopass module for Unix that does this, and I know how to write one for the Windows console. The problem is that the Windows module obviously won't build on *nix, and the *nix version won't build on Windows. Since Go lacks any preprocessor support (as far as I can tell), I have absolutely no idea what the right way to approach this is. I know it's possible, since Go itself must do this for its own libraries, but the tooling I'm used to (conditional imports/preprocessors/etc.) seems to be missing.
Go has build constraints, which can either be specified as comments in a .go file, or as part of the file name.
One set of constraints is for target operating system, so you can have one file for Windows, one for e.g. Linux and implement the same function in two different ways in the two.
More information on build constraints are at http://golang.org/pkg/go/build/#hdr-Build_Constraints
Need To Set Version Information on the existing .dll
I need to add these to dll
1.File Version
2.Product Version
Tried this free version.
does not work
any Idea ?
There is a tool named verpatch that does exactly that.
After you download it you can run it from command line as below:
verpatch your.dll /pv "product.version" /va "file.version"
There are many other flags that can be used to add extra information.
Try:
verpatch /?
There is Resource Tuner Console from Heaventools Software.
Resource Tuner Console is a command-line tool that enables developers to automate editing of different resource types in large numbers of Windows 32- and 64-bit executable files.
See specifically the Changing Version Variables And Updating The Version Information page for greater details.
I've created a tool for this purpose because didn't find anything that is enough easy to use and easy to automate. Developers find it useful.
I'm sorry if that might seem as a self-ad but I know how annoying is to sync versions...