I attempted to get localized resource satellite assemblies for the WebDataGrid by following the instructions in this document:
http://dl.infragistics.com/community/aspnet/articles/wdg-localization/WebDataGridLocalization.doc
On my development machine, this works fine. The filters are being localized as promised. However, I am deploying my web site to another machine and I've run into a problem. I am placing these satellite assemblies into the appropriate localization folders in the application's bin directory (i.e. de-CH, as in the document). However, when I run the website in the target machine, the filters are displayed in the default culture.
After a search, I noted another post which brought up the idea of the fact that these assemblies are delay signed, and that this might be an issue (requires a fully strong named signed assembly).
While I suppose I could use GACUTIL.EXE to install the assembly to the GAC of the target machine, I would prefer to keep these in the bin directory of the application.
Question: Am I on the right track as to the cause of the issue? If so, is there any way to strong sign these assemblies such that they will work when deployed with the application as members of the application's bin directory? If not, is installing to the GAC an appropriate course of action?
Hello cfshuhl,
According to this article: http://msdn.microsoft.com/en-us/library/1ztca10y(v=VS.85).aspx Satellite Assemblies are shadow-copied into the global assembly cache, to eliminate potential locking issues. The only assemblies that can be shadow copied are those stored in the application directory or its subdirectories, specified by the ApplicationBase and PrivateBinPath properties when the application domain is configured. Assemblies stored in the global assembly cache are not shadow copied. If you want to install satellite assemblies into the global assembly cache, they must have strong names. Strong-named assemblies are signed with a valid public/private key pair. Compiling Satellite Assemblies With Strong Names - http://msdn.microsoft.com/en-us/library/21a15yht(v=VS.85).aspx
Hope this help
Actually, no, this does not help. If you reread my initial post, you will find that I do NOT want to install to the GAC. I want to place the satellite assemblies into my website's bin folder. The problem with this approach is that the assembly resolver will not use delay signed assemblies unless they are installed to the GAC (again, which I have done and does in fact work). Since I cannot strong-name the satellite assemblies (I do not have access to the key the original DLL was signed with), I cannot deploy them as part of the website file structure. As a part of the target deployment installation process, I need to do a GAC installation of these satellite assemblies, which, as I've stated, I'd like to avoid.
My questions remain. Is there a methodology to accomplish what I want to do, or is the methodology presented by the document I referenced the recommended way to localize my applications if I intend to use Infragistics controls in my solutions?
An additional question. Has any thought been given to shipping properly signed satellite resource assemblies with the product, at least with a few of the most commonly supported languages? It would be nice to have this, rather than having to perform these steps manually.
Hello Charles,
I have made a sample in order to test the scenario in which the satellite assembly is not strongly signed and is no installed into the GAC. I followed the procedure outlined in the document as I skipped the steps for signing and installing the satellite assembly into the GAC. If I put the resource assembly into the bin all goes well. The filter rule “equals” has been localized “Switzerland”. Please download the sample from this link: http://forums.infragistics.com/members/RMinchev/files/Localization/WDG_5F00_Localize.zip.aspx
In order to see the localized filter rule you have to set default language for your browser to be [de-CH]
Actually it’s a good point about the idea to distribute localized assemblies with the controls. You can bring you opinion to our product management attention as you submit a feature request : http://devcenter.infragistics.com/Protected/RequestFeature.aspx
Let me know if I could assist you further.
Yes, I did test it with our production resources and it does appear to work. The issue seems to be the second pass with the sn.exe utility. Once this is done, it seems to "tie" the DLL to the machine that the assembly is to be installed, such that if the sn.exe utility with the -Vr option is performed on to the DLL on machine A, the DLL won't be recognized by the assembly resolver if deployed to machine B.
It is a good work instruction, otherwise. Perhaps it could at least be updated to indicate that if you intend to deploy resources as hub-and-spoke without installing the resources to the GAC, to stop at the point prior to the second use of the sn.exe utility.
Thanks for your help.
Okay,
I have the following deployment structure
The result is the same. The filter has been localized succesfully. Did you try this on your machine with the attached sample?
OK, here is the difference. I see that you've done everything with your example that I tried, except for one thing. The de-CH localization is just an example, but in practice, the web site will have multiple localizations. To do this, you have to follow the hub-and-spoke model by placing your resource files for each localization into a separate subfolder under bin. I noted your resource file is directly under bin, and this will not work for my purposes. Offhand, does your sample work if you create a de-CH subfolder under bin and place your compiled de-CH resource assembly there? This is the deployment I am looking for.
Just another bit of info for clarity: My web-site provides a control for language selection for "on-the-fly" localization. It uses the selection to set the thread locale on every page load.