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.
Related
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.
I've been creating a WPF application that initially loads as a task bar icon and then when clicked opens an appropriate window. This was a prototype and I want to move over to Prism and having watched the (superb) videos by Mike Taulty (channel9.msdn.com/niners/mtaulty) I have the feeling that what I need to do is create an application with a custom bootstrapper that does all the service registration but does not create an initial shell but instead simply loads the modules and perhaps identifies a module to Run. Has anyone anyone done something similar, if so how much work am I in for?
OK I bit the bullet and just tried it. I should first state that I was using the Autofac version of the Bootstrapper.
I returned null to CreateShell
I marked the apps ShutdownMode="OnExplicitShutdown" in the declaration at the top of App.Xaml (important otherwise it closes the application when you close the last window)
I created a module (IModule derived) that loaded the WPF notify icon by Philipp Summi (http://www.codeproject.com/Articles/36468/WPF-NotifyIcon)
In response to a command from the context menu on this icon I simply create the window and it's view model and show it.
This all works just as I had hoped. The only thing I have yet to do is see how to use regions with these temporary windows although other articles appear to have this covered. I'm not convinced the Autofac bootstrapper gives me any great advantages but I had developed a very early prototype using Autofac and stuck with it because it went smoothly. I will probably go with Unity or MEF in the long run just to avoid compatibility problems and to allow dynamic module loading from external plugins.
I have a project called "Buta".It is like a little operation system.And apps of my project must be in UserControlLibrary and I must attach it with code.When I click button, my usercontrol must be found in path and must be added to my project.That is all.
Thanks...
You're trying to build a plugin based architecture for your application? Then you might take a look at MEF. You can find more information at http://mef.codeplex.com/ and an overview at http://msdn.microsoft.com/en-us/library/dd460648.aspx
I am building an application in the MVVM style where the actual views (UserControls) are stored remotely and hopefully sent via a WCF service to my main application window. I am doing this in order to avoid having the user reinstall the application each time a new view is added. However, when I try to return a User Control from my WCF service I get an error stating:
System.Runtime.Serialization.InvalidDataContractException: Type 'System.Windows.Input.TouchDevice' cannot be serialized.
I am wondering if there is any way around this or if people have implemented something similar in other ways?
Thanks,
Ochowie
When you're loading from an assembly you're instantiating the compiled object from an assembly, which is a lot different than a deserialization operation, which is what is happening with a service call. The best you can do with serialization is transfer raw XAML that can be loaded with XamlReader, but this limits what you can do with a control since you can't use any code. If you're really set on hosting controls on your server the most flexible option would be to have your app download an assembly containing the new control and dynamically load the new assembly or use a separate launcher that can download new control assemblies before starting up the main application (make sure you take the time to understand the security implications and secure the assemblies and downloads).
What you're trying to do doesn't really make sense... controls are not DTOs, they're strongly dependent on their runtime environment. In WPF, there is also the issue of the dispatcher : even if you could transfer a control, how would you reattach it to your application dispatcher ? Anyway WPF controls are not serializable with the DataContractSerializer, and there is no way to change that.
However, what you could do is transfer a representation of the views in XAML. This is of course assuming your views are XAML only, without any code-behind. You could then load the views using XamlReader and render them in your UI. I'm not sure of the feasibility, but I think it's your best option.
You could also implement your views in a separate assembly, so that the users don't need to reinstall the whole application. They will only need to upgrade the modified assemblies.
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.