I have acces file with forms that create excel file with multiple spreadsheets and I have a task that converts it to C# application that do the same thing the VBA code do and it has alot of code
Can I convert the VBA code to (e.g .dll file) that enable me to use the VBA methods in C# or anyway to use VBA code in C# instead of convert it ?
Thanks,
Mohammed Thabet Zaky
http://thabettech.blogspot.com/
If you want to do it yourself, it is possible to just reference the COM stuff. I did this with another application that utilized VBA (AutoCAD). What we ended up doing was creating a .net class that referenced the COM interop and then copied all of the code into that project. This is how we created the .dll file. Then we slowly refactored the vba code into C#.
The copy and paste isn't completely seemless. You do need to make some adjustments. For example thisworkbook, activesheet, and all of those items that are referenced automatically don't work automatically (because you are not out of Excel's process). But (at least for us) it was better than completely re-creating the logic.
Here is a link to some reference material - http://au.autodesk.com/?nd=e_class&session_id=5084. It references Autocad, but doing it in Excel would be very similar.
Hope this helps.
You may have success with the VB Migration Partner, even though it was designed for Visual Basic applications, not office. At least in terms of syntactic migration from VBA to C# it could help.
Related
My Excel can download data from a data provider via an AddIn.
From the help pages of the provider, I found out (and tested) that it is possible to "Refresh" the data by calling the following command in VBA:
Application.COMAddIns("PowerlinkCOMAddIn.COMAddIn").Object.RefreshWorkbook
After spending a couple of hours searching on the internet I couldn't find an answer on how I can call exactly the same method by using C#.
As I have many of these spreadsheets that need to be updated regularly, I am trying to automate the process.
One way to probably achieve this would be to inject a new macro every time I open the spreadsheets with the above command and call it, but I would prefer calling it directly with C# if possible.
A second solution would be to use Python or another language to
download the data in CSV format and link my spreadsheets to the CSVs
but this process also seems an overkill.
Many thanks in advance.
You can use the late-biding technology (Reflection in .net) for calling methods and properties without casting an object to the actual type, see Type.InvokeMember for more information.
Application.COMAddIns("PowerlinkCOMAddIn.COMAddIn").Object.GetType().InvokeMember("RefreshWorkbook" ...
Also you may find the HowTo: Communicate with a COM add-in from a standalone application article helpful. A sample code in C# is included.
I'm currently developing a C # application which currently uses a VBA macro in an Excel perform data extractions.
The Excel file is essential to achieve the extraction of data and this file will be located on the customer's computer. As this code is private content and has an intellectual property law, I wanted to know how I can deploy to my customers VBA code while protecting the code?
I heard about VSTO, is it possible to run VBA code from a VSTO plugin? It is correct security level?
Thank you
If your going to create a VSTO plug in then why is the VBA needed? You can just manipulate the data directly from your C# code as per the following link:
https://msdn.microsoft.com/en-us/library/cc668205.aspx
If the point of the application is to export data from the database, why not use a library such as EPPlus and just export the code from an external application? Again, no VBA code for someone to potentially see.
Either way, your code is not in the public domain of a standard user. If your really concerned about your code being high jacked, it is worth reading up on Obfuscation too
I wanted to know how I can deploy to my customers VBA code while
protecting the code?
Excel provides a mechanism to lock access to the macro source code any workbook which I assume you know about. E.g. see here.
I heard about VSTO, is it possible to run VBA code from a VSTO plugin?
Yes
It is correct security level?
The VBA security has nothing to do with how you call it. If a macro is protected than it will stay protected no matter how you call it. To say it another way, calling a macro from VSTO does not protect it in any way.
If you want to "hide" a function from the user simply protect the project and mark the function as private. But even if the function is public the user can't see the source.
I have a problem/question with some basic stuff.
I have interoptoolkit v2.1 installed and I am trying to create this form in vs 2008 with C# so this form can be accessed from a vb6 application.
I am trying to add a public property on this form, so I am thinking I am supposed to add this
[interopformproperty] above the property.
But when I do this and try to generate the wrapper using the option under Tools menu, it doesn't generate the wrapper.
I obviously searched google for a while but I couldn't find something particularly helpful.
So if you know anything about this, please give us hand.
Thanks a lot in advance. Cheers.
If the com visible type implements an interace, all the public methods, properties are com visible, provided that the types uses in their signatures are com visible. If the com visible type implements multiple interfaces, the first one (in the class definition) is used as the com interface. This behavior can be changed using the ComDefaultInterfaceAttibute.
If an interface is not implemented, all the public properties (that expose a com visible type) are automatically com visible.
regasm automatically generates a com inteface, containing all public methods/propties.
"Generating a wrapper" as you say... I don't understand this.
After compiling an assembly with com visible types register it using regasm (if the option in project properties "Register for COM interop is not active).
I always end up answering my own question :D
I am doing this just in case someone else get on this.
Go to this link and download the 2nd file.
C_Interop_Form.aspx">http://www.codeproject.com/KB/dotnet/VB6_-C_Interop_Form.aspx
Assuming you are using vs2008. Get the dll file, and the add in file.
and copy this file into My documents -> visual studio 2008>addins
Open up the addin file with notepad, and change the version number 8.0 -> *
Now save it. and reload vs2008. It should generate the wrapper file in C# instead of vb.
P.S, reading the comment of the post always helps :D
I have an assignment which is to import mpp file into database via ASP.NET (C#).
Can anyone please advice me on this matter.
Any help is very much appreciated.
Thanks.
Depending on the situation, using Interop isn't necessarily a good choice (have to have Project installed on the machine).
You can use MPXJ to open the mpp file and read the information in it. It's free and open-source and works fairly well, though since it's a port from Java, you have to do some things in a Java way in your .NET code.
A paid option is ASPOSE.Tasks, which is a little nicer to use, but pretty expensive.
Project programmability is available in C# but docs are only available for VBA.
This should get you going - all the stuff that is available in VBA can be accessed from C# using the Project Primary Interop Assembly from the list here.
Check out Application.FileSaveAs.
We had a bit of a problem where we have lost some source code for a very old ActiveX component we had. We've got a Delphi7 program that calls the Active X component. Thats a bit of a moster and can't be changed too much. However, some of the functionality in the Active X component needs to be updated. Since we've been moving our apps to C#, its been decided to redo the ActiveX as a C# class library.
I've got a basic C# class library working to prove the concept. I can hack the GUIDs and registry so it just looks liek the old one. If I look at the type lib for the old one and the new one, they are basically the same. Couple of slight differences but not anything i would have thought would be a problem.
Now as far as I can see there are three ways to use the new class library:
Late binding by looking up the ProgId. This works ok.
Import the type library. (Project| Import Type Library) This works ok.
Import as an ActiveX component. This generates a tlb file. This doesn't work. When I go to create the component I get 'No such interface exists'. The class is loading to a point but not completely.
Now unfortunately, the Delphi program is using option 3. So I have to try to get my class library working in this circumstance. Any ideas how I get past that error? I googled and found some references but nothing that says what the problem is.
Second question. I should know how to do this since I've done it once but I seemed to have fluked it. When I am in Delphi I do an Import ActiveX component to generate a TLB file. Now the first C# class library generated is showing up in the list of ActiveX controls and I can Create Unit for it. But I've created another simplier class library for testign purposes and damned if I can get the library to show in the list of ActiveX controls and so I can't import it.
The Create Unit for the Active X component generates a different format of TLB.pas to the Import Type Library format and its the ActiveX one that I require.
An ActiveX Control does way more then just implementing your interfaces. It is more like an TComponent or TWinControl. It requires you to implement a lot more ActiveX Control interfaces. Your C# object exposed through COM/ActiveX is not a Control, but a simple class.
It does not show up in Import ActiveX Control since it is not an ActiveX Control. I do not think it is feasible to make your C# class an Active Control.
Another possibility, although probably not the most elegant, would be to create a new ActiveX com object in Delphi which in turn calls your C# class by either method which you already have working.
Since you stated that this is for an existing Delphi 7 application, you might want to just use Com Interop on the C# side, expose the object as com visible, and the consume it directly from your Delphi 7 application.
The first option would probably allow you to get by with minimal changes to your existing application, but does add an additional layer that most likely is not necessary.