I was just applying for a small two week contract that was based on Localisation. This is the work I did to give myself a quick refresh. It reminded me on how well Asp.Net MVC3 works with RESX localisations.

As a start, you will need someway to change your Local Language quickly. My preferred choice is using the Quick Locale Switcher for Firefox which is in the image.

I have (over the last few hours) built up a fully translated version of the default MVC3 project which is viewable at http://resxstuff.adventureswith.net and is viewable as 2 languages available English (Which is default) and French (which is terribly translated BTW).

Turn On The World – Enable Globalisation

To enable globalisation, you will need to add this line to your web.config  in the <system.web></system.web> section:

<globalization uiCulture="auto" culture="auto"/>

Add the RESX files; and let the class be seen

If you are coming from Web Forms, note that for MVC you DO NOT HAVE TO (and perhaps should not) add your RESX to App_GlobalResourses or even App_LocalResources.

Just add them wherever you want and they can still be used, but only if you do the following:

• When you adda new RESX, Change the Access Modifier to Public

Otherwise you will be wondering why your resources don’t show up.

I followed the advice given by a few others to use the “RESX to a View” method, where you mimic the View folder structure within the Resources folder; as seen in the picture.

This usually means it is fairly easy to find the right file for the string that you want to change in a hurry.

Views – Changing out the text

I went through all the views and changed every “message to the user” into a string resource in a RESX file.

All the Html.LabelFor calls were replaced with resources calls
e.g. @Html.LabelFor (x => x.Username) became @Resources.Account.Register.Username

All boilerplate text was replaced with Resources e.g. “Login was unsuccessful. Please correct the errors and try again.” was pulled out of LogOn.cshtml and moved to Resources.Account.LogOn.Login_Unsuccessful

@Html.ValidationSummary(true, Resources.Account.LogOn.Login_Unsuccessful)

Controllers – Fixing up user messages

Essentially controllers are the same deal as the views. Take the static text, place it in a RESX file where it makes sense.

I used the files related to the views that were to be returned e.g. If an action method returned the Logon view, then I used the Logon.resx file for that text.

using Resources;

....
....
....
[HttpPost]
       public ActionResult Register(RegisterModel model)
        {
            if (ModelState.IsValid)
            {
                // Attempt to register the user
                MembershipCreateStatus createStatus;
                Membership.CreateUser(model.UserName, model.Password, model.Email, null, null, true, null, out createStatus);

                if (createStatus == MembershipCreateStatus.Success)
                {
                    FormsAuthentication.SetAuthCookie(model.UserName, false /* createPersistentCookie */);
                    return RedirectToAction("Index", "Home");
                }
                else
                {
                    ModelState.AddModelError("", ErrorCodeToString(createStatus));
                }
            }

            // If we got this far, something failed, redisplay form
            return View(model);
        }

       private static string ErrorCodeToString(MembershipCreateStatus createStatus)
        {
            // See http://go.microsoft.com/fwlink/?LinkID=177550 for
            // a full list of status codes.
            switch (createStatus)
            {
                case MembershipCreateStatus.DuplicateUserName:
                    return ErrorStrings.Username_Exists;  //these are the resource strings
                case MembershipCreateStatus.DuplicateEmail:
                    return ErrorStrings.Email_Exists;
                case MembershipCreateStatus.InvalidPassword:
                    return ErrorStrings.Invalid_Password;
                case MembershipCreateStatus.InvalidEmail:
                    return ErrorStrings.Invalid_Email;
                case MembershipCreateStatus.InvalidAnswer:
                    return ErrorStrings.Invalid_Answer;
                case MembershipCreateStatus.InvalidQuestion:
                    return ErrorStrings.Invalid_Question;
                case MembershipCreateStatus.InvalidUserName:
                    return ErrorStrings.Invalid_Username;
                case MembershipCreateStatus.ProviderError:
                    return ErrorStrings.Provider_Error;
                case MembershipCreateStatus.UserRejected:
                    return ErrorStrings.User_Rejected;
                default:
                    return ErrorStrings.Default_Error;
            }
        }

Models & Validation

The only tricky part is this one. And it’s not even that tricky.

Instead of where you would normally put ErrorMessage=”Something bad happened here”, you would instead point it the RESX files.

All of the Validation attributes have the Properties ErrorMessageResourceType and ErrorMessageResourceName which are explained as follows:

• ErrorMessageResourceType – Points to the resource file type
• ErrorMessageResourceName – Points to the KEY within that resource file

It is sad that the key is not strongly typed, like in the rest of the code; this is the annoying nature of attributes.

So here we have the example of a model with resource friendly validation:

public class LogOnModel     {      

[Required(ErrorMessageResourceType = typeof(ErrorStrings), ErrorMessageResourceName = "Required")]
public string UserName { get; set; }         

[Required(ErrorMessageResourceType = typeof(ErrorStrings), ErrorMessageResourceName = "Required")]
[DataType(DataType.Password)]
public string Password { get; set; }  

}

RESX – Adding more languages

So now you have all the files in place to use the RESX files that have been created as you went along.

Adding RESX files for other languages is easy. Just copy, paste, rename and it works.

The naming convention is as follows (from lowest to highest priority):

• Default – mytranslation.resx
• Language – mytranslation.en.resx  or mytranslation.fr.resx
• Regional – mytranslation.en-GB.resx or mytranslation.en-US.resx

So how do you create these for more languages? Luckily there is a fantastic free opensource tool that is available. ResxTranslator from Codeplex is able to read all your RESX files in the project and help you out by creating the other languages.

After they are created, just include them in the project.

Just a note that I haven’t been able to create another language from inside ResxTranslator, by which I mean add a language that doesn’t already exist somewhere in the resx files already.

First, I have to first create a file with the language in the filename, as shown above, for it to show up as an option in the “Add Language” tool. But once I have added a language/dialect for one RESX, it is available for all files. Maybe I am missing something here.

Further Reading

Nadeem Afana – Internationalising MVC3
http://afana.me/post/aspnet-mvc-internationalization.aspx

K. Scott Allen – Resource Files and ASP.NET MVC Projects
http://odetocode.com/Blogs/scott/archive/2009/07/16/resource-files-and-asp-net-mvc-projects.aspx

Glimpse is an amazing tool (that comes available with Nuget in Visual Studio 2010 [included in the Tools Update]) that can hook into the System.Diagnostic.Trace (ewww) to display error messages on your client side browser. Like so:

I don’t want to use System.Diagnostics as my Logging system. I could use it on the side, but not as the core. This would be awful and much too rigid. The good thing is, I typically use Common.Logging in all my projects because of it’s way to tie ANY LOGGING SYSTEM into a single point then ship those events off to any other receiving system. The receiving system in this case, is  of course, System.Diagnostics.Trace using the TraceLoggerFactoryAdapter

So to get to the point above this is what I did:

1. Using Create a new MVC project in VS2010
2. Nuget
   1. Install-Package Glimpse
   2. Install-Package Common.Logging
3. Add Common.Logging  to the web config

   <!--...config sections... -->
   <sectionGroup name="common">
         <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
   </sectionGroup> 
   
   <!--...configuration... -->
   <common>
       <logging>
         <factoryAdapter type="Common.Logging.Simple.TraceLoggerFactoryAdapter, Common.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=af08829b84f0328e">
           <arg key="level" value="ALL" />
           <arg key="showLogName" value="true" />
           <arg key="showDataTime" value="true" />
           <arg key="dateTimeFormat" value="yyyy/MM/dd HH:mm:ss:fff" />
         </factoryAdapter>
       </logging>
   </common>
   
   

4. Add some “problems”
5. Run the project and go to http://[your project url]/Gimpse/Configthen click “Turn Glimpse On”. Don’t be surprised that nothing happens.

   

6. Go to your main page http://[your project url]/ – See the icon in the right hand corner? Click that.
   
7. Look at those errors!

Conclusion?

Amazing! The guys who made Glimpse deserve some sort of medal!

So, you want AWStats on IIS7?  This doesn’t require a restart of IIS, so it can be done in place with no issues.

For IIS6, you will need to look elsewhere sorry. I’m also sorry you still have to deal with IIS6.

The 2 Required Files

Ok, this is more of a hack than a true conversion, but I haven’t noticed the difference… yet.

Remember to back up what you’re not willing to lose!

1. Remove your MVC project from your solution. Don’t delete, just remove. Then save all (Shift-Ctrl-S)
2. Edit your MVC project *.csproj file and change the ProjectTypeGuids to:
   <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
3. Add your project back into your solution and save everything

Whatever I think of Godaddy, they haven’t caused me too much pain yet, just minor inconvenience. This time it’s my precious StructureMap.

StructureMap, I like it and alot of people do, but it just won’t work under Medium Trust! So it’s either time to change Hosts, or change IoC container. Pretty obvious which one is the easier choice here.

So what choice do you have? Well not much. So the answer is:

Unity from Microsoft Patterns & Practices*

Here’s a nice manual to go with it.

And what’s not able to be run in medium / partial trust:

Windsor Castle
Spring.Net
StructureMap

There was someone who was explaining how to download and build Spring.Net to allow it to run under Medium Trust, but that seems pretty likely to cause issues when you hack code (try to ignore my NHibernate post when I say that).

It may be the same for the other 2, but off the bat, Unity wins.

*Caveat: Unity is restricted in what it can do when run without ReflectionPermission (which is what Medium Trust disallows), but typically this won’t affect much from the normal IoC behaviour.  The restrictions are explained on this MSDN doc, but it’s to do with internal and private constructors and properties. If it’s public you should be sweet.

Ok, so Log4Net is not that bad. It is a very good logging system, etc…

So how do you perform IoC with the NHibernate logger? Well, you can’t. Unless you are ready to HACK CODE.

That’s the brilliant thing about open source. Take it and modify until its the shade of green that suits you.

The First Warning

If you modify the DLL for NHibernate, then all associated DLL’s break.
For me this means FluentNHibernate wont like you. So you will have to rebuild that too for the new NHibernate DLL.

According to the bug report for exactly this issue, in the future log4net will be removed as a dependency (yay). For the logger interface Commons.Logging has been “sort-of” chosen. Meaning: you should  use the ILog interface from Commons.Logging for your Log interface! Make’s it a bit more future proof.

What I did to have IoC : 2nd Warning  – This is not a concise walkthrough

1. Download the source code of
1. NHibernate – Under the Browse Files you will find a SRC version.
2. FluentNHibernate – Download from GitHub
3. Commons.Logging 
2. Create a new Interface called ILog that is inside the NHibernate project. This is because it will be used as an adapter for the Commons.Logging. It’s probably best to put under a smart namespace like NHibernate.Logging.ILog
3. Create a LogManager class that does the same thing as the log4net LogManger, but using the Commons.Logging assembly. I know this is vague, but my implementation wasn’t very good. The idea is that when NHibernate is called, the LogManager is setup using the Commons.Logging.ILog object that was returned by my  IoC object  factory.
4. Remove the References of log4net from the projects
5. Replace all namespaces of log4net with the namespace of your new Interface and LogManager (say NHibernate.Logging).
6. Remove all Log4Net residue, like Cfg calls and XML setup arguments.
7. Build and everything should be happy.