I am trying to write a program that modifies Office files (word, excel) programmatically using C#. Before continuing with my project, I would like to know if the COM Interop can be used in OSX by utilizing Wine, and if so, can this be done in Linux as well?
Related
I have one native shim add-in project including C# class libraries.
Add-in works fine in windows OS (By using WIX).
Is it possible to load this add-in on outlook of MacOS?
If so, How can i do that ?
Is it possible to load this add-in on outlook of MacOS?
No, it is not possible. There is no COM technology available on other platforms. COM add-ins can be run on Windows only.
If so, How can i do that ?
There is no way to port an existing solution. You may consider developing a web-based Office add-in to support multiple platforms and devices. See Build your first Outlook add-in to get started quickly.
I am developing a winform desktop application that uses the Microsoft.Office.Interop.Excel library for processing Excel files.
I have included this file in the References section of my program, but when I build it as an exe and send it to another user's computer, they are required to download a Microsoft driver in order to use the Excel integration features.
How can I include the dll when I build my program, so that my users don't need to download and install a separate driver?
Updated to add:
My users all have Microsoft Excel installed on their computers, so this is a different issue than the related question.
Here is the error message the user receives:
As i remember Microsoft.Office.Interop.Excel requires Microsoft Office to be installed on your target machine. I recommend you to use ExcelDataReader which allows you to work with Excel workbooks and does not require any additional drivers etc. Check it out!
I'm developing a Windows Application using C#. I wanted to run a .sys file (driver basically) at the backEnd as my Code makes use of certain functions to implement the output.
How can i write a code in C# ? If the .sys file is placed in "Bin" folder, it just does not run as I guess it can be made to run as a service.
Consider the name - "someDriver.sys" (I'm using Win7 OS here)
Can I run this .sys file as Service in Kernel mode?
My application is a very simple one and does not have installer (I do not want to have it too). Can you pl help how I can tackle this situation where I need the presence of .sys file for my functions to work.
Have you tried to see how it's done in this article How to install driver dynamically or install driver as a service for Windows
You must adapt calls using interop.
Use this tools to help you in Interop definition : PInvoke Interop Assistant
You can use the code from this answer and just change SERVICE_WIN32_OWN_PROCESS to SERVICE_KERNEL_DRIVER (0x00000001). Then you can just do
ServiceInsatller.InstallAndStart("yourServiceName", "Some Description", "C:\path\to\driver.sys");
This works for me.
I need to write a plug-in for a MFC application:
- plug-in is deployed as dll.
- On the runtime, the MFC application will call the plugin and the plugin shows a custom dialog.
- the dll needs to be dynamically loaded, the MFC application should not be re-complied if the dll is updated.
I mainly code in .net and after playing with MFC, everything just seems too odd for me (no events/delegates etc). I'm fine to write a MFC dll but if I can do that in .net then I'll willing to give it a try. A possible solution is that I can write a C# dll and expose it as COM. Since I don't know anything about COM, here are my questions:
- Does the .net framework needs to be installed on client's machine?
- Can COM be dynamically loaded from a MFC application?
- I read something about registering the assembly with COM, does this happen on client's machine? (if yes, then the installer might need to be updated)
- Is it easy to use COM in a MFC application (this requires MFC devs to modify their code)
Or, given if there is too much effort to make the connection between .net, COM and MFC, would you suggest me to code in MFC? Thanks.
UPDATE:
I decide to use C++/CLI as a bridge between MFC and .Net. A mixed C++/CLI dll can be called from MFC application and the dll can utilize .net framework. Thus I can code the UI with C# in another dll and that dll can be called by C++/CLI.
References:
Native and .NET Interoperability
Integrate Windows Forms Into Your MFC Applications Through C++ Interop
Does the .net framework needs to be installed on client's machine?
Yes the frame work must be installed on the client's machine
Can COM be dynamically loaded from a MFC application?
It can, the MFC application will load your DLL dynamically, it can call it without being updated as long as your class's public interface doesn't change
I read something about registering the assembly with COM, does this happen on client's machine? (if yes, then the installer might need to be updated)
Yes the .NET COM object (or any COM object for that matter) must be registered on the client's machine. You can use the building setup project in Visual Studio do to that
Is it easy to use COM in a MFC application (this requires MFC devs to modify their code)
It should be reasonably easy, but that's more a question for the MFC dev's
Would you suggest me to code in MFC
Do you know C++ or MFC? If not it's probably a lot more work.
Another option would be to write the component in C++/CLR. It can expose unmanned functions/classes which would be directly callable from the MFC application.
I am creating an app in C# using the .NET COM Primary Interop Assemblies. I was wondering if this will be able to open and read files from both Project 2003 and Project 2007. Also, does Project have to be installe don the computer that is running this app?
That's Yes and Yes. You'll have to use the 2003 PIA, Office versions beyond this are backwards compatible with older COM interface specifications. But of course you won't be able to use 2007 specific features. You can't do anything with Project if it isn't installed on the machine. Project 2003 isn't likely to be able to read Project 2007 files unless the file was saved in 2003 format. No problem the other way around.