Recently, we're asked from one of our customers if it was possible to customize the BAM Portal to Portuguese. Well, knowing in advance that the BAM has very limited customization, our answer was "We will have to investigate".
We started our investigation, hoping that BAM Portal had support to satellite assemblies. In our installation the satellite assemblies with resources weren't under the bin directory. We checked also at MSDN if there was a Portuguese installation, however it seems there isn't.
Using Reflector, We started to explore the code in BAM portal assemblies. There is an assembly dedicated to have almost all the resources displayed in BAM Portal. The assembly that have the resources is Microsoft.BizTalk.Bam.Portal.UI.dll. Using Reflector we exported this assembly to a VS Project and started to edit the resources (using Resourcer).
Our first approach was trying to generate a satellite assembly for culture PT. We generated the assembly, deployed under bin\pt-PT, changed the culture in the web.config, but nothing happened (the BAM Portal remained in English). Using the tool fuslogvw.exe we checked what assemblies were being loaded. In fact, the .Net Assembly Loader was trying to load the assembly
Microsoft.BizTalk.Bam.Portal.UI.resources, Version=3.0.1.0, Culture=pt, PublicKeyToken=31bf3856ad364e35
however, our satellite assembly will never work, since we will never get the key to sign our assembly with the same key as the primary assembly.
We continued to look the code in Reflector, and when the ResourceManager is created, the assembly argument that is passed to constructor was loaded using the partial name Microsoft.BizTalk.Bam.Portal.UI. We knew that if we replaced this assembly with the one with the Portuguese resources, maintaining the partial name, we would get the BAM Portal in Portuguese (it worked). The problem with this approach is that "it's not clean": Microsoft could argue that our installation would not be supported since we replaced physically an original assembly. No way.
The solution was to use the web.config to do the replacement we want, using the .net framework mechanisms to redirect assemblies. We compiled again our assembly, now with a strong name, and signed with our private key. We added our assembly to the GAC and add this snippet to the web.config
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="Microsoft.BizTalk.Bam.Portal.UI"
fullName="Microsoft.BizTalk.Bam.Portal.UI ,version=1.0.0.0, publicKeyToken=edf781631e804c6e,culture=neutral" />
</assemblyBinding>
</runtime>
This snippet tells to the framework that if someone asks for the partial name Microsoft.Biztalk.Bam.Portal.UI it will get the assembly with the fullname specified in the attribute "fullName". Bingo!. It works. Now we have the BAM Portal in Portuguese. Changing the web.config, we think we are not compromising our installation in terms of support ;-).
Of course we have to be careful when upgrading to other versions of BizTalk. Maybe new versions can include more resources, or Microsoft can change the way display resources in the Portal. Who knows.
We finished our job customizing and translating all the Bam Portal to Portuguese. Our customer gave us a smile.
BFC