My program deploys with a configuration option that I've chosen to expose as a feature. This option can be one of two values.
Each configuration changes a set of settings files. They have different input file names (for the sake of example, let's call it option1-config20-lv80.xml), but should be installed to the configuration directory as config20-lv80.xml. Each option has a prefix that should be stripped like that, which also means only one of these options can be selected for install at a time. However, even with conditions preventing the install of one feature when the other is selected, my output is littered with:
LGHT0204: ICE30: The target file 'config20-lv80.xml' is installed in 'path' by to different components... This breaks component reference counting.
How can I give my users the option to choose between these configuration options and get around my ICE30 issues without any negative side effects?
I saw an similar question answered, but I'm not 100% sure how to implement it in wix#, or if there are other ways open to me to achieve my goal without disabling ICE30 validation or creating 2 installers.
A bit rushed, have a look...
Milk & Honey Winnie: In cases like this I prefer to install both files with different names using two different components and then switch between them with an option shown in the application itself. On launch or in the preferences. Makes deployment simpler, it is already complex (section "The Complexity of Deployment"). The linked answer you refer to can work technically, as can more hacky approaches.
Alternatives: I have a long answer here on different ways to install settings files: Create folder and file on Current user profile, from Admin Profile ranging from eliminating the whole file and using internal defaults, to downloading settings files from the network or just relying on clouded web-service settings retrieval from a database. Not 100% match, but maybe give it a skim?
A related issue is when you have a settings file that regular users can't write to. This is a list of approaches for eliminating that condition: System.UnauthorizedAccessException while running .exe under program files.
Related
My VSCode extension creates a database of symbols and stores it along the project. I'd like to automatically exclude this file from search results (it would be even better to exclude it from file explorer).
Is there a way how can I modify "search.exclude" from my extension or can I set such a setting in my extension's package.json?
There is no API for you to contribute to search.exclude and/or files.exclude settings, so you are out of luck on this.
On the other hand, you can make your extension to update the User Settings using workspace.getConfiguration("section").update("section") API. With that, search.exclude and/or files.exclude settings could de updated to respect the symbols you want to be ignored.
But, I would suggest you to warn the users about this process, asking for their approval, before effectively updating the setting. Personally, I don't do this, and prefer that extensions that don't do this as well, but I understand sometimes this is necessary/inevitable.
Hope this helps
Is there a way to set a property value to the formatted install date/time?
I'm in the process of creating an MSI installer for an old VB6 application we still depend on (yes, I know, upgrade before it dies).
I'm trying to add a backup folder for the user data files in the install-folder (not my application design, nor my application). Unfortunately every user of this application has their own copy of the data file installed on their system (dedicated machines per user), and the installer has the default file. I would like to create a backup folder so that I can manually (if necessary) go back and retrieve previous versions of the file.
What I'm thinking is
c:\program files (x86)\app*.mdb => c:\program files (x86)\app\backups\201804091125
This will be rushed. Please tell me what is not clear.
Custom Action: In order to implement exactly what you describe, you generally need a custom action. This is always unfortunate since they are very error prone: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Alternative?: If you ask me I would install the database in a component of its own, make the file the key file and set the component to permanent and never overwrite if key path exists.
In the WiX source: for the WiX component element, set these attributes: Permanent="yes" NeverOverwrite="yes"). I am not 100% sure what will happen if you do something stupid such as setting REINSTALLMODE="amus" during installation (force overwrite all files regardless of version). It has been a while since I tested the NeverOverwrite flag. But for normal deployment done the regular way the database file should be left alone and not overwritten.
Custom Action Overview: There are properties called Time and Date that are automatically set in the installer, but the Date property will generally contain characters that are illegal in path names. It is possible to just get the properties and replace the illegal characters. However, the date separation characters are probably different based on regional settings and hence hard to predict. Your code could get messy quickly and testing would be challenging (potentially many locales to test depending on distribution scope - a truly globally capable package is challenging).
I would rather get the date and time some other way - via some programming API call where I can determine what format the data comes back in. You also need to run this custom action elevated in deferred mode to ensure it doesn't fall over with access denied (insufficient user rights for operation). This is always quite a bit of clunk to set up and get working. Maybe try the alternative approach first?
I have long considered adding a custom action to abort the install if REINSTALLMODE="amus" has been specified. I would prefer that and the alternative approach described with "never overwrite" to a custom action doing all this copying.
We have a legacy COBOL application based on OpenVMS for-which we do not have a clear idea of configuration. In this context, by "configuration" I am talking about:
Which executable files comprise the application;
Which pristine source files correspond to which executable files.
It may seem odd that 1 above is something that is not known, but over time what has happened is that executables have "come and gone" (and many still remain used). The knowledge of which executable files constitute the application as it exists today is not known since knowledge of which executables are no longer required has been lost in time. In practical terms, the team faithfully compiles all source code files and deploy the resultant executables despite the fact that there are obviously programs that are no longer used.
It goes without saying that there is no formal configuration management process and the source code is not kept in a version control system. Since the application runs on OpenVMS, the corresponding Files-11-based file system keeps older versions of files (including source files) and this has long been the excuse for not putting the application source into a version control system (despite the reasons for using a VCS extending far beyond merely having a record of previous versions).
There are a number of ways in which the configuration can be determined, of course, but I'd like to start with a first "small step", that is: determine the set of executables that comprise the application. At this point I should mention that the executable components of the application are not limited to OpenVMS images, but also DCL command files. I would like to:
Log all invocations of images that reside in a certain directory or set of directories;
Log all invocations of command files that reside in a certain directory or set of directories.
If we run this logging on our production system over an extended period of time, say two months, we can get a pretty good idea of what the application comprises. Together with user consultation, we'll be able to confirm the need for the executable files that aren't being called.
I think I have an idea of how to do 1 above, although I'm not sure of the specifics, that is, use SET/AUDIT. The second part, at this stage, I have no idea of how to do.
So, the main criterion for this effort is that as little of the existing system be affected in order to gain the above information. Due to the question mark around the configuration (and the complete lack of automated tests), changing anything is a nerve-wracking undertaking.
Using operating-system-level services like SET/AUDIT would allow one to get to know what's being run without the need to change source and/or recompile anything. So, my question is a multi-parter:
Is this the optimal way to do this on OpenVMS?
What would I need to do to restrict SET/AUDIT to only monitor images in a particular directory?
How would I log command file invocation without changing the .COM source files?
What should I expect in terms of performance degradation as a result of logging such information?
Ad 2., 3.
I would try security auditing with ACLs. From a a privileged account, something like ...
Make sure ACL auditing is enabled:
$ show audit
should show
System security audits currently enabled for:
...
ACL
...
If it doesn't, enable it with
$ set audit/audit/enable=acl
and then you may want to disable it when you are done with
$ set audit/audit/disable=acl
Set audit ACLs on all the wanted files:
$ set sec/acl=(audit=security,access=success+execute) [.app]*.com
$ set sec/acl=(audit=security,access=success+execute) [.app]*.exe
and you may want to delete the ACLs when you are done with
$ set security/acl=(audit=security,access=success+execute)/delete [.app]*.com
$ set security/acl=(audit=security,access=success+execute)/delete [.app]*.exe
You can check what ACLs are set with:
$ show security [.app]*.*
Run you application ...
Get the results from the audit file
$ analyze/audit [vms$common.sysmgr]security.audit$journal/sel=access=execute/full/since=17:00/out=app.log
Check your report for your files:
$ pipe type app.log |search sys$pipe "File name", ,"Access requested"
File name: _EMUVAX$DUA0:[USER.APP]NOW.COM;1
Access requested: READ,EXECUTE
Auditable event: Object access
File name: _EMUVAX$DUA0:[USER.APP]ECHO.EXE;1
Access requested: READ,EXECUTE
$
Sorry, I have no answer for 1. and 4.
It would help to know the OpenVMS Version (e.g. 6.2, 7.3-2, 8.4...) and the architecture (Vax, Alpha,Itanium).
Recent OpenVMS versions have great sda extensions
http://h71000.www7.hp.com/doc/84final/6549/6549pro_ext1.html
or
http://de.openvms.org/Spring2009/05-SDA_EXTENSIONS.pdf
such as LNM to check the logical names used by a process, PCS for PC sampling of a process, FLT to check the faulting behavior of applications, RMS for RMS data structures, PERF only for Itanium performance tracing, PROCIO for the reads and writes for all files opened by a process
Post a
dir sys$share:*sda.exe
so that we know which Sda extensions are available for you.
You can always check what a process with a pid of 204002B4 does with
$ ana/sys
set proc/id=204020b4
sh process /channel
exam #pc
and repeat while the process moves on.
Is there a way (via shell extension or registry setting) to tell Windows Explorer that it shouldn't read files in the folder being shown in order to extract metadata or create thumbnails?
The problem is that when the user navigates to the folder, Windows Explorer attempts to read all files in the folder and extract certain metadata from them. If the medium is slow, this takes ages and causes unnecessary load on the file system. This is especially true in case of thumbnails, when the whole graphic file is read.
I am looking for ways to do this (restrict Explorer) in code, so "don't use Thumbnail mode" is not an acceptable answer :).
Upd: per-user settings won't work unfortunately cause we as a disk provider can deal only with our own disk (and the user might want to have separate settings for regular disks and virtual disks). I believe there must be some way to "explain" the OS that the drive is slow.
Maybe there's some IRP on driver level that we need to handle to tell the OS that the medium is slow?
Is there a way (via shell extension or
registry setting) to tell Windows
Explorer that it shouldn't read files
in the folder being shown in order to
extract metadata or create thumbnails?
Not that I know off, but depending on the priorities regarding the use case details you outlined there might be two options still to approximate the desired result:
Via group policy
Note that this essential expands/details the network folder related aspect of Freds answer, which you dismissed in your update; however, you claim to be able to deploy shell extensions or registry settings and the following two group policies simply execute the latter by administrative means:
User Configuration -> Administrative Templates -> Windows Components -> Windows Explorer:
Turn off the display of thumbnails and only display icons **on network folders**
Turns off the caching of thumbnails in hidden thumbs.db files.
This boils down to the following registry settings:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
"DisableThumbnailsOnNetworkFolders"=dword:00000001
"DisableThumbsDBOnNetworkFolders"=dword:00000001
Of course this is still not per folder, but at least limited to network folders and ignores regular disks and virtual disks.
Via hackish workaround
Given your statement we as disk provider can deal only with our own disk there might be a hackish workaround, though I'm afraid it lacks the last mile (untested by myself).
Starting from Chris W. Reas own answer to How can I suppress those annoying Thumbs.db files in Windows Vista and Windows 7?:
Also worth knowing: In Vista and Windows 7, Thumbs.db applies to network folders only. For local folders, Vista and Windows 7 instead save thumbnail cache information to a database in a local folder at "%userprofile%\AppData\Local\Microsoft\Windows\Explorer"
Continuing from there, Wil claims the following potentially clever solution to work on a per folder basis:
Go to the drive and create a file called thumbs.db (in notepad or anything), then change the permissions on the file for everyone (including SYSTEM) to deny all.
Unfortunately, aside from the automation requirements to create the dummy thumbs.db in each folder, the outcome depends on how Explorer will react on the inaccessible file - because caching is optional as per group policy, it might as well display thumbnails without caching them, making the bandwidth issue even worse in turn ...
Good luck!
I'm not sure if you can disable thumbnail generation/display for certain folders but this article talks about a script which could quickly disable it via context menu.
The script modifies a value in the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\. I suppose you could find something similar in that key for the other metadata. ShowInfoTip sounds promising. There might be relevant information in other nearby keys.
This may be a complete non-answer depending on your needs, but how about storing the files without file extensions that the OS wants to make thumbnails of? Call it file.jpg.abc and it won't be reading thumbnails, for sure.
We have four regions (dev, test, qa, prod) that all require environment specific config files. I am trying to develop a WIX install that will accept a property assignment from the msiexec command line and dynamically set the file source of a config file. I've tried just about everything and read about every page and I can't seem to make it work. This seems like a trivial probleml.
While there are probably ways to pull off what you ask, the traditional approach would be to include all four files, with their respective components conditioned such that your command line property selects exactly one of them to be installed.