I am currently porting a legacy VBA application to a .Net application. During this process the users of the existing VBA application need to have some features added. So instead of coding them in VBA & then later in C#, I’ve wrote the new functionality in C# and I want to expose this to the existing VBA application through COM, as well as also keeping it in the currently .Net application version.
The solution contain several projects, 1 project for the UI, 1 project for Business Logic, 1 project for the data access layer.
The new features are just a some new forms to modify data. So ideally they will click on a form command button in access which lunch these C# forms via COM interop.
How should I go about exposing this forms through COM Interop.
What I was hoping to do was just add another project, MyProject.COM, which will contain my Interface ICOMManager, for exposing methods to access to launch the required forms. My COMManager class will just instantiate the required forms in my .net application and show them.
This project MyProject.COM will have references to the UI layer & Business Logic Layers.
When I want to register this project using REGASM how will I include references to these other projects?
Thanks for any help or advice on how about doing this.
Ah ok so i see this is alot easier than i thought.
Once i looked at the reg file produced by regasm i could see that the tlb (Type Library) is just a pointer to where it can find the libraries to execute the .Net component.
So once i register the tlb and make sure its pointed to the install directory where the rest of the project files are located it works.
Related
I'm using Visual Studio 2015. I have successfully created a class library and selected:
Register form COM Interop
Make Assembly COM-visible
I've then managed to deploy this using a Setup Project to other users and it works great (although still don't understand why Intellisense doesn't work for it)
Now I'm trying to do the same for a WinForms application, but
Register form COM Interop
is not viable to apply, it's grayed out - should it be? And if so, why can't I register an application for COM Interop so I can manipulate it in other apps? (e.g. in Excel VBA)
The problem is that com registration normally makes only sense for assemblies (.dlls) and your WinForm application is normally a executable (.exe).
So I this case you should create a dll and move all the functions and classes that should be com visible into this assembly. Than make it Com visible and use it also from your executbale WinForms application.
To register a .NET assembly for COM Interop, the assembly has to be a class library, which is intended to be shared by applications.
A WinForms application, on the other hand, runs as a standalone program is not intended to be shared by other applications.
In this case, you can create a class library project, and creates a WinForms UserControl in the project, and expose the UserControl to other apps by making it COM visible.
Here is an old example, strangely it is hard to find more recent examples in my search.
Is it possible to create an VSTO add in for multible office applications?
Can I outsource the functions i want to have for every application and then create an Add-in for every application? If yes, is there a better way to achieve this?
I recommend making a solution with an add-in project for each Office application.
Then add a class library project to the solution and reference that from each of the add-on projects.
That way you can centralize code used in all add-ins.
If you need to interact with the active application or document, you can detect the type of the calling object and typecast it to the relevant application/document type.
Yes - you can just put your common functions into a shared DLL, just like any other application. Since each VSTO project targets a different application structure and potentially UI paradigm, I'd recommend having different VSTO projects in a single solution, and a shared assembly holding the common code.
VSTO doesn't support creating multi-host add-ins. You need to create separate projects for each host and use a class library for the shared code base.
Note, Add-in Express allows creating multi-host COM add-ins. So, a single add-in project can be run in multiple hosts. It comes from the IDTExtensibility2 interface. I don't know why VSTO creators didn't provide such feature to developers.
VSTO itself doesn't provide such an option. If you want to get single project for all application you can use shim add-in. That makes possible to run add-in in all applications from the same dll. The only issue -- your code need to handle what application started to call it to run separate logic or to call specific office API functions.
I have a c# application that does all kinds of automation stuff based on voice commands.
I want other users to be able to develop plugins that can add additional functionality.
If the users create a new project for a plugin, is there a way to have it reference all the dlls that the main application references?
We're developing a ClickOnce application with a mixture of .NET components and legacy C++ COM components.
Currently we're adding the C++ COM components to the user's machine using an MSI (this is a prerequisite to installing our ClickOnce app) which means we can register the COM objects on the user's machine beforehand.
We can still push out updates to the rest of the application written in C# via ClickOnce, but updating the components installed by the MSI requires manual intervention.
However, we are trying to figure out if it is possible to install the C++ COM components via registration free COM, i.e. they're all in the same directory, and each component has a manifest file specifying the clsid for each COM object and interface. This would mean we can get rid of the MSI entirely.
This link has been a good introduction to the topic.
I've been able to get a .NET component to load a C++ COM object, but not the other way around.
Does anyone know if this is possible?
Yes, that's possible. You'll need to use the <clrClass> element in the manifest. There's a decent how-to located here. The SDK docs are otherwise pretty miserable, you'll need Junfeng Zhang's blog to get better background info.
I have an MFC application to run on mobile device. Now this appliation code need to be reused from C#.
I am trying to create wrappers, dll, and import this dll from c#.
Problem being faced is , my project is not a class library. So i created another MFC class library - (MFC-Shared dll) in the same solution and tried to create wrapper functions in this library . But i am not able to create any objects or access any functions of my application from this library even after adding reference.
Is there any way to access my application code from this library.
Please help
I suggest splitting some of that code into a C++ DLL (not a class library) and then using DllImport attributes in C# to access those functions (see http://msdn.microsoft.com/en-us/library/26thfadc.aspx). You can then still use that DLL in your MFC application by adding a project dependency (add both projects to the same solution first). This way a lib wrapper is automatically created and linked to the MFC application.
A different solution (but probably even more work) is to do Inter Process Communication between your MFC application and a C# client by opening a Named Pipe or a TCP Socket. As protocol you can either create your own (like we did at our company) or go for something like XML-RPC, SOAP, etc. As an example you could try to get gSOAP to work in your MFC server, then define a WSDL file and have the C# client code be autogenerated out of this by Visual Studio.
Another solution is to turn part of your MFC application into a COM DLL. Then both the MFC and the C# clients can use it. But I don't think this solution adds anything more than the 'normal' DLL solution.
Sorry, but I don't know of an easy solution (or at least one that doesn't take a non trivial amount of work).