When to move from VBA to .NET

[Viper15]

I'm sure this has been discussed many times before across the internet, however most of recent searches have turned up articles from 2 to 12 years ago so I'm posting here to get your feedback. I started learning VBA about a year ago and recently completed a rather larger project in Excel and I'm starting to think it would have been easier (and better) to have built it in VB.NET.

Just a little background on the project, first and foremost it was made to look and operator as if it's not in Excel, meaning that all of toolbars are hidden leaving just the window frame and spreadsheet, a clean UI was created by creating png images to use as buttons throughout, and even a splash screen was created with a custom logo. The project itself has a couple of sheets that are metrics dashboards with charts tied to slicers, where the user can right click the chart and export it to Word, Excel or PPT. A couple sheets that are project dashboards, consisting of department headers that expand when clicked to unhide rows below it displaying projects. Users can click on the project row which then opens another window with all of the details that is exportable as well. In addition to this there a report generator that creates various company reports in both Word and PPT formats. Lastly, to get all of this data into Excel there is an upload procedure (actually 2, one for each data stream) that cleans, standardizes, and writes the data into an Access database that I'm using as the backend for the project.

This entire thing took me about 5 months to build (while learning at the same time), but given the size of this project hopefully you can see why I'm second guessing if VBA was the right way to go about it. We also have a couple other similar sized projects that we're scoping so any input/thoughts/suggestions on whether development would be better off in VB.NET vs VBA would be appreciated.

 

[mole999]

I don't know anything about .NET, beyond that it exists. If I had to deliver a new project quickly I would work within what I know and have learned. If however the time is a available then learn the new one, It'll improve your scope, if it becomes unachievable, you have the fall back root

 

[Viper15]

Makes sense @mole999. Curious if anyone else in here has had experience with .NET and when might a project be better suited for that type of environment.

 

[Joe4]

I have gotten into VB.NET over the past few years. It certainly is powerful, but there is also a ton of stuff to learn. It uses Object Oriented Programming, and that was one of the biggest differences from the way most people use VBA. Just a very different way of approaching things. So, it really isn't one of those things you can just expect to pick up and master in a short period of time.

You can integrate it with other programs, which is good, because I am not sure if it could do advanced Excel things like charts and slicers on its own.

Most people I know who know both seems to lean towards VB.Net, all else equal.

 

[Smitty]

Welcome to the Board!

Starting with VSTO, Microsoft built in the ability to build Excel features into .NET apps, and now it's native (they realized that people were trying to recreate Office functionality in earlier versions, so they exposed the object models). But it really depends on what you need to do. If you've already built in Excel, and it's stable and functional, then I'd probably stick to that unless you just want to experiment (which can be fun on its own). You might want to talk to your IS/IT department to see what they'll be willing to support. While some companies strictly prohibit VBA use and .NET apps created outside of IT/IS, most don't have a clue, so you'd definitely want to check.

HTH,

 

[Viper15]

Thanks for the feedback, it's much appreciated.