Hello Everyone,
I am writing a VB.NET application. This application will be distributed with a standard UI that will suit most of my customers. However, some customers (many actually) will require custom Windows Forms created from time to time as state regulations change.
I'm not sure how to accomplish this.
One way would be to customise the application everytime the user needed a new form. So I'd go in, add a menu choice and code the associated click() event to load the new form, I'd create the new form, recompile the application, and distribute it to my customer
who would then need to totally reinstall the application to get the new functionality.
There has GOT to be a better way!
All I need to do is distribute an 'update' file of sorts to my client which would 1) add a new menu item to the main, already installed application that when clicked would launch a new form and, 2) add a new Windows form to the already installed application.
Is this possible? How can I accomplish this? Are there any good resources I could hit to help me out?
Thanks!
Anthony
-
-
The complexity of this basically depends on how general a solution you want. If your updates are additive though, I would suggest you define an interface (IUpdate) with two methods (OnAppStart(CoreWindow app), OnAppShutdown()) - where CoreWindow is the main window of your application (which is initially named Form1 when you first started your application).
You then program your main (core) program so that during the load procedure, the main form looks through a directory and reflectively loads all dlls in a directory, loads all objects that implement IUpdate and calls their OnAppStart(CoreWindow app) or OnAppShutdown() respectively.
You can then code your addon-code, such as adding a new menu and form by creating a new solution that references your core library, creating the new form and creating an update stub that impelements OnAppStart(). The code in OnAppStart() should be able to hook into the menu of CoreWindow, which it recieves as an argument, and add a new menu item, complete with click event that launches your new form.
Implementing OnAppShutdown() is suggested because you may want to introduce new shared resources (such as file handles, SQL connections, whatever) which should be properly closed during the app shutdown. Even if you don't need them now, you may need them in future, so don't leave this one out. It should be called during the OnClose() of the CoreWindow.
Distributing updates to your application is now as simple as dropping a new dll into the directory of updates.
If you want to have updates applied in order, you can add a unique update field (int) to the IUpdate interface, and have the core program call OnAppStartup() and OnAppShutdown() in order (oldest to most recent on startup, most recent to oldest on shutdown).
Hope this helps. -
evildictaitor said:The complexity of this basically depends on how general a solution you want. If your updates are additive though, I would suggest you define an interface (IUpdate) with two methods (OnAppStart(CoreWindow app), OnAppShutdown()) - where CoreWindow is the main window of your application (which is initially named Form1 when you first started your application).
You then program your main (core) program so that during the load procedure, the main form looks through a directory and reflectively loads all dlls in a directory, loads all objects that implement IUpdate and calls their OnAppStart(CoreWindow app) or OnAppShutdown() respectively.
You can then code your addon-code, such as adding a new menu and form by creating a new solution that references your core library, creating the new form and creating an update stub that impelements OnAppStart(). The code in OnAppStart() should be able to hook into the menu of CoreWindow, which it recieves as an argument, and add a new menu item, complete with click event that launches your new form.
Implementing OnAppShutdown() is suggested because you may want to introduce new shared resources (such as file handles, SQL connections, whatever) which should be properly closed during the app shutdown. Even if you don't need them now, you may need them in future, so don't leave this one out. It should be called during the OnClose() of the CoreWindow.
Distributing updates to your application is now as simple as dropping a new dll into the directory of updates.
If you want to have updates applied in order, you can add a unique update field (int) to the IUpdate interface, and have the core program call OnAppStartup() and OnAppShutdown() in order (oldest to most recent on startup, most recent to oldest on shutdown).
Hope this helps.Thank you very much for your great reply. It's just what I've been looking for. I'm going to investigate IUpdate right now and see how to properly use all this stuff.
Thanks Again!
Anthony -
Papillion said:evildictaitor said:*snip*
Thank you very much for your great reply. It's just what I've been looking for. I'm going to investigate IUpdate right now and see how to properly use all this stuff.
Thanks Again!
Anthony
There is no IUpdate defined in the framework, it is something that you would have to create, it's a route I've used several times and works well.You may also want to look at System.Addin, for some examples try these:
http://msdn.microsoft.com/en-gb/magazine/cc163476.aspx
http://channel9.msdn.com/posts/DanielMoth/Managed-AddIn-Framework/
http://channel9.msdn.com/posts/DanielMoth/Version-Resilience-in-the-Managed-AddIn-Framework/
-
Not to hijack the thread, but it is somewhat related. Is there a method in .NET similar to the old VB CreateObject method?
-
it is part of one way to handle the OP's problem.spivonious said:Not to hijack the thread, but it is somewhat related. Is there a method in .NET similar to the old VB CreateObject method?
there is a thread here right now that asks about it.
http://channel9.msdn.com/forums/TechOff/428654-How-to-create-an-object-from-type-name-string/
Type type = Type.GetType("MyAssembly.MyType, MyAssembly");
object obj = Activator.CreateInstance(type) ;
you could create forms as dll's and ship a config file / xml settings file with a package of dll's that the main app could load on the fly.
if you used an interface to describe a contract for loading and running the forms then your main app could have as many optional parts as you want ....
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.