I have created a WiX project that installs a bunch of different EXEs and DLLs. Unfortunately when I build the project I receive the following warning for each one of them:
ICE60: The file fileName is not a
Font, and its version is not a
companion file reference. It should
have a language specified in the
Language column.
I have found examples and possible solutions for this and each time it is suggested to set the DefaultLanguage tag to 0 in order to fix the warning. Once doing that I then get this warning:
The DefaultLanguage '0' was used for
file 'fileName' which has no language
or version. For unversioned files,
specifying a value for DefaultLanguage
is not neccessary and it will not be
used when determining file versions.
Remove the DefaultLanguage attribute
to eliminate this warning.
How can I handle this warning?
I beileve you are stuck with the warning until the executables are updated. Not helpful, I know, but I would focus on fixing the executables rather than trying to hack the Windows Installer.
The answer is to use something besides Wix. Having an test for a condition which the developer has no means to solve anyway, is a fruitless search for perfection that just results in wasting peoples time. In the end, your installer will work fine with this warning, and the warning being there will lead to you missing some other warning because you over looked it in the stream of useless output produced by this warning.
There is no value in demanding language when there is no net use of that language to fix the users life. The executable still run, they still produce the same results and they still have no support for language. So, why would this test, with an unquenchable warning, really add value to the developer or users life?
Related
I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.
Some valid IDL files, build as IDL Projects and install but some or all of their contents do not appear in the SCA Explorer/Target SDR/IDL Repository. I believe that the IDL parser used to build the tree in the IDL Repository is different from that used by the omniORB idl2cpp (omniidl) during building and it rejects some valid IDL. The cases I have found all use a value of a const previously defined. e.g.,
const Algorithm ALG_NONE = 0
const Algorithm ALG_LPC = ALG_NONE + 3
The second line can occur in the same file or in a file that includes the file containing the first line.
The file containing the first line is accepted if the second line is not in the same file, but the file containing the second line is rejected and none of its contents appear in the IDL Repository tree. It appears that it rejects a const appearing as a value on the right side of an assignment statement. These files however are valid and are accepted as valid by omniidl. But they cannot be used in RedHawk because they cannot be selected for a component interface.
I am not very familiar with RedHawk IDE sources or Eclipse plugins and so have not been able to find where the syntax for the parser is specified. I see "eclipsecorba" appearing in plugin lists so I assume that RedHawk is using the Eclipse CORBA Plugin (aka ECP) and that its parser is the one being used to build the tree. So I suspect that the parser error is in that package rather than in code added by RedHawk.
Can anyone confirm this and suggest where I might look in the ECP code for this? Should I report this as a ECP bug to the ECP group on SourceForge? I am not sure how active it is since it appears that the latest version is from 2008.
This seems to be a bug in the IDL editor, the IDL you have is legal. Would recommend you to report this to ECP but given the long inactivity of that project probably it will not fixed soon. I do know that one of our Remedy IT engineers has created a more modern IDL editor for Eclipse but due to lack of funding this work is not available publicly.
I'm working with gendarme for .net called by Sonar (launched by Jenkins).
I've a lot of AvoidVisibleFieldsRule violations. The main violations are found in the generated files. As I can't do anything on it, i would like to exclude *.designer.cs from the scan.
I can't find a way to do that. There is a properties in Sonar to exclude generated files but it doesn't seem to be applied for gendarme.
Is there a way to do such a thing ?
Thanks for all
Gendarme expects you provide an ignore list,
http://www.mono-project.com/Gendarme.FAQ
https://github.com/mono/mono-tools/blob/master/gendarme/self-test.ignore
The ignore file format is bit of weird, but you can learn it by experiments.
Indeed that is actually not normal at all. Generated code is excluded by the plugin with the standard configuration. What version of the C# plugins are you using ?
Anyway, the configuration property you can try is "sonar.exclusions" (see http://docs.codehaus.org/display/SONAR/Advanced+parameters).
If you do not solve your problem right away, the best thing would be to drop a mail to the user mailing list (see http://www.sonarsource.org/support/support/) and send the verbose output of your build. To get this output simply add "-X" to the command line.
Hope it helps
I have installed both the GNAT Programming Studio (GPS) and GtkAda. They both seem to work fine, but when I try to build the Simple Window project under New Project from Template, I get a bunch of errors saying "file gtk.ads not found." This seems to be a directory/dependency sort of problem - GPS doesn't know where to look for GtkAda. I'm running Windows 7, and have GPS installed at C:\GNAT\2011, and GtkAda installed at C:\GtkAda. I tried adding GtkAda to my PATH; at the moment my PATH user variable includes C:\GNAT\2011\bin, and my Path System variable includes C:\GtkAda\bin. Any advice on resolving this problem is greatly appreciated!
There are two things here.
First, "project" is key. Whenever you're building something that depends
on a library like GtkAda, it's much much easier if (a) you use GNAT
Project to manage it, and (b) you use the GPR(s) provided by the library
- always assuming it does, of course.
In the case of GtkAda, that means that your GPR needs to "with" GtkAda;
with "gtkada";
project Tinkering is
...
Second, gnatmake or gprbuild needs to be able to find gtkada.gpr.
The easiest way is to install GtkAda in such a way that gtkada.gpr is in
the default place that gnatmake/gprbuild expect to find GPR files. This
is $prefix/lib/gnat. GtkAda obeys this convention, so you could install
GtkAda under the same root as your compiler. I don't know why that's not recommended anyway.
If you don't want to do that, you can add the correct location to the
environment variable ADA_PROJECT_PATH, for example in your case set it
to C:\GtkAda\lib\gnat.
There is a lot of good stuff in the GtkAda README at libre.adacore.com, and in
the GtkAda User's Guide which I see from the README is also included with the
installed package at (in your case) C:\GtkAda\doc\GtkAda\gtkada_ug.
I want to remove AssemblyInfo.cpp, because of some metadata errors that sometimes come up.
Is AssemblyInfo.cpp useful for anything? Or can it be removed without any problem?
I've discovered one distinction for this file: it has to do with values reported under calls to Assembly.GetReferencedAssemblies. I was working on tracking version numbers of our binaries from our SVN repository by embedding the revision numbers into them. Initially I too was updating AssemblyInfo.cpp and found nothing reported in the file property details tab for the binary. It seemed this file did nothing for me in terms of updating those details, which was not the case with similar updates to a csproj's AssemblyInfo.cs. Why the difference right?
Now in one such csproj we happen to reference a vcxproj and that csproj dumps to a log the versions of all its referenced assemblies using the .NET Assembly.GetReferencedAssemblies method. What I discovered was that the number that was being reported in that log was not the vcxproj's version as given by the VS_VERSIONINFO resource I added (which does get the version details into the file properties details tab). Instead the number reported was actually matching that defined in the AssemblyInfo.cpp.
So for vcxproj files it looks like VS_VERSIONINFO is capable of updating the contents you find under the file properties details tab but AssemblyInfo.cpp is capable of exposing the version to GetReferencedAssemblies. In C# these two areas of reporting seem to be unified. Maybe there's a way to direct AssemblyInfo.cpp to propagate into the file details in some fashion, but what I'm going to wind up doing is duplicating the build info to both locations in a prebuild step. Maybe someone can find a better approach.
So far I never had the AssemblyInfo.cpp in my managed c++ dlls, so I don't think it is necessary.
(I just added the file to have version information for my c++ dlls).
Why not just fix the errors? On that note, what errors are you getting?
This file provides information such as a version number which is definitely needed in order to use the assembly you have built.