Localized resources in silverlight class library - silverlight

I have created a silverlight class library which is going to be consumed by multiple client projects. Inside the class library I have a localized dialog box showing the localized text: You have unsaved pending changes. This text is stored in Messages.resx (and the translations in Messages.da.resx etc.) and accessed like this:
Prompt.Announce(Messages.Verify, Messages.UnsavedChanges)
However when I add a reference to the class library dll from my silverlight client projects, the dialog box always shows up with the default language (english).
I can see that the class library build output is like this
root
SilverlightClassLib.dll
da
SilverlightClassLib.resources.dll
But the client build output is missing this, so I'm guessing that the danish translations are hiding in there - but how do I include this in the consuming silverlight client projects?
UPDATE:
This is the folder structure in TFS:
Classlib
Distribution
da
References
Source
Client
References
Source

Sounds like a deployment problem. You need to deploy the satellite assemblies of your class library (da\SilverlightClassLib.resources.dll) in your client's binary folder (still in a "da" subfolder, if missing).

Related

Reading PRISM & Unity configuration from multiple files

Can we have Unity configuration in file other than app.config file of the application? If yes, how to do it?
Can we combine unity configuration spread across multiple files?
How to define Unity configuration in the XAML file? (PRISM modules can be configured in XAML.)
Is it possible to have custom implementation of the Microsoft.Practices.Unity.Configuration.UnityConfigurationSection configuration reader class?
We are developing a WPF application which should allow other developers (working on various ares of the enterprise app) to register their XAML views (user controls) with our application. And depending on the functionality being used, our product will navigate user to the appropriate form/view. E.g. On click of the "Home" button, user would be navigated to the "Dashboard". But Dashboard may or may not be developed by the core product.
I am using Prism 4.1.
I believe that pretty much everything you need is explained in the following section of Unity's documentation:
Using Design-Time Configuration
It describes how to load one or several "configurations" into a Unity container from the default configuration file or from several other independent files.
Based on this, I believe you should be able to have a configuration file in each of your modules and load them manually in the Initialize method (or the module classes' constructors). If not, you can always register the corresponding type mappings programatically in the modules too.

Get WinForms app to apply localisation set in user control that exists in another class library

I have a Windows Form Application Project that references a class library containing user controls.
The developer of the class library has set localisation in the same way I do (select a culture from the user control language property then modifying the relevant text properties of the controls e.g. Label.Text).
When the PC culture is change, my Windows Form Application works as expected - the language of text is relative to the pc culture. However, all of the class library user control localisation isn't applied - the language is always English.
How can I get the User Controls in this class library to match the behaviour in my Windows Forms Application project?
Note: I am hoping the answer will be very simple and I don't have to manually set the text in the user control (from the resx file) in the user control initialisation/load event.
Also - the Class Library project is a set of DLL's, they are not included in the solution of my project.
Make sure that your satellite assemblies are in the correct location. The files should be organized like this:
MyAssembly.dll
en-US/
MyAssembly.resources.dll
zh-CN/
MyAssembly.resources.dll
What is a satellite assembly? gives a good summary of this.

WIn Forms loading labels from resx file

I'm creating a windows forms application. I have all of my resource strings (resx files) in its own project within the solution. Is it possible to reference those resource files at design time?
Coming from web (ASP.Net MVC) we were able to add a reference in the view to the resource file(s) we needed. Am I able to do something similar and set the labels at design time?
Not unless you are prepared to go down the route of using Localizable forms - see WinForms strings in resource files, wired up in designer

How to reference the WebContext.Current.User from a separate controls project?

I have a [appname].[ui] project that exists separate from my main silverlight 4 application. I do need to be able to bind to the WebContext.Current.User object in one of those controls and I don't know how to get an instance of it since it is in the Generated_Code hidden folder in the [application].web.g.cs file.
any ideas?
Create a RIA Services Class Library project containing the WebContext class.
Other client side projects can reference that class library project.
for instructions on how to structure your solution, you can refer here.

How do I use the same Web User Control in two different DotNetNuke (DNN) modules?

I am developing a number of modules for a client that will share some user interface functionality using a common Web User Control to provide the UI. When I wrote the first module and added in the .ascx file, all was fine. When I add the same control to the second module, I get the following error:
DotNetNuke.Services.Exceptions.ModuleLoadException:
The type
'XXX.ParametersControl.ParameterTabControl'
is ambiguous: it could come from
assembly
'C:\Clients\XXX\Code\Reporting\DotNetNuke_BaseInstall\bin\XXX.KPI_Configurable_Chart.DLL'
or from assembly
'C:\Clients\XXX\Code\Reporting\DotNetNuke_BaseInstall\bin\XXX.Survey_Grid.DLL'. Please specify the assembly explicitly
in the type name.
Both modules install and run just fine without this additional UI control.
I developed the UI control as a separate project that compiles it's own DLL for the included back end functionality, then deploy the application with just the compiled DLL and the control ASCX file in the module install files.
The include into the main module ASCX is done this way:
<%# Register
src="ParameterControl/ParameterTabControl.ascx"
tagname="ParameterTabControl"
tagprefix="uc1" %>
As you can see, I include the interface control by getting it from a subdirectory, which I implement as a Subversion external.
I reference the control's objects and properties in the main module's .vb codebehind like this:
ParameterTabControl1.DateRangeTabVisible = True
If (ParameterTabControl1.StartDate Is Nothing) Then
ParameterTabControl1.StartDate = DateAdd(DateInterval.Day, -90, Now)
End If
Any tips on how to engineer this so it doesn't happen? Some way to get the sub-control ASCX to connect only to it's own DLL and not be bound to the main module control while still allowing me to query properties and objects on the control to set and get it's properties?
Have you tried specifying the shared assembly and/or namespace in your # Register tag? I don't know the exact values for your shared component but you can specify exactly which namespace and assembly to use:
<%# Register src="ParameterControl/ParameterTabControl.ascx"
tagname="ParameterTabControl" tagprefix="uc1" assembly="XXX.SharedControls"
namespace="My.Shared.Control" %>
Check out the # Register documentation for more information.
I think that I solved this for good using a workaround to break the link between the projects. Having them both in the same solutions as the main control seemed to be the issue. I pulled the ParameterTabControl out of the solutions for the DNN Modules and just open it in a second copy of VS. Without the "project reference" in VS it just links the code to the DLL directly and doesn't import the DLLs namespace.
I had to add some post-build events to the ParameterTabControl to automatically push the new DLL to the testing platform in order to prevent version control issues between the two DNN Module solutions, but that wasn't too much work. Then the latest common DLL is always available to both and they both see the same version when compiled. It's a hack, but it works.
For once, I was pleasantly surprised with both the completeness and correctness of the error thrown and displayed.
Thanks Lance and Ian.

Resources