I need your help in deciding the best strategy and technology to choose from for the continuing development of a successful in-house VBA application.
In our company (a web-based distributor of financial information), over the years, we have developed a VBA XLA Add-in application for use only inside our company, which helps in the linking of our database of financial information with Excel worksheets, through the use of several UDF's, supported by ADO/SQL and other business objects logic. This app became a solid, fast, and useful tool for us, somewhat similar to old DDE links, but much more sophisticated and flexible than that.
Recently we replaced the ADO/SQL portion of the system with a SOAP based Web-Service and XMLHTTP MSXML 6.0 technology, literally putting our database into the cloud. The goal was to transform the application into a product which could be used outside of our company. That work is already done, and its behaving quite well, with all functionality, load at startup, user authentication and session control login/logout, seamless integration with EXCEL, user-friendly messages, all done in a single 2.036Kb XLA Add-In file, spanning more than 15.000 lines of good VBA code. However, we feel that it cannot yet be distributed like it is...
We feel that in order to be successfully published as a product to our clients, this application must be transformed into compiled code instead of the interpreted VBA. There are many reasons to justify doing that, including security, speed, robustness, etc.. but we don't need to go into these details right now.
Our fist thought was to use VB6 and Automation Designers to quickly transform our VBA code into a VB6 Automation Add-in. Apart from the fact that VB6 is old technology, it seems that Automation Add-in's are not the ideal solution, for our app requires some interaction with Excel events and the End-User, at least during the "login" and "logout" into the web-service based database (and some other functionality that requires user interaction through forms), BUT is seems that Automation Add-ins are not suitable to anything other than UDF's only. Here we would like to learn about other's experiences with Automation Add-ins and end-user interaction.
So, COM Add-in's are the next option. Again, these allow interaction through menu buttons and commands, but do not allow UDF's in the worksheets. Or so we've read. Also, we have read that COM Add-ins can be made as Automation Add-ins (allowing UDF's after all), but that they will work as two separate entities inside the Excel environment (one COM and one Add-In), one half not communicating with the other. That's not acceptable to us. Again, we'd like to learn more about other's experiences in that regard.
Then there is Managed Code (.NET, Interop, and VSTO) as other viable options. However, while simple to get started with, it is not clear that Interop came to stay, and it is not clear what is the best strategy with managed code. Again, we'd like to learn about other's experiences in this realm.
So, the questions final is: given our requirements (i.e., load at startup, access to data through SOAP based web-service (MSXML 6.0), UDF's functions, login/logout session control, user-friendly error handling, etc.), and the fact that we already have 15.000 lines of good VBA code, which is the best technology for us to continue to develop this Excel component, in order to make it into an easily and safely distributable product? All comments and thoughts in that regard are very welcome.
I would take a look at Excel DNA: https://github.com/Excel-DNA
I had a very similar problem developing a VBA add-in that communicates with an ASP.Net Web API. Couldn't really give all the code out in VBA, so we needed a way of giving out compiled code. Connecting to the web service was freezing up excel making it harder for users working with massive spreadsheets with multiple API calls.
You can develop them in visual studios easily using VB so a lot of the code could just be copied and pasted over then changed slightly to fit the later version of VB you're using.
Add-ins compile to .xll 64-bit and 32-bit versions.
We handle all login and connection to the API in the Ribbon: https://exceldna.codeplex.com/wikipage?title=Ribbon%20Customization&referringTitle=Documentation
And you can use newer VB forms which are more user-friendly.
Connect to other .dll files for sharing logic across multiple add-ins.
The UDF we use which call the API can all run asynchronously freeing up Excels main thread.
https://exceldna.codeplex.com/wikipage?title=Asynchronous%20Functions&referringTitle=Documentation
It can run any VBA specific or CAPI code by queuing as a macro.
Pretty much do everything that you could do in VBA plus more.
Govert the Developer https://stackoverflow.com/users/44264/govert is very active on StackOverflow and forums. He's helped us out loads in the development. And Excel DNA is still being updated and worked on.
Let me know if you want some more details.
great summary of your project.
I'm also curious what other thinks about the "right" solution for such task. It won't be an easy decision though.
My short answer will be "stick with VBA" unless you are really concerned about stealing your code from the great VBA add-in.
The reason I'd go for VBA is that the longer I've been working with VSTO/COM the better I've found VBA to be the best for handling tasks that are closely related to Excel (understand MS Office) object model. I'm saying that even I have written almost zero lines of VBA code in last 4 years. I do understand that you are using webservices and other dependencies but I'd say that if you have good progress and the add-in is working as expected I'd NOT throw myself to a completely new world of development (VSTO & C#) just to be cool, you will gain not too much value of this, especially if you know that
deploying managed code is harder that just copy your add-in to a
folder, set registry, done
troubleshooting is a way harder with managed code, basically you will have to log much more and trying to reproduce issues that may not happen in your environment but happens in clients
re-engineering of managed code is not such hard so if people really wants to steal your code they can do that unless you use obfuscation
and the last and probably the most important for you as much as I'm aware there is no easy way to do UDFs in VSTO
I have very minimal experience with VB6/ COM Automation so I'd love to hear opinion of guys who have done something similar before
Re: the VSTO & UDF, at my job, we have a VSTO add-in that somehow handles UDFs for a large project. I'm not the main developer of the application but I believe we use Excel DNA there so do check it to explore the managed code option further
Hope that helps
I'm using VB.net so keep that in mind.
I'm trying to create a program that is highly edible. Users will be able to change multiple things by just replacing the existing dlls. Kind of like a modding ability.
The new DLL shouldn't have to recreate every function though, it should only include the ones that it changes and then hook to the old dll for anything that it doesn't have. Is there a way to dynamically do this? Reference another dll (like a proxy) through yourself for anything that doesn't exist in its self?
Sorry if that is confusing. If it still confuses people, I'll draw a picture later =)
I'm Sorry, but it must be done this way. I have already set up everything in the manor and told clients (they have already started developing).
Sounds like you want to write a plugin architecture into your application, why re-invent the wheel, take a look at the Managed Extensibility Framework
I would like to access a WCF service through VBA functions/macros in Excel (2007 or 2010).
It seems there are a number of possibilities, each with its own particular shortcomings. ...
Microsoft SOAP Toolkit
WCF Service Moniker
COM Interop
VSTO
Excel-DNA
Can anyone advise on the best way of doing this?
I don't think there is a clear-cut answer to your question; it depends a bit on what you want to do with the data returned from the service, how you intend to deploy your solution, and how much is done with VBA, as opposed to .NET.
My gut feeling is that VSTO is probably right, because it gives you a full-fledged .NET project, which will likely be the most convenient to handle the WCF services. Assuming that what you are trying to do is retrieve data and give your user choices as to what to pull and how to display it, you can then build a user interface for it (maybe in a task pane), and write the results to Excel, while writing code in Visual Studio.
However, you mentioned VBA, and I am not quite sure how much you want to use it. I found ExcelDNA to be easier to use if what you want to do is create a VBA user-defined function which calls a .NET dll. If VBA is what you want to focus on, this may be the way to go.
Hope this helps!
I am currently involved in porting a large and complicated VBA application to .NET 4.0.
In .NET I have access to the Profiling API, which I have used to instrument an assembly to extract information about when classes are constructed, methods called, etc.
Is there an equivalent for VBA? That is, some sort of callback system so I can write code which will be notified of events within VBA code as it executes? I've spent some time on Google and contacted several VBA gurus, but to no avail.
A similar question didn't turn up much except a suggestion for a trial version.
This profiler looks free and still available.
You could also search for VB6 Profilers which should also do the job.
Is there a method for handling errors from COM objects in RDML? For instance, when calling Word VBA methods like PasteSpecial, an error is returned and the LANSA application crashes. I cannot find anything in the documentation to allow handling of these errors.
Actually, error handling in general is a weak-point for LANSA and RDML, but that's another topic.
I know almost nothing about LANSA etc. A few minutes in Google convinced me that error handling is, as you say, not a strong point. Over on the lansa.us site there is this article about remote debugging which, at a stretch, might be going in the right direction.
One wonders if a DEF_BREAK would work. Here's a longish post about using DEF_BREAK. If DEF_BREAK hooks in with #COM_* functions, that might be a possibility. Please pardon my naivety in this regard.
I also found some code at the LANSA Tech Exchange. I had hoped that there'd be something obvious, but no. Being more LANSA-aware than me, you may find something.
At my company, we were able to handle Communication API's through the ActiveX part of LANSA. The supplier embedded his API's in an ActiveX component. We used this component in our LANSA application. This works fine and stable.
Maybe you could embed the Microsoft API's in an ActiveX component too? I don't know from the top of my head if Microsoft Word can be addressed as an ActiveX component.