I have recently added the Multilingual App Toolkit to our projects. There are several assemblies which are dlls and exes which have resx files and one dll that is for global resources.
Each assembly has a Locales and MultilingualResources directories. Locales stores Resources.resx and Resources.XXX.resx files while the MultilingualResources stores the xlf files. Generate machine translations works and populates the xlf files.
However I have only been able to get the Resources.XXX.resx files of our global resources to be populated. I have tried doing complete rebuilds and manually setting state of all resource strings to translated, but the other assembly Resources.XXX.resx files do not get populated.
How can I force Multilingual App Toolkit to populate the Resources.XXX.resx files. Also does populating the other Resources.XXX.resx files depend on the state of a translation in xlf files?
We are using version 4.0.1605.0.
We encountered this error with one project not updating the Resources.XXX.resx files with new or updated translations from the .xlf file.
It turned out the issue was that project renames don't completely propagate through the .xlf files. When we renamed the project from OldName to NewName, the group id in the .xlf files was correctly changed to "NEWNAME/LOCALES/RESOURCES.RESX". The the original element in the header was not changed and was still "OLDNAME/LOCALES/RESOURCES.RESX"
We used a text editor to manually change value for "original" to the new project name for every .xlf file and the problem was solved.
Related
I have a workspace with multiple projects that I would like to add source control too. All of the projects share some files which have been added as a folder reference. Testing this with source control these shared files aren't recognised fully or added to commits etc.
Is there a way to include these files? or should there be multiple copies of the same file to enable source control? All the projects have different UI's and set ups.
To add this is when a file is not copied to destination when adding so is outside of the projects file structure
I have 4 files in my Xamarin.Forms project that reside in a folder named MiscFiles. The build action for each is set to Content and Copy to Output is set to CopyAlways. The first 2 files are database files that have a ".db" extension. The other 2 files are resource files named StaticResources.Resources.resources and TestClient.Resources.resources.
The files are being used by a .Net Standard library which is referenced by the Xamarin.Forms project and also a separate WinForms project. The Xamarin.Forms projects just need to deploy the files with the app and pass the file path to the Standard Library.
I was expecting that when the projects are built that all 4 files would be copied to the Environment.SpecialFolder.LocalApplicationData path which on iOS resolves to:
/Users/me/Library/Developer/CoreSimulator/Devices/A1415D63-CE56-4AA2-B8FB-B89B498E70AE/data/Containers/Data/Application/0682337D-1832-4640-8A90-2DFC525901DD/Documents/
The db files are always present in the Documents folder but the resources files never show up. Are the resource files just not being copied or are they being copied to a different folder? Does Xamarin treat the resources files differently somehow?
Whenever I am adding some files to my project by dragging and dropping in Xcode, a popup message is shown "Copy items into destination's group folder (if needed)".
I noticed that when we are using most of the third party library's we DON'T tick the checkbox and instead specify the library path in "Header Search Path/Library search Path". But for smaller resource files like images, we tick the checkbox.
Which specific scenarios do I have to tick and what difference will it make?
It all depends on how you want to organize you project. It's far more common to store 3rd party frameworks somewhere on your machine that is independent of any project that may use that framework, thus allowing multiple projects to reference the same shared framework project from a standard directory. In that case, you don't want the 3rd party framework copied into your own project, and so you don't check that box.
Images and other resource files are typically owned on a project-by-project basis, so it makes the most sense to store those in the directory of the project itself. To pull that off, you check that box to make sure a copy is made in the project's directory if one doesn't already exist.
Neither of those rules are absolute, you could copy an entire framework into your project's directory if you want, and you could reference media assets from some standard location. It's all up to you to implement good project organization.
Typically, your project is saved to a project folder. If you drag stuff from outside the folder into your project without copying, only references to the added files are stored. You will have to be careful not to delete them, or your project will break.
Also, if you are using version control, such as the built-in git, files not in the main folder will not get added to your version tree.
I got into the habit of copying everything I need into the main folder and then drag-add without copying. This is working well for me and has so far avoided any errors.
We have different dev environments between developers here. When I build, I want my compiled files to be copied to a bin folder located in C:\Web\bin\. Another developer may want those files dropped in C:\Web_2011\bin\.
Using Visual Studio 2010, the way we work this now is to run a BAT file with the directories defined as parameters that need to be changed if pulling from another developer's branch.
Is it possible to store a solution-wide parameter, (in a .user or .suo file maybe,) to define where a developer wants to drop his builds?
You could do it through the project file (.vcxproj for C++ project for example).
The simplest solution would be to add a Custom Build Step that runs some batch file. This batch file could check the current user name and copy the files based on that.
(An even simpler solution would be to run a user specific batch file from his local disk)
If you really want the fully fledged solution that will allow you to save this data to the user file, you can do it by editing the project file and adding a PropertyPageSchema element that extends VS property pages with another parameter (your destination directory). You can define the Persistence attribute of DataSource element as "UserFile" and the data will be saved on your .user file. You will need to add some target that actually uses this data (copies files to the directory specified).
For more information, read about msbuild and PropertyPageSchema.
I have a Visual Studio 2010 project which references some third-party components. Their assemblies are accompanied by XML documentation files, which are useful for us (and only us) developers. And whenever the project is built (either in Debug or Release modes) these XML files are copied to the build directory.
I can't seem to find a setting or switch to disable the copy of those XML files to the build directory, either within Visual Studio or though MSBuild. A post-build script may be an option, but a smelly one. Any ideas? Thank you.
When you build a project the .xml/.pdb files are gathered through the ResolveAssemblyReference task. When ResolveAssemblyReference is called it is passed a list of file extensions for related files. That list of file extensions is captured in the MSBuild property AllowedReferenceRelatedFileExtensions. By default that list will contain ".pdb;.xml".
If you want to exclude all related reference files from being picked up then just override the value of the property to something which related files won't have extensions of. For example you can set AllowedReferenceRelatedFileExtensions to "-".
You can also customize the list of file which are returned by that. If you only want to find only .pdb files then you will need to pass in AllowedReferenceRelatedFileExtensions=".pdb". In that case any references which have .pdb file next to the .dll/.exe they will be copied as well. You can also use this to copy other related files which may not end in .pdb/.xml. For example if you have a referenced assembly named, MyAssembly.dll and in that same folder there exists MyAssembly.pdb and MyAssembly.foo If you set AllowedReferenceRelatedFileExtensions=".pdb;.foo" then both the .pdb and .foo file will be copied to the output directory.
Visual studio project file has the same format as any msbuild file. So you can manually add the condition into corresponding section to not copy your xml files if configuration name is 'Release'.
It should be changing
<ItemGroup>
to
<ItemGroup Condition="'$(CONFIG)'=='RELEASE'">
or something like this.
If the .xml/.pdb are marked as build-action "Content" (etc), you can change them to "None". You should also ensure they copy-to-build-output is false.
Are both of those set?
What is the problem with having the XML files get copied into the folder on release builds? It seems to me that this is fine and that the real problem is with the code that picks up files to place them in the installer. Picking up third party dlls from your own bin\release folder is not a good practice in my opinion. I'd have my installer pick up third party dlls from their own folder in my source tree.
The setting is in the Properties of the project in question, under the "Build" tab, uncheck "XML documentation file". It's also an MSBuild property called <DocumentationFile> under the applicable <PropertyGroup> for your build configuration in the .*proj file.