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.
Related
I have a modular application created with PRISM 4. My main WPF application.desktop solution has an app.config and my sysAdmin module has app.config and a settings file.
Can anyone tell me how I can edit the sysAdmin modules' config/settings files as they seem to be wrapped up in the sysAdmin.dll??????
Hmm... hopefully the interfaces are defined in a commonly referenced assembly? If so, then just UnityContainer.Resolve<T>() the interface that contract-binds the class which exposes the config/settings that you require.
That's how I'd do it, from a naive point of view. Once we get into more complicated factors, this would change, but I'm not sure exactly what your setup is.
I couldn't figure out how to make my modules' app.config visible upon deployment so I added my settings which I needed to be editable upon client machines to the app.config of main WPF application then added a "sharedInfo" class in my Infrastructure module and populated this upon loading the main app from the main app.config so I can access the values in my module. Not ideal but works for me.
I'm developing an application that both run as a standalone application and a plugin. We're using dependency injection to inject different implementations of the application logic.
The GUI in the standalone application and the plug-in is identical today, but we're seeing a need to do minor customizations to the GUI depending on the context. This is typically small changes, like providing different input mechanisms (e.g. a drop down list in the standalone version and a hierarchical selection control in the plug-in version). Typically the controls used in the plug-in version will be controls provided by the plug-in API.
Since there typically will be many small differences between the standalone GUI and plugin GUI rather than big components (e.g. buttons rather than pages in a tab panel) we do not wish to create one XAML for the plugin and one for the standalone sharing a common view-model.
Are there any patterns for injecting user controls in WPF?
Prism! :D it is a framework for MVVM/ dependency injection and WPF/Silverlight
See http://compositewpf.codeplex.com/ and Composing the User Interface
I'm new to Prism and have a conceptual question.
What I want to build is a Silverlight app that can load its layout (and the modules that are used) from a config file. Imagine I have a number of modules (e.g. a Chart, a Treeview and a Newsticker) and I want to use my config file to determine which of those are visible in my app and also where they are located on screen.
So if I want to have an app with just a Graph and a Treeview but not a Newsticker, would it be enough to just create an XAML file that contains views to those two modules? Would this XAML file be the shell?
Could I then have different XAML files/shells/config files to "generate" different looking applications at startup?
I don't need to switch layouts at runtime, I just want to be able to easily configure my application to use a different set of modules. I would appreciate pointers in the right direction.
Here are some approaches that I found:
http://blog.roundthecampfire.net/2011/10/creating-composable-ui-with-f-and-prism.html
http://www.dotnetpatterns.net/content/147-Lesson-2-Prism-creating-a-dynamic-region-layout-with-templates
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
I have developed a Microsoft Prism 4.0 application and I am struggling to understand how to make the user application setting functionality available to modules.
e.g. a Properties.Settings.Default.MyProperty.
I can define a simple class that gets populated via the bootloader (which does have a handle to the properties) and inject that into the modules but If I want to save a change of property, I need believe I need a handle to the Properties.Settings context which is not available to my modules (which are simple class libraries).
Your scenario sounds like the perfect reason to use a "Service" class. Create an interface and class called IUserSettingsService and UserSettingsService that has the information (or can load and save it from where it is stored).
Read Chapter 3 of the Prism 4.0 help file, Managing Dependencies Between Components, Registering Types with (either Unity or MEF, depending on what you are using as your DI Container).
Then, in your ViewModel that needs the user settings, locate and use your service. In MEF, it is as simple as adding a property of type IUserSettingsService with an [Import] attribute, or using [ImportingConstructor] and having a parameter of type IUserSettingsService. With Unity, you access the service through the container. See Chapter 10 of the Prism help file - Advanced MVVM Scenarios.
Added after comment discussion:
Because you need your service to be in the context of your main application, you can implement your service class there. Create the interface for your service in a shared library that can be used by both the main project and your modules. Finally, load the service in the bootloader class instead of in a module.