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...
Related
I can't seem to figure out how to get F# TypeProviders to work in a Windows Store (C#) app.
As far as I can tell, TypeProviders can only be used in an assembly targeting the full .NET Framework, whereas Windows Store apps must target .NET Portable.
I have created an F# assembly and referenced the F# TypeProviders library, however when attempting to reference this assembly from my Windows Store app, I receive an error stating that the library could not be referenced.
Is there any way around this? I want to use F# TypeProviders to reference various data sources and then use the generated code/types in my Windows Store app. Anyone have experience with this?
UPDATE:
Just to be clear, I am asking if there is a way to use the standard F# TypeProviders (such as WsdlService) in a Windows Store App?
Looking at the other assemblies FSharp.Data.TypeProviders.dll is referencing, I don't think there is a way around this. Since most type providers are used for accessing a database in one way or another (ADO.NET, LINQ to SQL, EF), it references System.Data.dll which is not available in WinRT.
The only data sources supported by built-in type providers that can be used in WinRT are web services and OData services. Their type providers maybe could be supported in a WinRT project if they were implemented in a separate library, but not in their current implementation.
Type providers are design/compile time facility. It should work in Portable library profile. It is maybe dependent on how is type provider library implemented, but in general, it should work.
For more info see F# type providers with Portable Library
Visual C++. I have to implement some drawing and printing functionality that will be incorporated into (other developers') COM dll. Firstly I thought of doing everything using pure GDI and nothing more, but it seems that printing and print previewing is hell of a job to be done in GDI compared to the MFC implementation. So I decided to focus on MFC. Quick side question here: Is my choice right? I mean, are any easy ways of implementing printing (and print-preview) without MFC?
Now that I need MFC (assuming if you also agree with this), I have two questions about how to do it:
1) I believe the COM dll is the ATL project (it's not my code, some other developers independently develop it). Can I enable MFC support in that dll? What are the risks/limitations/drawbacks of having MFC runtime in the COM server? And if you advice doing this, how can I do it?
2) As much as I want to affect the third-party COM server's code as little as possible, I thought it might be the better approach to implement my code as a separate MFC-based DLL, and load and use that DLL from COM server. Do you advice doing this? What are the risks/limitations/drawbacks in this situation?
Shortly, I want to use MFC's drawing and especially printing capabilities in my code, which itself should be integrated in another developers' COM dll (which itself is utilized in a large corporate application). I'm no expert in COM technology so I'm a little bit confused. What are my best options?
You can use MFC in your own dll internally, and expose functionality to your users with non MFC intruded function: for example if you need to pass a point from/to ypur caller, use the GDI standard POINT structure, then convert it to a CPoint to use internally. In this case you don't need to enamble use of MFC in the ATL project ( that is possible anyway ) but of course you need to distribute or link with the MFC dll. If you want mantain the caller com dll as clean as possible, you can definitely create your own ATL+MFC dll and expose your functions via com interfaces too, but keep in mynd to avoid put MFC related objects in the interface.
Printing and print preview is a hell of a job unless you're using MFC Document/View Architecture. Will your COM expose such advanced UI?
If your COM must be independent of .NET then MFC is the way to go, otherwise I would use .NET. If you choose MFC, make sure you link to it statically. Otherwise you will most likely end up with runtime errors on machines where the necessary MFC version is missing.
Except for this, I wouldn't worry about compatibility since the idea of COM is to let the underlying magic do the marshaling of integers, strings and other objects.
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
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.
I am very new to VB.net. I have written these objects in VB6 before. I'm just lost in VB.net, but (kicking and screaming) I have to learn how to do this. I've been googling for hours with only minor steps forward. Can anyone post a link that explains start to finish how to do this?
I have managed to write the class object, What I can not tell is how to register it and where the name1 and name2 in the CreateObject("Name1.Name2") come from.
Regsrv32 will not work. It says "Entry Point not found" and will not register it. Also, I can not drop it into the Assemblies directory. I read something about a regasm command one uses, but I can't seem to make this work either.
Thanks in advance for any assistance.
I am going to assume you are not trying to write a COM DLL but rather a complete project that call various sub assemblies like a VB6 EXE call a ActiveX DLL. If you can be more specific about what you are trying to do it would help me better.
Several points about VB.NET versus VB6.
1) For .NET only projects there is no registration. If a EXE or DLL references another .NET DLL the only requirement is that the DLLs be present in the parent's directory.
2) You can do a COM style registration for .NET apps only by registering the .NET assembly in the GAC. However there are several requirements for doing this. Do a search on the .NET GAC and it will give you the scoop on how to do this.
3) You can setup the .NET assembly to use COM in which case it will operate by the rules of COM including registration with regsvr.
You will find for .NET only project that #2, or #3 only come in rare instances. #1 will apply for 90% of your DLL assemblies. Of This is dependent on your project.
A common use for CreateObject is allow for plug-ins or installable libraries. .NET handles this through the Reflection API. With the reflection API you can look in a directory, go through each .NET DLL and see what them and create objects from what you find. Search for .NET Reflection to read up on this.
If your project is .NET only then I recommend that you create a Assembly that is reference by both the master assembly and the individual sub assembly that define the interfaces of the objects you are creating. This when you use the reflection API and determine the Object type you can assign it to a variable of that interface and code it noramlly with intellisense and other aids.
if you have old COM ActiveX Controls or DLLs .NET will generate a wrapper class that exposes the ActiveX Objects to .NET. I would spend some time learning how .NET does this. What I do create a dummy project and have .NET reference the ActiveX stuff I need. I then find the wrapper projects and DLL it made and move them into a central area. That why when I work on subsquent projects using the same ActiveX stuff I know where all the wrappers are.
You have to go to your class library properties and select the option "Register for COM interop". This will make your assembly available to COM.
You want to create what's called a COM Callable Wrapper (aka CCW) for your .NET component. This basically entails setting up some COM interfaces with some GUIDs and either enabling "Register for COM Interop" in the project properties (as mentioned) or using regasm.exe.