I have a wix booststrapper project, which cannot be localized like the normal WiX project.
If I extract the hard code string from the booststrapper.wxs file, then the compiler output errors:
Light.exe : error LGHT0100: The localization identifier xxx has been duplicated in multiple locations. Please resolve the conflict
Has anyone some experience in boostrapper internationalization?
Would you give some suggestions?
This issue is discussed here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Votive-Light-LGHT100-error-when-more-than-one-localized-wxl-td7587802.html
In short, if you include two or more .wxl files you will see this error. The trick is to mark the extra localized wxl files as Build Action = None in the Properties window for the actual wxl files in the solution project tree.
If you are using a main one (or a copy) like RtfTheme.wxl, that one can remain as type Embedded Resource. This is the default type Visual Studio seems to assign wxl files added to the project but only one can ever be marked as such. So long as you have Payload elements that bring in the rest they do not need to be marked as Embedded Resource and, as experienced, it will fail the build if they are.
Additionally, the following post describes a very nice way to organize all these localization files: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/My-experiences-making-a-multi-language-bundle-td7208949.html
Related
I wish I could provide a better description, but this is hard to describe succinctly.
Let me start with some background. This is a C++ solution using Visual Studio 2019 Community Edition. It has 12 projects of different types (DLLs, static libraries, and executable tests) and 4 build configurations ((Release, Debug)x(Win32, x64)). Keeping all the properties the same across projects and configurations has been a massive pain, so I decided to try using property sheets so that I could have the properties shared across projects. Given the structure of my solution, the property sheets are themselves somewhat complicated, but it's an improvement over what I had.
However about halfway through this migration I noticed some odd behavior. When I inspect the properties for one of my projects (a static library), the properties page is almost totally empty. Not only the properties I have changed with my sheets are missing, but even the default properties that you would expect.
However when I build this project, I can tell that most of the custom properties are in fact set correctly despite being missing, so it would seem like a UI bug, except some properties are not set correctly, for example the build log is not written to the correct location despite being set in the property sheet. This makes me worried that other more important properties may not be set correctly as well, but it's hard to know which properties are getting set and which are not.
I have another static library project that is set up in the same way with the same property sheets, and it behaves normally. It shows the expected properties in the project properties, and the build log is even in the correct location.
It gets even stranger. When I run the build from the command line using msbuild or devenv, the build log is written to the correct location. This suggests that building from the command line is working correctly, and that building from Visual Studio is not the same as building from the command line.
I ran msbuild -pp to see the expanded project file, and it looks correct. I diffed this project file with another static library from my solution that is working normally, and the diff is as expected, only the project names, paths, and source files are different. I did this diff on the expanded projects files too and they were the same except the expected differences.
I have closed and reopened Visual Studio countless times. I have also unloaded and reloaded the project. I have even tried deleting the .vs folder. None of these had any affect.
Here is a link to my code.
Screenshots demonstrating what I mean.
Is there any way to fix this? Have I done something wrong? I would like all of the properties from my property sheets to show up in the project properties, and I especially need all of them to apply when building the project.
Moving the <ItemGroup>s containing the source files below the <ImportGroup>s in my project file (.vcxproj) fixed the problem. I cannot explain why this works, or why this was ever a problem in the first place, but it fixed it.
I've got two files in my build named State.cpp. When I generate the VS project with the Introjucer and try to compile, both of those files clash to the same object file and I get the warning:
Warning 1 warning MSB8027: Two or more files with the name of
State.cpp will produce outputs to the same location. This can lead to
an incorrect build result. The files involved are
......\audio\State.cpp, ......\sg\State.cpp.
and then various link errors.
I can correct this easily enough within VS by modifying the Object File Name property on the VS project. However, when I regenerate the project with the Introjucer, that setting gets blown away.
Is there a setting I can use in the Inrojucer's config pages to prevent the clashes?
Just to close this one down...
There isn't. Rename the file for now.
We discussed this on the forum. I think Jules is up for making a change to the Introjucer to fix this - but it hasn't been done yet.
http://www.juce.com/forum/topic/msvc-build-consistency
http://www.juce.com/forum/topic/introjucer/visual-studio-2013-object-file-clashes
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.
I'm working on a project and we have a huge assembly if hundreds of types. I would like to add some kind of code analysis, but only on new types.
In FxCop I can chose the types and/or namespaces I want to have analyzed.
I can't seem to find a way to do so in VS2010 code analysis. Is it just me or is this not possible?
Yes, it's possible in VS2010, but there's no UI for creating the subset. Instead, you'll either need to either specify the inclusion/exclusion list via the CodeAnalysisAdditionalOptions MSBuild property (using the /types command line parameter that will be used when running FxCopCmd.exe) or via a .fxcop project file specified via the CodeAnalysisProject MSBuild property.
The latter approach caused problems in VS2008 since FxCop would attempt to load the target DLL twice if it was included in the project file. I haven't tried it in VS2010, but it's certainly worth giving it a shot before resorting to the CodeAnalysisAdditionalOptions approach.
N.B.: This is exactly the same answer already provided at http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/fd431e4d-401d-4b5b-b07d-144198e0dc30.
In VS, it is possible to set a custom build rule at the individual file level. However, unless you change the description of the build step (which is what msbuild outputs when running the external tool), all you get is the default, which says "Performing Custom Build Step," followed by the error output of the tool.
I recently got burned by this in an inherited solution, where the build rule for a .asm file buried deep in a project was failing, and NASM didn't provide any useful debug information. Since I didn't know what file was failing, it took me forever to find the problem. One thing I tried was changing the description for all the projects in the solution (by selecting them all at once and opening the properties panel) and adding macros to show the project and file affected. Since the build rule was attached to a file, however, this naturally didn't work.
I also tried searching for the default description string in all the project files, but the project files don't store this information unless you set the value. So clearly, there's got to be a default somewhere. Anyone know how you can set this?
I doubt you can change the default for everything, but what you can do is create a property sheet in which you set a custom description, and than add that property sheet to all projects needing it.