I've created a small helpers framework and I want it to be multi-languages. So I used the .resx files for translation.
But, I'm afraid the satellites dll's will be a real mess when my framework is used into an application that has its own .resx...
So I'd like to know the best practices to avoid what seems to be a resource hell
The best practice is to follow Microsoft guidelines. Therefore *.resx files, or more precisely Satellite Assemblies is exactly what you should be using.
The problem with this approach, however is how you handle dependencies. From what I understand, you don't want to pollute the disk with additional libraries. So, you would like your clients to install just the needed files and nothing else.
The good news is, you can do that and you can still use Satellite Assemblies. All you have to do, is to pack the assembly into your DLL and override Assembly Resolution event, so that it will use internal file rather than searching for it on disk. However, with all the pros are also the cons. When you do that, your clients will have to install one file (rather large one), but they will be forced to choose from languages you provided. They won't be able to cut anything out, nor add additional language in the future.
I hope now you understand why Satellite Assembly approach is the best solution - it gives you the control over Localization process. There is no better way of handling this, sorry.
BTW. The DLL hell was related to the multiple versions of the same library needed by different clients. It won't happen in your case. Of course additional files means additional installer entries, but there is a reason why people created the concept of Merge Modules. I wouldn't worry so much for it, I would just provide framework as a merge module and let people customize it themselves, if they really have to do that.
Related
I'm working on a sub-application for a large system.
There is a company X which has created the system. Sub-applications are created by numerous smaller companies, including the one I work for.
Our application is close to being finished but there is a new requirement that our application must not use DLL files and all the business logic should be contained in .cs files.
Why is there such a requirement? Company X believes it can solve the problem of having too many DLLs and dependency issues. With many sub-applications and many different companies creating them, problems arose with /bin directory and dependency issues.
Main problem is that many sub-applications are interlinked. Service Oriented Architecture is used.
I understand this is an architecture problem. And requirement also came way too late.
I'm a developer.
More specifically about my problem:
It's simple when it comes to ascx.cs files, I can just switch from CodeBehind to CodeFile. No problem here.
Problem is with our libraries. Obviously, I can just copy all the corresponding .cs files on the server but how do I make the application load the classes from there instead of using DLL libraries?
I have never implemented an asp.net website without using DLLs, it is not clear to me what are my options.
I have been reading about:
How to load a class from a .cs file
I hope I've explained my situation well enough.
Company X no doubt has someone leading the developers who once had a dependency issue. They have now decided that any and all dependencies that are in the form of an actual assembly are bad (I think we've all had a manager like this at some point).
The fact is: this isn't possible. It is a stupid requirement that makes your life much, much more difficult.
You have two options that I can see.
1) Remove all of your (hopefully) nicely decoupled assemblies with their nice business logic out into your code behind files. This is tragic.. but an option.
2) Continue down your path of investigating compiling code from a source file. This sets you up for a HUGE amount of extra development time and.. honestly, you'll probably just end up giving up.
Save yourself some hassle and just offer them your full source code on USB.
Sorry if that sounds harsh. I do not envy you though.
Offer to license your source code to them but at much higher price than the binaries. Source code has much more intrinsic value, because it is your intellectual property.
Also beware that company X can decompile your binaries into source code using e.g., ILSpy. How much do you trust them not to do this?
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...
I've gotten to the point where I have made a few classes that I have found to be rather useful for a variety of different projects, they're either extensions of the already existing .Net ones or something entirely new.
Although I may not use them for EVERY project I would most certainly use them again at some point, my questions is what is the best way to keep these stored?
I was thinking about compiling them into a .dll that I can simply reference if necessary but at the moment there are only about 4 different classes, I've always thought that a .dll is more suited towards a larger amount of classes.
Would it just be simpler to store them somewhere in the cloud so I can access them from pretty much any computer?
What has worked best for you?
Edit: I'll be using more than one computer as I sometimes use the university computer facilities.
The classes range from memory management helper classes in XNA to niche functions in regular .Net/C#
If the classes don't fit together naturally as an assembly, keep the source files somewhere like Github and include them in your projects where needed. You can always rearrange them into components at a later date, when you feel it's worthwhile.
Are these classes in any way related? If you want to use one of them, do you need the others? If not, then those don't belong in a common package together.
Robert C. Martin provides some decent introduction in the chapter "Principles of Package and Component Design" of his book "Agile Software Development". There is also a C# adapted version with very similar content called "Agile Principles, Patterns and Practices in C#".
What I'm just saying is, packaging components is not only about thinking components X and Y are "cool enough" to be reused, but also about how you organize things and how well libraries or packages fit into the big picture.
You could compile them as a DLL and install them to the GAC. Then you can reference the DLLs from any project you need, just like any native C# library.
And I agree with Jim Brissom. Compile only the classes that go together as one assembly.
I keep my common classes in sourcegear and then share them into any projects as required.
I'm working on converting some exiting code to take advantage of the Internationalisation tools in VS.Net 2005. I've been asked to do this without creating any additional dlls if at all possible. I've tried a few different things and searched around, but I'm not sure if this can be done, so I thought I'd ask you guys.
Any ideas?
Thanks!
I think that if you want to take advantage of the i18n tools in VS.NET then you will have to use multiple assemblies (one for each culture). However, you may be able to merge these assemblies using ILMerge for deployment.
I don't know if this will work, but at least it may give you another path to research.
It is possible to package all your internationalization resources in your main assembly, but this may have repurcussions for your versioning strategy. You can point the ResourceManager constructor at any assembly, including the currently executing one.
Background: At my company we are developing a bunch applications that are using the same core dll's. These dll's are using Spring.net's IoC-container to wire things up (auto-wiring). All applications are using the same spring configuration file, and this configuration file points to many classes in many different dll's. But not all application needs functionality from every dll. But because of the way IoC-containers works, all dll's is loaded for Spring.net to examine the types and check what interfaces they implement and so on.
Core question: I understand that it's better to just load the dll's you really use. But is it really bad for memory usage just to load a managed dll? Or is it first then you are using classes in the dll and they are getting JIT'ed that the most memory are used?
If none of the code from the assembly is ever used, then eventually the pages from that assembly will be moved from memory into the page file in favour of actively used pages. In which case, the overall long-term effect is likely to be minor. Although, there will be a negative effect on startup time.
I don't think it's so bad. Only problem is that because of large metadata and amount of memory your application takes it's more possible that some parts of application which are in use will be located at different memory pages which can 'cause some performance leaks, but it's very low segment of application where this type of things are critical.
Really bad is a difficult term to quantify, I guess depends on the scale of things, in general I'd say that if you can avoid loading stuff you don't need then you should. But of course if you are using reflection to determine if you can use it, you first have to load it...chicken and the egg problem.
Something to be aware of though, once you load an assembly into an Application Domain you can't then unload it from that App domain, it is possible however to dynamically create app domains load assemblies into it and unload the whole app domain when you are done.
of course loading dll's w/o using them causes slower startup time due to reading the assembly from disk and evidence/security checks. But if memory is your concern you at least can be sure, you won't waste more memory than the size of your assemblies if you really don't use any types within. Of course if those types are specified in the spring configuration, at least those types get loaded into memory and their static initializer (if any) will be executed. In rare cases this might be an issue. JITing is done on by the CLR on a per-method basis, so methods you do not use won't waste cpu+memory.
In any case you may split your configuration files into partitions e.g. by putting all object definitions of module A into file moduleA.config, all definitions of module B into file moduleB.config and specify only those modules for your particular application that are really needed.
hth,
Erich
P.S.: I'd also like to suggest you post Spring for .NET relevant questions to our community forums - it is more likely to get your questions answered there.