I've already created a UI framework based on the same strategy. It works very well.
My MDI parent window is written in C# and I have "application modules" that are dynamically discovered when the exe is started. The container application, on startup, looks for assemblies that implement the interfaces that are required to be implemented by an application module. Based on the interfaces the container calls into the application so that it can add an icon to the toolbar and an menu item. I go even further in the application modules because I use visual inheritance so that the application modules have a similar look and feel. VI is GREAT! There is more that the framework does but that gives you an idea of the possibilities. It is very sweet indeed. The customer for which I developed this framework is finding very easy and flexible to use. Chris Rolon Principal Consultant -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Jay Ayliff Sent: Thursday, April 18, 2002 2:18 AM To: [EMAIL PROTECTED] Subject: [DOTNET] Using System.Reflection to create Extensible Apps Hi List, I want to run a development technique past the experts in the list to get comments and suggestions: We need to write a large and extensible application using WinForms. I have worked out a design strategy but would appreciate any commentes from the experts in the list. The idea I have in mind is to have a container program coded as an EXE, based on an MDI form. This will not do any application processing but will load and run the other programs. These will be coded as single classes inheriting from System.Windows.Forms. A number of these classes can be compiled into a single DLL assembly which can be put on an Intranet web server. The code to load and run the form in the DLL is as follows: Dim ClassName As String ' Name of the class to be instantiated Dim AssemblyFileName As String ' URL where we look for the assembly Dim AssemblyName As String ' Name of the Assembly Dim Assem As System.Reflection.Assembly Dim ProgObj As Object Dim ProgType As Type ' For the sake of demonstration, set these values explicitly. ' In the real app they will be read in from a database AssemblyFileName = "C:\VBDotNet\TestProject\bin\TestProject.dll" AssemblyName = "TestProject" ClassName = "MyForm" ' MyForm is a class in TestProject inherited from Windows.Forms.Form Assem = System.Reflection.Assembly.LoadFrom(AssemblyFileName) ' Load the assembly ProgType = Assem.GetType(AssemblyName & "." & ClassName) ' Get the Type ProgObj = Activator.CreateInstance(ProgType) ' Create an Instance ProgObj.MDIParent = mvarMDIMain ' Put it in as a child of the MDI form... ProgObj.Show() ' ... and show! I have found this to work, and it seems to have enormous possibilities: - We can group logically related applications in the same DLL assembly - We can easily implement new versions of apps by either overwriting the DLL assembly or simply by changing the value of AssemblyFileName so the program looks in a different place for the new version. I am happy about other aspects of this development, e.g. passing data between the loaded form and the container. What I really want a warm feeling about is whether this use of System.Reflection is a viable way of creating an extensible application, or whether I am storing up trouble for myself further down the line. I await your gracious comments. Regards, Jay Ayliff Stalis Ltd You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
