Developing an Automation Interface for C# project
- I'm trying to develop an Automation Interface for our C# project. I'm running into all kinds of problems with classes needing to be serializable and references to project dll's. It is appearent to me that I don't know what I'm doing. Are there any good resources for learning how to do this. I would like the flexibility to have my app evolve without compromising Automation applications my customers may have developed (once I give them the ability to anyway)
- Changed Typebeejerdude Thursday, October 29, 2009 5:39 PM
Answers
- Jialiang,
I appreciate your time on this. I seem to have solves my problem by having my Automation Interface objects inherate from MarsthalByRefObj and overriding InitialLifetimeService.
As far as your question "Does your automation server support being attached?" I'm not sure I understand what that means. I have an oject (V5AppServer) that resides in a service that must be installed for our application to run. By activating that object a client gets access to the automation objects. The C# code to do this is:
IV5AppServer _appServer = (IV5AppServer)Activator.GetObject(typeof(IV5AppServer), "tcp://localhost:10010/AppServer.rem");
AutomationCLT aTrunk = (AutomationCLT)_appServer.GetV5Instance("TestID");
AutomationInstance aInstance = (AutomationInstance)aTrunk.GetInterfaceX("Automation Instance");
The AutomationCLT (Core Logic Trunk) is responsible for serving up requested automation interfaces (GetInterfaceX) and providing the core objects that the automation objects use. GetV5Instance launches the application that will be used by the automation client. Does this constitute "being attached"? Now I just need to find out how to do the equivalent in other apps like Excel and Lab View
AutomationInstance provides shutdown capabilities:
aInstance.Shutdown();
Does this constitute detaching?
As far as "Is it feasible for your core compoent to be writting in C++?" So far there are 90+ projects and Hundreds of Thousands of lines of code in the solution. I will look through your examples and see if they will help me figure out how to "talk to" my existing V5AppServer object residing on port 10010 with the name "AppServer.rem"
Thanks again for your time,
Beejerdude- Marked As Answer byJialiang Ge [MSFT]MSFT, ModeratorTuesday, November 03, 2009 7:21 AM
All Replies
Good morning. Welcome to the CLR forum!
You question is about UI automation support in .NET applicaitons. I find these materials on MSDN and MSDN magazine that discuss the topic:
http://msdn.microsoft.com/en-us/library/ms753388.aspx
This documentation describes the UI Automation API for managed code.
Automating Windows Forms
http://msdn.microsoft.com/en-us/library/ms996405.aspx
Lightweight UI Test Automation with .NET
http://msdn.microsoft.com/en-us/magazine/cc163864.aspx
We also have a forum dedicated for UI automation questions:
Development for Windows Accessibility and Automation
http://social.msdn.microsoft.com/Forums/en-US/windowsaccessibilityandautomation/threads
Hope that these information are helpful to you.
Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact msdnmg@microsoft.com.
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.Thanks Jialang,
I glanced through the articles and they all seem to talk about how to access controls on the forms, etc. I have a decently decoupled project with core model classes that don't rely on the existence of a GUI. I have a nice event model where GUI elements register callbacks to display the state of my core objects. In the case of the Automation interface that we are developing, I would like to have the ability to access functionality without the GUI elements even existing. I currently have it developed enough to run the application (Without a GUI) and do have access to core objects. The problem that I have is that when I call a core (model in MVC) function all of the classes that are used must be serializable since some of the system level classes (XMLDocument, Color, etc) are not marked as serializable this causes problems. I did use the NonSerialized attribute to resolve some of these problems, but it did not work in the case of Color. While it may sound strange that without a GUI I have to worry about color that is because the GUI state must be stored in the Model objects rather than the GUI itself. Strangely enough the serialization (while it must be dealt with) is not the biggest problem. The problem that I have is that this approach is causing me to have dependencies on my core dll's. This means that any program written to work with my interface will be broken everytime I change anything in one of my dll's. I need to find out how to call my core functions in thier current process space (no serialization) through a com like interface (no dependence on implementation). It is not my wish to exercise my core objects via an existing GUI.- Hello beejerdude
Does your automation server support being attached? If you are sure that the automation server will be started by your automation client, I have a working example for you. Please refer to the CSExeCOMServer sample in All-In-One Code Framework.
If your automation server needs to support attaching and detaching, I don't find .NET references, but I find some C++ samples on MSDN.
http://msdn.microsoft.com/en-us/library/bz0tsbyd(VS.80).aspx
http://msdn.microsoft.com/en-us/library/xfx55tf8(VS.80).aspx
They use the MFC class CCmdTarget to support automation.
Is it feasible for your core compoent to be writting in C++? You UI application written in .NET can load the native module.
Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact msdnmg@microsoft.com.
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us. - Jialiang,
I appreciate your time on this. I seem to have solves my problem by having my Automation Interface objects inherate from MarsthalByRefObj and overriding InitialLifetimeService.
As far as your question "Does your automation server support being attached?" I'm not sure I understand what that means. I have an oject (V5AppServer) that resides in a service that must be installed for our application to run. By activating that object a client gets access to the automation objects. The C# code to do this is:
IV5AppServer _appServer = (IV5AppServer)Activator.GetObject(typeof(IV5AppServer), "tcp://localhost:10010/AppServer.rem");
AutomationCLT aTrunk = (AutomationCLT)_appServer.GetV5Instance("TestID");
AutomationInstance aInstance = (AutomationInstance)aTrunk.GetInterfaceX("Automation Instance");
The AutomationCLT (Core Logic Trunk) is responsible for serving up requested automation interfaces (GetInterfaceX) and providing the core objects that the automation objects use. GetV5Instance launches the application that will be used by the automation client. Does this constitute "being attached"? Now I just need to find out how to do the equivalent in other apps like Excel and Lab View
AutomationInstance provides shutdown capabilities:
aInstance.Shutdown();
Does this constitute detaching?
As far as "Is it feasible for your core compoent to be writting in C++?" So far there are 90+ projects and Hundreds of Thousands of lines of code in the solution. I will look through your examples and see if they will help me figure out how to "talk to" my existing V5AppServer object residing on port 10010 with the name "AppServer.rem"
Thanks again for your time,
Beejerdude- Marked As Answer byJialiang Ge [MSFT]MSFT, ModeratorTuesday, November 03, 2009 7:21 AM
- Thanks for the sharing! It's a good idea to do automation through .NET remoting technology.
Regards,
Jialiang Ge
MSDN Subscriber Support in Forum
If you have any feedback of our support, please contact msdnmg@microsoft.com.
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.


