-2

I consider myself to be quite a competent Excel VBA programmer. Over a few years of my professional finance career I created quite a lot of useful procedures (UDF's, some small or big apps with multiple user-forms and a lot of small, easy to do stuff).

I decided that I will take a step forward and try to monetize my work. I have looked at VBA obfuscators, VBA compilers and stuff like that but sadly, the protection from obfuscators seems to be weak (at least I think so, I cannot comment as I know only VBA language, I am not master in computer science) or in case of compilators, compilation modifies my code so much, that 1/3 of it is not working properly (I have tried to debug it, but no matter what I do it does not work).

I checked the amount of code I have and it is about 13-14 thousand lines. Now - is it worth or even possible for me to translate all that stuff into VB.NET or C# starting from scratch? I have no experience with any of them, I have programmed only in VBA. I have been reading and it seems like it is nearly impossible to convert and re-write the code due to differences in user-forms, no UDF's, which I use in my subroutines and stuff like that. If it is possible, can someone point me in the right direction, what would be a better choice?

I am quite lost at the moment, as I have no experience and I know no developer who could "guide" me into this or that direction. What would be a good way to "translate" my VBA code and make a working app from it? I know it is not easy, but if it will take me a few months of after-hours work, I will do it. The thing is that I do not want to completely waste the time and I want to do it right.

Thank you kindly for all ideas and your help. I hope my message is not completely off-topic.

Kashing
  • 1
  • 1
  • 1
    I wouldn't throw away my VBA code. I decided a long time ago the c# Interop is slow and cumbersome. And requires different versions of the Interop depending on the version of Word you are using. The Interop uses a scripting language as the interface that requires Excel to parse a text language. So when reading and writing cell values I use an ole connection string in c# as interface.Whenever I have to do anything more complicated I still use VBA which is very efficient in most cases. There are still things that cannot be automated even with VBAI've never uses OPEN XML which is an option. – jdweng May 23 '20 at 18:19
  • this might be useful https://stackoverflow.com/questions/4927487/disadvantages-of-bigger-project-in-vba – rustyBucketBay May 23 '20 at 21:16

1 Answers1

1

It feels like an of topic question because it can't be factually answered; we can only give you our opinion for the most part. I'll pick out those parts that can be answered with facts:

Now - is it worth or even possible for me to translate all that stuff into VB.NET or C# starting from scratch?

Worth, I can't answer. Value is contextual - look at the number of people who get a kick out of providing stuff for free.

Possible; certainly. Your VBA code encapsulates a process, a notion, it does useful work and makes your life easier. It could make someone else's life easier too; would they pay you to make their life easier? Would they be able to integrate your work into theirs? Do you know how to make your work available to them in a way that means that they can actually use it?

You can put all this stuff into .NET, but don't think it makes it any harder to reverse engineer your work. If you want your stuff to be immune to reverse engineering, sell the data processing it does rather than selling the code. Create a webservice that calculates all the things people want, don't sell them a DLL that they could integrate and use but then their kid could decompile and release as a rival offering. That's not to say that this happens in business as much - businesses tend to be staffed with conscientious types that recognise when they license someone's work and use it, if they just ripped it and took it for free they would be stabbing one of their own in the back. If you're creating components for businesses to license and use, you'll probably have fewer piracy problems than shareware type licensing to end home users. But you can probably still sell the processing as a service rather than the software as a thing..

impossible to convert and re-write the code due to differences in user-forms, no UDF's, which I use in my subroutines and stuff like that

It might well be impossible to drop your code into something .netty, press play and have it working in an hour.. But I didn't think we were doing that. I thought we were re-implementing the process/software in .NET. Maybe whatever you pick doesn't have some blah UDF (user defined function?) this, or input box that - but at the end of it all, those things do some simple job and you can use something else in .NET that does that simple job. If anyone told me "seriously, there are things you can do in VBA that are flat out impossible in C#" I'd laugh for a while, then go back to playing javascript quake

14 thousand lines isn't an overbearing amount of code that you couldn't just sit down and start bashing it out in the evenings, and probably have reimplemented it all in something else in about a month - you already know what you want the code to do, so the hard part is getting info on how you do that in (your chosen language) - it's on topic for SO though, so fee free to search and ask how to translate various bits of VBA to C# etc.. People won't take kindly to questions that are a dump of 500 lines of VBA and a "can someone translate this to C# for me" though

Caius Jard
  • 72,509
  • 5
  • 49
  • 80