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.
Related
Since VSTO has yet not been ported to .NET Core, can I do it the old fashioned way and create a unmanaged shim to load the CLR and host the managed .Core 5 add-in?
My particular use case is an Outlook COM add-in that is currently built using VSTO against .NET framework 4.7 but I want to start leveraging .NET 5. In terms of interaction with Outlook, it just adds some buttons on the Ribbon and makes a few calls into the Outlook object model. I don't need to do anything like VSTO document based add-in in Excel for example.
I don't want to down the JS path as there is quite a bit of C# code that would need to be ported.
I found this https://github.com/jozefizso/COMShimWizard/releases which shows how to do it with the .NET framework, and am assuming its pretty close if not identical to what the shim wizard did back in VS 2010.
Since I need to load .NET 5 I believe to load the CLR I will need to do something along the lines of what is outlined here: https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting.
Before I dig further into it, is the approach likely to work? In particular, will in be possible to do necessary COM gymnastics to instantiate the managed components?
And assuming all this is feasible, will this be more or less equivalent to what VSTO does for .NET framework 4.x, i.e. is it less safe or performant in any way or will there be any functionality that won't be available compared with an add-in built with VSTO?
Update 1
I did some more research which raised some additional potential issues.
For the .NET framework case, once a class has been loaded into the CLR it is relatively easy to "unwrap" the returned reference to get a COM pointer which can be used to access COM interfaces that the type implements. It is not clear to me how this can be done when loading the .NET Core runtime using netfxr interface.
.NET Core does not have the concept of app domains, does that mean the multiple add-ins loaded into the Core runtime would not be isolated, or there a way to achieve some degree of isolation? From what I have read it seems that maybe their heaps would at least be isolated but I'm not sure.
Update 2
From reading this https://github.com/dotnet/runtime/blob/main/docs/design/features/COM-activation.md it seems that in Core, requests to types in assemblies as COM servers will result in auto loading the Core runtime (if it isn't already loaded) and create the object in a separate AssemblyLoadContext so maybe a shim is not needed at all? On the other hand it seems that if the Core runtime is already loaded and the version does match what is required by type you are trying to create, then the type will fail to load, so that seem to be a problem...
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.
I am very new to development on MS platform and hence I have some issues in understanding the concepts of dll's and how they are used by applications. I have quite extensive experience with Java and will try to compare them in order to understand the functionality even more.
From what I understand, dll's are complied c++/c#/mfc code. Its almost equivalent to .class from Java (Except class files can be decompiled). dll's can be imported in any other source files as a library and so can class files.
Now what I want to know is when we use this dll, is there just once instance of dll that will be shared by multiple instances of application using it or each and every application have its on instance of the dll. I assume it would be the latter as it makes more sense since MS development is completely object oriented.
One prime example of this can be running COM add-ins in any office application. We can have several open instances of excel application with different workbooks. So does each workbook have its own instance of the add-in (which is in form of a dll file) or there is just one instance which is started when excel first loaded and it is shared with all the open workbooks until the last one closes.
If they are not shared, is there any way to share some methods between time (like making static methods and variables in Java)?
Here's a comprehensive explanation of Windows DLLs. http://support.microsoft.com/kb/815065
Regarding instances, I believe it is the latter as you suggested i.e. 1 instance per process, which in case of COM add-ins would be each running instance.
See this paragraph from the article.
When multiple programs use the same library of functions, a DLL can
reduce the duplication of code that is loaded on the disk and in
physical memory. This can greatly influence the performance of not
just the program that is running in the foreground, but also other
programs that are running on the Windows operating system.
so my question is relatively simple, can I create VB6 application that references a class in a dll, and then substitute that dll for another at runtime?
Now my intial guess is... no chance in VB6.
So my thoughts turned to a VB.net interop dll. Could I do it in here, and then call the interop dll from the VB?
Again, my guess would be no.... but I'd be happy if someone knew differently.
The only thing that I think would actually work would be DI in .Net, but I'm limited to .net 2, or 3.5 at a big push, so I dont know if that is possible.
So for the background....
I have a dll that a specific site uses, but we dont want to ship that out to everyone. Instead, we want to build a clone dll which just has the interfaces setup so that the VB6 build will complete.
When it gets to the site that needs it, they want to replace the dummy dll, and drop in their version instead.
Note: We do use RegFreeCOM when its gets installed, so I do have the manifest files that I could play around with if needed.
Any ideas would be much appreciated.
Nick
Its a COM dll so its not statically linked to the VB6 exe, so long as the clsids and interface ids are the same in the type library for both DLLs, you can swap them around as you see fit. (If its a VB6 dll this is trivial to do with the 'binary compatibility' build option)
You could also use late binding instead and instead of making a reference directly in your VB6 code, you would create an object and then set that object to an instance.
Examples and information:
MVPS
Microsoft
We have an application which uses COM dll.Now, we are pushing updates of this dll.We copy the new dll ( overwriting the existing one) and register the dll. Is this a good practice.Or, should we first unregister the dll already on clients machine.
As long as your old COM dll implements the exact same interfaces, there's no reason to unregister/register
While updating the COM dll, we should not change the old interfaces i.e., IIDs (basic rule of the COM) so that it won't break the clients which are using the old interfaces.
So there is no need to un reg the old COM dll, just register the new DLL. Upon registering the new dll, as old interface uses same IID, it will not going to break the clients which are using the old interface.
Two things you have to consider if you want just to replace the Com Dll:
They old and new have the same GUID.
You haven't append any new interfaces to the updated com Dll.
otherwise you should unreg/reg your com dll
Well, supposing you're writting your COM server using VB6 (a common case a couple of years before) you'll need to set it binary compatible to make VB keep same GUIDs for the component.
As the objects for the classes in the DLLs most of the time are being created using the class factory built into the same dll, if GUIDs not match with the ones the Class Factory knows about it cannot create objects for the old GUIDs even if no changes were made to Interfaces.
That was a part of the DLL Hell, remember?
If you know all your client platforms are running Windows XP or later, you might consider using Registration Free COM, and thereby avoid the entire issue.
See my answer to "How to register COM libraries at runtime?" for details. The article "Registration-Free Activation of COM Components: A Walkthrough" on MSDN has a complete walkthrough of what to do.