I intend to add a COM interface to an existing application (which, by the way, is written in C++ using Win32). I have some experience using COM objects, so I know the basic COM concepts of interfaces, etc., but this is the first time I'm actually implementing a component.
Ultimately I want to be able to use the COM interface to automate my application from scripts such as VB. I understand that there are two steps:
My application must act as an out-of-process server (i.e. I have to use MIDL and generate code for a proxy DLL and a stub DLL).
Once I have the server I can add automation capabilities by implementing the IDispatch interface.
Since the server-in-an-EXE thing with MIDL and what not is already a bit steep, I wanted to get a grasp on all that first before moving on to IDispatch.
I am reading the book "Inside COM" by Dale Rogerson and have completed the chapter on servers in EXEs (the following chapter will cover Automation).
The "Servers in EXEs" chapter provides example code that implements a server and a client. But it is necessary to start the server manually. This confuses me. Obviously, when my application (= server) is used by a client process, this extra manual step should not be necessary. Is there no mechanism to start the server automatically? Or is automation necessary to achieve that? At the moment, the prospect of having to start my server manually (once I even have one) makes me doubt I am moving in the right direction.
Hopefully someone with more knowledge of this can see what information I'm missing and point me in the right direction.
No, COM servers are not normally started by hand. Not sure why the book proposed it, possibly because it wanted to avoid talking about the registry keys you need to allow COM to automatically start the EXE. It isn't otherwise very complicated, you register the Application coclass of your app with the LocalServer32 key value giving the path to the EXE.
It is however not completely uncommon, especially with an existing program. One design decision to make is whether you let the client code completely control your program. Or if your program already has an existing user interface but you also want to expose services to other code. In the latter case it makes sense to let the user start the app by hand, like she'd normally does.
When your application is registered as LocalServer32, it will be invoked with the commandline specified there if no running process has registered a factory object for your CLSID yet.
This way, you can get the best of both worlds -- if the application is running already, this instance can provide the server side, and if it isn't, it will be started.
Automation is completely orthogonal to that -- your component becomes Automation compatible by implementing IDispatch.
Related
I've been given the task of trying to recreate a DLL that has slight modifications to the original DLL, which will be executed if another program runs. Basically a mocked up version of the DLL for testing/simulating other parts of a larger system.
I've searching to see if there is any method to check if the library is COM or DCOM but have not found any. I am aware of the differences, but given a DLL library, how can I tell if it is a COM or DCOM library?
Additionally, is there any way to swap out a COM/DCOM library with a newer technology but not change parts of the code that call the COM/DCOM library?
Having the executable code alone you cannot tell which it is except that if there're proxy/stub dll shipped with it you can assume it is DCOM.
The visible differences are in how the thing is registered. Digging into registration process can be easy or not so easy depending on how registration is implemented. If registration parameters are hand-glued inside code you'd have to reverse-engineer it the harder way. If registration uses a .rgs file which is stored in resources you can just extract it and see how registration is done. Anyway your best bet is to use a VM and export its registry, then register the component, export the registry again and see the difference - what was added.
Wow, you are going old school here!
If I remember correctly any valid COM object is can also participate in DCOM. Isn't the wiring for the remote procedure calls done at the operating system level?
From https://msdn.microsoft.com/en-us/library/aa295360(v=vs.60).aspx:
Once COM was adapted to work across a network, then any interface that
was not tied to a local execution model (some interfaces have inherent
reliance on local machine facilities, such as those drawing interfaces
whose methods have handles to device contexts as parameters) would
have the capability of being distributed: An interface consumer would
make a request for a given interface; that interface may be provided
by an instance of an object running (or to be run) on a different
machine. The distribution mechanism inside COM would connect the
consumer to the provider in such a way that method calls made by the
consumer would appear at the provider end, where they would be
executed. Any return values would then be sent back to the consumer.
To all intents and purposes, the act of distribution is transparent to
both the consumer and the provider.
Such a variety of COM does now exist. DCOM (for ‘distributed COM’), is
shipped with versions of Windows NT beginning with version 4.0. Since
late 1996, it has also been available for Windows 95 and its
derivatives. In both cases, DCOM comprises a set of replacement and
additional DLLs, with some utilities, which provide both local and
remote COM capabilities. It is therefore now an inherent part of
Win32-based platforms, and will be made available on other platforms
by other organizations over time.
I'm building an add-on UI system in VB.NET (Visual Basic specifically) that uses data from a legacy Microsoft Access system (that will at least for some time needs to be useful via its old, internal UI). I can do pretty much everything I need to do from VB.net - work with the data tables, call Access functions that contain decent functionality, etc.
What I'm trying to figure out is if Microsoft Access can call back to VB.NET (e.g., perhaps allowing me to pass in a function reference to be invoked).
The specific motivation is that there are 2 or 3 time-consuming Microsoft Access functions that produce critical output data - if you were invoking them directly via the MS Access interface, you would see things like progress bars and the occasional text update on a form of the work phase, progress %, etc. I can modify the MS Access code not to do these things if called from VB.net, but I'd really rather have the MS Access code reach back into VB.net so that I can provide some progress feedback in the new interface.
An elegant solution would be, as alluded to above, have VB.NET pass in the function delegate for MS Access to call - but as these are entirely different memory spaces, etc., I would think some internal framework would be required to get such a thing to work - perhaps via a shared DLL in some manner. I could go the old "polling" route, wherein MS Access writes out status to a table, and the (asynchronous) VB.NET app polls that table and uses what's there. That seems like such an inelegant hack, unnecessarily wasteful in resources and potentially bug prone, that I hate to go that route. If I could build just one function that MS Access could use, something that just passes a status string back, I think that'd cover the vast majority of cases.
Any suggestions would be most welcome.
I often create COM objects in .net for use with Access. Thus in your access code you could MOST certainly have the process loop “call” the .net object to update the process.
However, you likely are automating a copy of Access, and thus would like Access to call a routine in the EXISTING automation client, not have an instance of Access call a custom .net object. However, I think building a custom .net object would be the least work and hassle. In other words, you flip your approach around. You launch Access first and it uses your .net application as a COM object. That way, any routine in your application would be useable and callable from Access VBA.
The ONLY reason why I would walk down the road of implementing a call back if the main .net app REALLY needs to receive messages from Access as opposed to Access simply calling + using a custom .net object to display the process information. (so VERY easy to build a .net object for showing progress).
So best bet is to adopt the idea of turning your existing application into a COM object to be consumed by Access. This is VERY easy.
Once you do above, then
Access is launched first and then creates the instance of your application. (and thus can call/use any .net sub or function expose in your .net application from VBA).
And even if you don’t launch Access first, Access on startup could grab a running instance of your application (just like you can pick up a running instance of Excel or Word in Access/VBA).
Last but not least;
You probably can implement call backs, but I simply don’t know if this is possible without having to create a .net COM object as a go-between. As such, likely best to have Access just pick up a running instance of your .net application anyway.
So I would expose your .net application as a COM instable object.
So least amount of work would be to create a separate .net COM object that access uses, but if you assume for future that VBA should be able to call any vb.net routine then I would thus just build your .net application as a consumable COM object.
It's hard to explain our situaction.
We have a 3-tier application. The engine is a DLL coded in C++, then we have a VB6 ActiveX EXE that access to the engine via API calls, and at the top level we have a Excel Addin (in C# using VSTO framework) calling the middle layer with an interop DLL. At this time, each "connection" from the Addin to the engine creates a new EXE (VB6 uses API calls to access to the engine) and all works fine.
Now we are moving the middle layer to .NET, it works 'presumably' fine (it pass all our Unit test) but, we found an error when we open 2 "connections" at same time (ups, no unit test check this situation because it's a new behavour). The DLL have static objects that it's shared over all instances in the same process and we have interactions between "connections". In our old version each "connection" creates a new EXE with no memory sharing between processes, now it's the same process and they share memory and the static objects.
Following the tips from this question. We tried to build a COM EXE in C# to do an out-of-process objects in the middle layer but we have the same result. They share the static objects, at the end, each connection not creates a independent process.
It's clear, but not affordable at this time, moving API calls to ATL or changing the static objects to instanciable references with a handle and change all the API calls to get/set this handlers. I reviewed all examples in MS All-in-one but I didn't find any solution. Neither it's possible to keep only one connection at time, each workbook can have one connection and in the future we want to explore a Web application with multiple connections at same time.
Any suggestion?
Thanks in advance,
Whether COM starts new EXE per each COM object, or uses single EXE to instantiate all the object is controlled by flags parameters passed to CoRegisterClassObject. See
http://msdn.microsoft.com/en-us/library/ms693407(v=vs.85).aspx, and
http://msdn.microsoft.com/en-us/library/ms679697(v=vs.85).aspx
You need to pass REGCLS_SINGLEUSE or REGCLS_MULTI_SEPARATE flags.
Now, the trick is to pass this flag, as you might not call this method directly - the details depend on how you implemented the COM EXE.
it's not clear from the question, but it sounds like the "middle layer" you have was built as a VB6 EXE, and you're trying to replace it with a .net DLL. If that's the case, you'll definitely get the behavior you describe.
With a VB6 EXE com project, instantiating a new object starts a new process. With a .net dll (or a Vb6 dll really) you +won't+ get a new process.
You'd either need to create a .net EXE that exposes COM objects just like your VB6 exe does, or (sounds like you've already investigated this) you'll need to refactor your EXE objects to properly handle multiple instances within a single process.
Honestly, it'd probably be better to do that latter, since relying on singletons like this is generally a bad code smell. But it a pinch, you should be able to replicate the behavior of the VB6 exe with a .net project. You just can't do it in a dll.
Was your middle layer created in .Net? If it was, you might be facing the issue that your COM class is been created as a native .net object instead of a COM object. The solution usually involve using Primary Interop Assemblies. Take a look on this SO question to see if it matches your problem.
Through COM, one can potentially gain absolute control over a target system. For example: using javascript's ActiveXObject object in IE, one can create certain objects which were designed to have direct access or interaction with system properties and files. One would think common sense dictates users disable ActiveX features in IE immediately after installing the browser to ensure their system is protected while surfing the net, or at least paying close attention to which websites they permit. But, I doubt many average PC users know how or why to do this, or just get tired of mirco-managing it over time. I think any PC user or admin my COM class caters to would greatly appreciate not having to deal with that. Thankfully it looks like IE versions come packaged with ActiveX disabled by default nowadays.
I've built a very versatile COM class library in VB. I didn't intend for it to be callable from any website, but that feature is just part of the COM platform. I'd like to prevent the library from being called from IE unless the website is on a white-listed domain to proactively protect the user (and ultimately their entire intranet) from harm from malicious websites. What would be the best method in VB.Net to tell which application called my DLL, to be able to tell if it was called from any command or process originating from IE? And, what domain called my dll?
Edit: I believe this might be a duplicate. See: Calling Assembly to get Application Name VB.NET
System.Environment.GetCommandLineArgs()(0) gets me the calling application path. With this info, I can compare it to a black/white-list of applications. Problem solved for now.
Don't mark the control as Safe for Scripting.
Default security settings will not allow such controls to be scripted.
Self-answer, and possibly duplicate, I suppose. See System.Environment.GetCommandLineArgs()(0) from Calling Assembly to get Application Name VB.NET
In this case, the class never was marked as safe for scripting and the intent was already never to mark it safe. The issue was how to obtain the calling application info so I could add additional security measures in case those which the calling application had were not enough.
I have recently come across a situation where code is dynamically loading some libraries, wiring them up, then calling what is termed the "application entry point" (one of the libraries must implement IApplication.Run()).
Is this a valid "Appliation entry point"?
I would always have considered the application entry point to be before the loading of the libraries and found the IApplication.Run() being called after a considerable amount of work slightly misleading.
The terms application and system are terms that are so widely and diversely used that you need to agree what they mean upfront with your conversation partner. E.g. sometimes an application is something with a UI, and a system is 'UI-less'. In general it's just a case of you say potato, I say potato.
As for the example you use: that's just what a runtime (e.g. .NET or java) does: loading a set of libraries and calling the application entry point, i.e. the "main" method.
So in your case, the code loading the libraries is doing just the same, and probably calling a method on an interface, you could then consider the loading code to be the runtime for that application. It's just a matter of perspective.
The term "application" can mean whatever you want it to mean. "Application" merely means a collection of resources (libraries, code, images, etc) that work together to help you solve a problem.
So to answer your question, yes, it's a valid use of the term 'application'.
Application on its own means actually nothing. It is often used by people to talk about computer programs that provide some value to the user. A more correct term is application software and this has the following definition:
Application software is a subclass of
computer software that employs the
capabilities of a computer directly
and thoroughly to a task that the user
wishes to perform. This should be
contrasted with system software which
is involved in integrating a
computer's various capabilities, but
typically does not directly apply them
in the performance of tasks that
benefit the user. In this context the
term application refers to both the
application software and its
implementation.
And since application really means application software, and software is any piece of code that performs any kind of task on a computer, I'd say also a library can be an application.
Most terms are of artificial nature anyway. Is a plugin no application? Is the flash plugin of your browser no application? People say no, it's just a plugin. Why? Because it can't run on it's own, it needs to be loaded into a real process. But there is no definition saying only things that "can run on their own" are applications. Same holds true for a library. The core application could just be an empty container and all logic and functionality, even the interaction with the user, could be performed by plugins or libraries, in which case that would be more an application than the empty container that just provides some context for the application to run. Compare this to Java. A Java application can't run on it's own, it must run within a Java Virtual Machine (JVM), does that mean the JVM is the application and the Java Code is just... well what? Isn't the Java code the real application and the JVM just an empty runtime environment that provides nothing to the end user without the loaded Java code?
I think in this context "application entry point" means "the point at which the application (your code) enters the library".
I think probably what you're referring to is the main() function in C/C++ code or WinMain in a Windows app. That is, it's the point where execution is normally started in an app. Your question is pretty broad and vague--for example, which OS are you running this on--but this may be what you're looking for. This might also address the question.
Bear in mind when you're asking questions, details are your friend. People can give you a much better, more informed answer when you provide them with details.
EDIT:
In a broader context consider what has to happen from the standpoint of the OS. When the user specifies that they want to run an app, the OS has to load the app from the hard drive and then when the app is loaded into memory, it has to pass control to some point in the memory blocked occupied by the newly loaded app to continue execution. That would be the "Application Entry Point". When an app is constructed with dynamically linked code the OS has to load all that dynamically linked code in order to get the correct app image into memory. Loading up those shared bits of code does not change the fact that the OS must have a point to which to pass control when the app is loaded into memory.