I am not sure whether this has been brought up before or not.
I use a lot of resource files in my projects to store things like strings etc. Whenever I change the contents of a resource file and rebuild the application the changes are not picked up by VS.NET. I
HAVE TO make a change in the source (even if it is just inserting a blank line) - to make VS.NET realize that something has changed in the project and only then VS.NET picks up the changes in the resource files.
Is it a bug? Feature? Any plans of improving resource file handling in Whidbey?
In my opinion a header file with constant strings stored is a more effective way of handling this. Using a resource file causes your program to jump to the string and then jump back to continue executing, constant strings don't. And they are just as easy
to modify in your source.
Thats good for C++, but not good for C# or VB.NET. Localization is also more difficult with header files.
I do a "Rebuild Solution" (Alt-B, R) in C#. That will pick up resource file changes. I have a similar problem with .js files.
I guess you have not tried rebuilding a solution with over 30 projects...
Oops, yea, sorry, I was going to mention that there was only 5 projects, most very small. Sorry!
+1 for rebuilding. I hate having to do that... or worse forgetting to do it and wondering why things aren't changing! :\ Haven't checked to see if it was fixed in Whidbey yet though.
And Manip, you can't use contants when you're trying to localize an application, which is what I assume manuj is trying to do. Otherwise you're right, you add overhead to your app and a lot of headaches into your build process.
What is the disadvantage of using them.. I mean:
const string hello = "Hello";
and someone who can read/write both English + their native lang comes in and changes it to
const string hello = "Bonjour";
It will require a re-build.. Did I miss something? Forgive my ignorance!
Yeah, you missed that the application needs to be recompiled per language. You also missed that people that do the translation aren't coders. Resource files enable you to run the same compiled binary for every region that you ever create resources for.
Have a look at this section of the SDK for more on the subject of localization.
I guess you have not tried rebuilding a solution with over 30 projects..
Who said you have to rebuild the solution? You right click the project(s) that contain the resources you modified and rebuild those individually. This could still result in rebuilding any dependencies, but it's bound to be less than 30 projects (at least...
I hope it is). Alternative to right clicking would be to bind a keyboard claw to the Build.RebuildOnlyProject action.
I hear what your saying.. but I would just give out a basic guide to translations or failing that a list of strings and get them to submit them back as the new lang and I'll import them. I just can't stand the idea of it breaking execution... going to
the resource file... getting the string... and returning it before it can continue execution.
I mean the common man can't edit resource files anyway.. only a coder can do that, and if you can code well enough to access a resource editor you can do the same and get in a header called Language or something creative like that.. but more than likely you
could just generate new langs using web-site translation services and then wait for any bug reports about mistakes those translation apps made. It is dirty but would be effective in rolling out your application in multiple languages very quickly.
The thing that scares me about other langs in right to left text, I mean that is not going to be fun to add in any application and have never tried it.
I like the idea of our using the web-site translation idea for the next windows release in a new region- can you imagine the slashdot posts on that
Seriously though, the issues in internationalization are really complicated and subtle for large applications targetting many regions. Windows is kind of an extreme case and it took us a while to get the process working smoothly ( and it's surprisingly efficient
Certainly resource files are part of the picture.... here we tend to use textual resource files that can be handed off to localization people to translate. These are then integrated into the binaries through the build process etc.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.