I have a number of localized RESX files in my project:
Messages.resx
Messages.de.resx
Messages.qps-ploc.resx
The last one being a pseudo-localized text resource for testing purposes. I would like it to be compiled to a satellite assembly (i.e. project/qps-ploc/project.resources.dll) as the rest of localizations . But for some reason AssignCulture task is assigning empty culture to this resource and it's not compiled as the result.
Snippet from MSBuild log:
Task "AssignCulture"
Culture of "de" was assigned to file "Resources\Messages.de.resx".
Culture of "" was assigned to file "Resources\Messages.resx".
Culture of "" was assigned to file "Resources\Messages.qps-ploc.resx".
Done executing task "AssignCulture".
Pseudo-localization cultures have been enabled in registry as described here
and new CultureInfo("qps-ploc") returns correct pseudo culture.
Is this an expected behavior from AssignCulture or just me using it wrong?
Not sure what happened, but suddenly everything started to work. Perhaps somehow related to system reboot.
I had the same problem and it also resolved itself after a reboot. I think it's because the AssignCulture task must check the culture used in a resource file and, if it's not a standard one or a custom culture that has an .nlp file in your Windows\Globalization folder, the assignment fails during compilation and no resource file is created.
In my case I'd just created a custom culture but I guess Visual Studio didn't know about it as it must have cached the resource files that were found at the previous system reboot. Rebooting the PC again must have updated the cached resource files (including the custom ones) and the AssignCulture task was then able to match the resource successfully and the resource file was created.
Related
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.
Installers of previous versions of our software include a Component File that was NOT marked with Permanent="Yes". Now, we wish to read the pre-upgrade contents of this file during the upgrade process, which will overwrite the file with different contents. Is there a good way to do this?
It would help if you said exactly what you were doing that would cause the file to be overwritten. Some major upgrades (is that what you're doing?) will do a complete uninstall of the product first, followed by a complete install of the newer product. If that's the situation then use a custom action sequenced before RemoveExistingProducts to back up the file somewhere so that your application can retrieve the content, or get the content you need before it's ovewritten.
If you are doing a major upgrade sequenced later (such as afterInstallExecute) or you are doing a patch then it is by no means certain that the file will be overwritten because file overwrite rules will not replace a file that has been updated since it was installed. If the application altered the file then this type of upgrade will not overwrite it:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx
Or in the case that the file is unchanged since it was installed, change the dates so it appears to be modified, as described here:
https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/
It's also not clear that Permanent=yes is what you want anyway - that would glue the file to the system forever. You may be thinking of NeverOverwrite, but it's typically not required if the app changes the files, and easier to decide at upgrade time (by changing dates) instead of committing to NeverOverwrite when it's sometimes unclear what the product may need in the future.
A comment refers to retrieving the previous version of the product during the upgrade. There are a number of ways to do this:
If you know the ProductCode of the previous version, MsiGetProductInfo (and equivalents in script etc) will return product version values or strings:
https://msdn.microsoft.com/en-us/library/aa370130(v=vs.85).aspx
Or if you'd rather not hardcode the value, MsiEnumProducts passing the UpgradeCode will return a list of installed ProductCodes. This technique is most useful if you have your own bootstrapper or UI where you want to show the user the current installed version.
In a WiX major upgrade the associated property (WIX_UPGRADE_DETECTED) is a list of the ProductCodes detected (usually a list of one) so you can use that to get the version of the product being upgraded. In a small vbscript example, something like:
set installer = CreateObject("WindowsInstaller.Installer")
and:
prodversionstring = installer.productinfo(WIX_UPGRADE_DETECTED, "VersionString")
will get you close.
Assuming this file is a configuration file such as an XML file, I find this is just a tough area of Windows Installer. You ship file version 1, the end user modifies certain attributes and then you ship file version 2 to which you want to preserve those customizations.
The problem is this is a very complex merge. It works somewhat OK if you only care about 1-2 attributes but if the answer is I need to preserve all of it then you are stuck between losing all the customizations or not getting the changes from version 2 of the file.
You could write extensive custom actions to do all this during the installer but I propose there is a better way: Have 2 files.
1 file that is owned by the installer and can always be safely overwritten and 1 file that is owned by the application that overrides are stored in. Think of it like a transformation file. The installer doesn't know about this file so it never overwrites or deletes it. (The very definition of user data from an MSI perspective.)
For example the .NET framework Web.Config schema AppSettings element has a file attribute that was designed to support this nicely.
Specifies a relative path to an external file containing custom
application configuration settings. The specified file contains the
same kind of settings that are specified in the , , and
elements and uses the same key/value pair format as those
elements. The path specified is relative to the main configuration
file. For a Windows Forms application, this would be the binary folder
(such as /bin/debug), not the location of the application
configuration file. For Web Forms applications, the path is relative
to the application root, where the web.config file is located.
Note that the runtime ignores the attribute if the specified file can
not be found.
I have a question whether what i am trying to do is doable, and if the answer is yes how to do it.
I am new to the wix and have been doing some reading on how dynamically to include a folder to an installer and eventually i were able to do a task in nant that uses heat.exe to generate wxs file and latter adding newly generated wxs file to light and candle tasks. This allowed me to add the content of a folder to the msi and subsequently have that folder and its content to be installed.
My problem starts at the point where the folder that i am adding to the msi contains files that has their names already localized (this is a requirement).
When i am adding a file to the directory structure that has its name in Russian for example which is not 1252 codepage i am getting the error:
[exec] ......Templates.wxs(65) : error LGHT0311 : A string was
provided with characters that are not available in the specified
database code page '1252'. Either change these characters to ones that
exist in the database's code page, or update the database's code page
by modifying one of the following attributes: Product/#Codepage,
Module/#Codepage, Patch/#Codepage, PatchCreation/#Codepage, or
WixLocalization/#Codepage.
I tried to set Product/#Codepage to 65001 (UTF-8) however that did not solve the problem.
Eventually what i want to do is to have an ability to add a folder and its content to installer and someone else latter add any number of files that has their names localized into that folder. This way whenever the build runs and subsequent creation of msi happens, msi would contain that folder and its content.
Thank you very much in advance.
This is what WiX.chm says about setting the code page of the MSI database:
You can set this to a valid Windows code page by integer like 1252, or
by web name like Windows-1252. UTF-7 and UTF-8 are not officially
supported because of user interface issues. Unicode is not supported.
As long as you are going to have files named in different languages, that is, File table won't fit into a single Windows code page, you have very little choice. UTF-8 is said to be not officially supported, and this leaves a place for a hope.
If you set the CodePage attribute of the Product element to UTF-8, it will build successfully. And you can install/uninstall the resulting MSI with no problem. I have played a bit with it, and didn't face with any "interface issues" mentioned in that warning above.
Furthermore, I've googled the topic a bit, and found out that InstallShield allows setting the MSI database code page to UTF-8, which is reflected in their docs (search for 'utf-8' on that page). They have more to say about the potential interface issues:
However, some scenarios result in user interface issues. For example,
if an end user specifies the /qb command-line option or uninstalls the
product from Add or Remove Programs, Windows Installer uses very small
fonts to display the user interface text in a UTF-8 database.
They also want to stay on the safe side, hence this setting is false by default (no UTF-8, just ASCII).
So, finally, what would I do in your situation?
if that's a strict requirement to the installation package, use UTF-8 as code page
test all possible scenarios (install / uninstall / repair / upgrade / etc.) on all possible combinations related to localization (English OS, non-English OS, various combinations of current culture and culture UI)
if you face with those ghost "interface issues", show those to your stakeholders, decide whether this is what you can live with and publish known issues if you do
otherwise, recycle this idea and just thank your life for an opportunity to level-up your skills in this area :)
Hope this helps.
in vb.net i am trying to save application settings but for USER but i cannot find the user.config file
when does this file get created?
i searched my entire hardrive. i also searched the entire project.
The user.config file is typically stored in their profile directory under the following structure:
Profile Directory\Company Name\App Name_Evidence Type_Evidence Hash\Version\user.config
Have you checked there?
EDIT: Taken from the article to help cover ambiguity about the path descriptions:
Profile Directory - is either the
roaming profile directory or the local
one. Settings are stored by default in
the local user.config file. To store a
setting in the roaming user.config
file, you need to mark the setting
with the
SettingsManageabilityAttribute with
SettingsManageability set to Roaming.
Company Name - is typically the string
specified by the
AssemblyCompanyAttribute (with the
caveat that the string is escaped and
truncated as necessary, and if not
specified on the assembly, we have a
fallback procedure).
App Name - is typically the string
specified by the
AssemblyProductAttribute (same caveats
as for company name).
Evidence Type and Evidence Hash -
information derived from the app
domain evidence to provide proper app
domain and assembly isolation.
Version - typically the version
specified in the
AssemblyVersionAttribute. This is
required to isolate different versions
of the app deployed side by side.
You don't need to know where it is (and it's different under XP and Vista)
All you need to do is
Settings.Default.Save();
We have a standard MSBuild project file that is used for our different deployment stages (pre-stage, stage, live, etc). Since each deployment stage is performed on a different server we introduced a server parameter called $SourceDatabaseServer and used this extensively in each of the targets inside the project file. Note: This database server name could be different from the server name on which the build is run.
To assist us with the customization of this parameter, we created a response file for each deployment stage and subsequently defined a value for this parameter in the response file, e.g. /p:SourceDatabaseServer=SRC_DB_NAME.
This worked fine, until we created a new deployment stage in which this value had to be the current computer name. So we thought by using the $(COMPUTERNAME) reserved property in the response file (/p:SourceDatabaseServer=$(COMPUTERNAME)), this would do the trick, but it seems like this value is interpreted literally by MSBuild, and we consequently get an error that server $(ComputerName) could not be found.
Interestingly, when the $(COMPUTERNAME) property is used directly in the proj file it works, but as stated above, we do not necessarily want to use the computer name in all the cases.
Is there a way to still use the $(COMPUTERNAME) property in the response file and get MSBuild to interpret this correctly?
What if you use %COMPUTERNAME%?
$(VAR) is the syntax for variable expansion when you're "inside" the MSBuild system, but coming from the outside, I believe you'd have to use the shell environment variable expansion syntax, %VAR%.