This question is about the performance
I am working on MVC4 and I want to support multi-language views.
I am using one resourse file for each language like this:
Multi.resx For English as default
Multi.ar.resx for Arabic
Multi.fr.resx for Frensh
and after specifying the culture, I do this in my views
#Multi.Name
However, I make breakpoints to check the value of #Multi and really it contains all the keys in my resources. Imagine all of them :P
My question is: would it perform better if I used a resource file for each view? Or will all the resources be loaded when I run my application even if I use multiple resource files for each view?
I am really not good at english, if you didn't understand my question, just ask me to clarify.
I know this is old thread, but I am also looking for the answer. Was single (and huge resource) file will effect the performance?.
After researching, I found this link and I thought to share with you (in case you are still looking).
Well, the short answer is NO, it will NOT affect the performance. However, it may cause problem when working in large team (where each of the programmer requires to modify the same resource file) and it can be troublesome to merge the changes.
Here is the guideline from MSDN:
Choosing Between Global and Local Resource Files
You can use any combination of global and local resource files in the Web application. Generally, you add resources to a global resource file when you want to share the resources between pages. Resources in global resource files are also strongly typed for when you want to access the files programmatically.
However, global resource files can become large, if you store all localized resources in them. Global resource files can also be more difficult to manage, if more than one developer is working on different pages but in a single resource file.
Local resource files make it easier to manage resources for a single ASP.NET Web page. But you cannot share resources between pages. Additionally, you might create lots of local resource files, if you have many pages that must be localized into many languages. If sites are large with many folders and languages, local resources can quickly expand the number of assemblies in the application domain.
When you make a change to a default resource file, either local or global, ASP.NET recompiles the resources and restarts the ASP.NET application. This can affect the overall performance of your site. If you add satellite resource files, it does not cause a recompilation of resources, but the ASP.NET application will restart.
I hope this can help someone who seeking the same answer.
Cheers,
Sam
A solution to your problem is described in this question (answer actually): Split Large Resource File into multiple files physically while compiler treat it as one
Related
From this comment:
the resource manager is intended to be used for storing resources (such as images, strings, or other data) that are embedded in your application, not for running external programs or scripts.
I understand the purpose of it is for storing, but why not allow to run scripts? Perhaps external programs are potentially large, but I suppose scripts are small enough?
It's not a question of "why is this not allowed?", it's more of a question of "why is this feature not implemented?", which is very different.
From the results from your other question you can see that it's possible to copy the contents of a embedded resource to a local file, and then call Process.Start to execute it. This works the same as the feature you are requesting, so executing an embedded resource is allowed but you have to do a bit of legwork to get it to work the way you want it to.
I don't know how MS decides what features are added to .net, but I assume this one isn't available directly from embedded resources is because of some combination of the following reasons:
It's not what embedded resources were designed for
If you need to do it, it's still possible to implement it yourself (as per your other question)
Encouraging developers to store and run executables as embedded resources sounds like it would be a security headache from a design standpoint
There's not much demand for it
They never thought about it
I'm designing a Visual Studio project that will use a potentially large number (up to ~300) of script files of various types. These files will not be shared with other projects, i.e. they are exclusive to the project. Is there any good argument against including all these files as an embedded resource (by setting their build action) and then using Assembly.GetManifestResourceStream() to retrieve them at run time? Or would this be a misuse of embedded resources, and a filesystem directory holding these resources as files should be used instead?
The benefits of using embedded resources appear to be:
the produced assembly is easy to share and deploy (single file deployment without having to worry about missing script files or invalid paths);
isolation and convenience: all the resources can be accessed from within the VS project.
The arguments against this approach are usually:
you can't modify the resources without recompilation and redeployment of the assembly. However, even for a project with many text-based resources, the resulting assembly will be rather small and just as easy to redeploy as overwriting e.g. a single filesystem-located script file would be. And theoretically, it should be possible to replace just the changed part of the assembly (hence smaller update), but I'm not aware if any such existing diff/merge tools exist.
The produced DLL will be larger, eventually perhaps significantly so; but then again, the total size of the program to deploy would be the same if you created a lean assembly without embedded resources, and deployed the resources separately to a directory.
Are there other considerations? More generally, is there a reason that project resources - regardless of what they are - should not be included as embedded resources, other than the required assembly recompilation in case of modification?
I can give you some insights from a complex environment perspective.
If your application is anywhere near critical or significant to your organisation and you need to minimize incident response time then it is of course better to have all scripts as separate files. Even though it might be very easy to recompile your assembly, in a structured corporate environment hotfix release usually requires number of hoops to jump through even in an emergency. Besides, this requires a dev person while support person should be good enough for changing a script file.
Other consideration could be if (at least some) scripts do not run properly when streamed from resources. They may need a place to write intermediate or result data. There might also be some dependencies between scripts (one calls another etc.)
One other factor is that having resources separate allows for quick review when you do not have access to project source. This adds some transparency to your application (which might be desired or not). It also might be useful to help determine what is happening with your application in case of problems and potentially make a quick change/fix (somewhat similar to my first point).
Generally I would say it depends on your requirements. If you need to be able to make frequent changes to your scripts (or other non-compilable resources) then having them separate is much better. If they don't change too often and you like to have neat, simple and compact file structure then embedding is a good choice.
If this is a web-project which you are going to use only on your own host, then it is better not to use it as embedded resources, but as usual files. (you need to install the project only once, but it will be easy to do small updates)
If you want to create a dll, which may be reusable in other projects, then it's better to use embedded resources - if you do some update, you can update just one dll in each project.
I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.
From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?
The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).
Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).
But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?
EDIT
The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.
With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.
With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).
Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.
EDIT
Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...
RESX
Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.
What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:
Have only English RESX files in the VS.NET solution.
Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
Write a simple CMD script to copy the real English resources to the separate folder.
Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.
This approach makes compilation really fast and still allows me to keep compilation and translations separated.
The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).
Database
I also did some projects with localization in database and custom <%#...%> blocks to load the languages.
Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.
3rd Party Tools
You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.
Just my two cent...
in some projects (web application projects) I'm using global resource files. (Stored in the App_GlobalResources folder)
pro:
Really easy to use: e.g. in the markup
Property="<%$ Resources:FILENAME, KEY %>"
con:
- As far as I know, I can't change the content of the resources on the fly. So if a customer is calling and tells me to change a string in the french implementation, I need to deploy a new binary. While using SessionMode="InProc" that might lead to undesired behaviour, like session loss etc.
I'd rather change a line in an XML file, to ensure maximum uptime of the application. I think It would be possible to write one's own localization class, that implements an XML file as underlying datasource (using caching etc.). So the question is, is there any upside in doing so?
Can anybody tell me more pros or cons for using global resource files? (And I'm still listening to suggestions to change resource files in a running web application ;) )
So what benefits do I have by using global resources?
Edit: I'd like to stick to "build-in" solutions in Visual Studio or the .net framework, rather than using a (unknown) 3rd party library.
It's provider model, so you can change the data source. For instance, you can store the resource on the database which is better for data driven applications. Because, you can edit, cache, install and update them simply. Visit here.
Global resources allow to localize your web application. You can have global resource per language you need to support and you will not have to duplicate aspx files. It will also allow users to switch to the language they wish at runtime.
See here:
Walkthrough: Using Resources for Localization with ASP.NET
ASP.NET Web Page Resources Overview
I would like to know how to implement CRUD operations on common files and folders.
My web site requires load balancing. The web site nodes need to CRUD files and folders in a common network location.
Note: At the moment, I am dealing with file changes by locking the file in exclusive mode when writing and shared read when reading, if there are better alternatives (A separate lock file is a no-go as there are far too many files) I would like to know. Folders still work in progress
This link has a solution for a file-lock implemented using a separate file that allows for recovery from bad situations (like one server never releasing the lock)
http://mvolo.com/blogs/serverside...
Be sure to read the comments as the non-UTC implementation provided isn't ideal.