I'm busy with a cross-platform mobile app using the Xamarin mono libraries and I ran into the following situation...
I've got a bunch of string resources in my monodroid project (strings.xml) that are being used by my layouts and my C# code.
What I would like to to is to move these string resources to a file in a shared project so that both iOS, Android and Windows phone will be able to use them.
What is the best way to achieve this?
*Currently i'm using a Resource.resx file that contains the non-UI strings. And then I have the strings.xml file in the android(monodroid) project to cater for the UI resource strings.
Keep the following in mind:
The same file must be used by all the platforms.
I need the android layouts to also use the same resources. (which currently is the strings.xml file)
It should preferably be one file.
Any opinions?
There are (at least) a couple of 'standard' libraries/tools you could look at:
Rdio's Vernacular tool looks to help with this problem using a GetText layer - https://github.com/rdio/vernacular
MvvmCross uses JSON files to share text (see Localising text in MvvmCross ViewModels)
Both of those are open source - you should be able to make your own design-time or run-time tools out from those.
Another option would be to use a generator to generate the appropriate resources at build time. For simplicity, I decided to create a Resource Migrator that I run with every build.
Essentially, I take everything in my PCL's *.resx files, and generate Android or iOS resources before building the app. This is a similar approach to combining/minifying CSS/JS in a web application during build time... it reduces performance overhead at runtime.
Related
I'm maintaining one program written in C# 2.0 (VS2005). It has pretty large codebase, lot of authors, it is almost internal app, but currently it is also one of our customers using it.
App is multilingual and translation of own forms and components works OK. But, there is one component - DockPanel Suite by WeifenLuo and I need to translate it to another language (zh-CN) - one of the chinese guys translated resource file to his language and now I'm trying to include and use in application, but I'm failing in it - although whole app is in chinese, this component remains in english. The untranslated resource file can be found on github: https://github.com/dockpanelsuite/dockpanelsuite/blob/master/WinFormsUI/Docking/Strings.resx
How to do that? I tried almost everything, naive approach (just resgen and compile by al, and trying to use it as satellite assembly - also tried ilmerge), then opening DockPanelSuite in VS2013 Express, adding resx as Strings.zh-CN.resx, but nothing works and tooltips and others are still in english.
Tried also stepping-in with debugger, but debugger broke at tooltip = Strings.DockPaneCaption_ToolTipAutoHide but it didn't step into getter defined in Strings.Designer.cs
I'm stuck and I don't know, how to do that. Any idea? Thanks very much!
I was able to translate a label in the demo application in a very simple process:
git clone the library
Copy & paste the Strings.resx file
Rename the copy into Strings.pt-BR.resx
Compile, it's done (in my case, I translated the "Close" label)
however, this project contains many Strings.resx files
Did you change all of them? Or did you just change one? (maybe a wrong one, like I did in my first try)
I'm working on an installation and configuration application in C# for a project I'm working on, and I'm wondering what the best method of internally organising everything is.
Requirements:
Single executable for deployment, no other files bundled with it.
Has to support custom config steps on each panel, which contribute to a generated XML config file at the end.
Certain steps may be skipped based on certain choices made within the installer flow.
Must support dynamic config screens based on information fed back from classes in one of my libraries.
Here's a description of my prototype:
A large form with a bunch of Panel controls, each representing one "screen" of the wizard. Each is named appropriately.
A class for each "screen", deriving from a base type I defined. I call specific methods of it (e.g. Enter, Back, Forward) when certain events occur.
State is stored as a Dictionary<string,object>, which is passed to each screen. The final screen (the actual "Installing..." screen) reads config out of this and dumps it into the XML file.
Each screen's code is responsible for handling the "Next" and "Prev" buttons, so I can control where it jumps to based on settings in the current screen.
A number of modules are stored in my library which provide information about extra config steps that need to be taken. I'm implementing this through reflection and automated UI generation.
Assets are stored in the resources of the executable.
I don't want to use a generic installer package (e.g. InstallShield) because the logic is totally custom and calls upon one of my class libraries. What I would like to know is - am I setting this out in a really circuitous way? Is there a simpler or more standard way to wizard-style applications?
Here's the short answer:
A commercial tool is perfect for what you need because it supports both custom installation UI and dynamic XML files. Anything else requires a lot of learning and hard work.
And the long explanation:
A custom installation UI is not an easy task. Windows Installer offers built-in dialogs and controls, so it's usually the best solution. You could also try a proprietary installation engine, but you will need to learn it.
You're also taking an incorrect approach by trying to control everything with custom code and classes. Most setup authoring tools offer direct support for handling the installation UI and XML files. Why try reinventing the wheel?
So you basically need to find the setup authoring tool which is best for you. Here is a general list:
http://en.wikipedia.org/wiki/List_of_installation_software
The tools are either MSI-based or proprietary. Personally I prefer Windows Installer (MSI packages).
Trying to implement all your tasks with custom code is just not worth it.
The only proper way to install software on Windows (which I assume is your target platform) is using Windows Installer. Simplifying a bit Windows Installer is based on the concept of a installation package (a database file) that in a transactional way can be added or removed from the system.
If you write your own installation logic you will not be able to participate in the transactional handling of software installation. If your uninstaller gets deleted there is no way the user can uninstall your software. Also, Windows Installer knows A LOT about the quirks of Windows which you may not be aware of.
Windows Installer provides a somewhat cryptic API for creating packages but you can also use then open source WiX toolset which is quite powerful or any commercial installer like InstallShield.
If you decide to go the Windows Installer way you should try to avoid custom actions if possible. Custom actions suffer from the same "transaction rollback" problem as a custom installer. You create the code for the custom action rollback/uninstall say in a DLL and if that DLL is lost there is no way Windows Installer can undo your custom action.
Windows Installer is actually quite powerful. You havn't given any specific information about the "custom stuff" you need to do but perhaps Windows Installer already has a table for that?
Use InstallShield or the MSI installer. Seriously. In addition to being able to support all kinds of custom logic (including code you specify), the generic installer wizards do things you're not even thinking about, like, say, listing the installed app in Programs and Features, and performing repair installs/uninstalls.
With the level of custom logic you're looking at, I would fork out for the latest InstallShield installer builder; the VS Install project builds into a pretty simple dialog set.
EDIT: Fair enough, been in that position before.
I would still HIGHLY recommend using any generic installer tools you have available, like VS's Install project, for the reasons I stated above; the install packages do things you aren't even thinking about in your design, and you get all of it for free.
Instead of putting this logic to customize your XML config file in the installer, how about putting it in your executable, as a "run-once" configuration wizard that the user will see when they start the application after installing it? It shouldn't be too off-putting to your users, and it should work well if the actual application is also a WinForms app (even if it isn't; you could compile the configurator into a different app and have your main app launch the configurator if it doesn't have an XML file).
Single executable for deployment, no other files bundled with it.
This might of some interest to you : http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
I have a windows form application. It has textboxs, checkboxs, labels and devxpress xtragrids etc. I need to apply localization to my application. I searched the net and came over some solutions about .resx . But its taking time to apply this method and if i need more languages in the future i need to create a new resx than customize that resx for that form.
Is there any other way to create a xml file so that i or translator change only the xml files.
Regards.
Resx files are in XML to begin with. You don't need to "add more resx" when you add language, at least you do not have to add them to your solution/project. What you need is to apply proper build process (I suspect that you build your application directly from Visual Studio, which is not very good idea) - you could use MSBuild to do that. In that case, all you need to do is to place translated files in their right paths and start building.
There are also other localization methods for Winforms applications - for example you might want to try WinRes.
I have a win forms application written in C# which has a resource file, after this application has been built I want to alter the contents of the resource file, how would I go about doing this?
I've realised that I was doing this the wrong way around, instead of building an application and then attempting to modify the resources of that application on the fly I am not creating and building an application (including resources) on the fly and this seems to work perfectly for my purposes.
I am working on a windows application that will need to be branded. The client will be selling this to other businesses, and needs a customized logo and name for each sale.
The client does not know how to use visual studio!
I think I need to write a packager app to inject custom logo and string resources into the executable. I am planning on using WPF. But since this is a critical requirement, I'd be willing to do it in winforms if that is easier.
What is the best way to do this? Any and all suggestions welcome.
It sounds like what you are after is application skinning. This doesn't mean you have to unpack the exe and inject resources. You just need to consider skinning from the start of the project and build the application to support your skinning requirements.
WPF will make skinning your app much easier. There will be several different ways to accomplish what you want.
Simplest is to leave the logo image loose and reference it with a relative path from the XAML file(s) that need to show this image.
You should look into Resource Dictionaries in WPF and how they help you group resources and support skinning. http://msdn.microsoft.com/en-us/library/ms750613.aspx
The text will be a little different but I am not sure what you need as far as a text goes. Do you mean you need to localize the strings or do you simply need different text (all the same locale) to show for different clients?
One possible solution (perhaps not the simplest one) is to use a parent application which compiles source code for generating child application. You can do it with CSharpCodeProvider and CompilerParameters classes. Add the image as an embedded resource and retrieve it in the child application. A working demo with a source code is available at Slide Show Builder.
My best suggestion for the exact question you asked (although I suspect there is another way by reconsidering the exact requirements) would be to write a utility which uses ildasm to disassemble the assembly, then use ilasm to reassemble it and include your new resource file.
http://msdn.microsoft.com/en-us/library/496e4ekx%28VS.71%29.aspx
The trivial solution is to provide the bitmap along with the EXE as a separate file. Actually replacing an embedded resource in the EXE requires decompiling it with ildasm.exe and putting it back together with ilasm.exe. Ildasm.exe is only available in the Windows SDK, it can be downloaded separately. Error prone and small odds that your customer can get that right, you'll need to provide them with, say, a .bat file that does this.
Of course, whomever is interested in replacing the logo, for whatever reason, would not be slowed down by replacing either the separate image file or using the Ildasm.exe trick. There is therefore very little point in making it any more complicated then it needs to be.