XLA vs COM vs Automation vs Managed-Code Add-in -
i need in deciding best strategy , technology choose continuing development of successful in-house vba application.
in our company (a web-based distributor of financial information), on years, have developed vba xla add-in application use inside our company, helps in linking of our database of financial information excel worksheets, through use of several udf's, supported ado/sql , other business objects logic. app became solid, fast, , useful tool us, similar old dde links, more sophisticated , flexible that.
recently replaced ado/sql portion of system soap based web-service , xmlhttp msxml 6.0 technology, literally putting our database cloud. goal transform application product used outside of our company. work done, , behaving quite well, functionality, load @ startup, user authentication , session control login/logout, seamless integration excel, user-friendly messages, done in single 2.036kb xla add-in file, spanning more 15.000 lines of vba code. however, feel cannot yet distributed is...
we feel in order published product our clients, application must transformed compiled code instead of interpreted vba. there many reasons justify doing that, including security, speed, robustness, etc.. don't need go these details right now.
our fist thought use vb6 , automation designers transform our vba code vb6 automation add-in. apart fact vb6 old technology, seems automation add-in's not ideal solution, our app requires interaction excel events , end-user, @ least during "login" , "logout" web-service based database (and other functionality requires user interaction through forms), seems automation add-ins not suitable other udf's only. here learn other's experiences automation add-ins , end-user interaction.
so, com add-in's next option. again, these allow interaction through menu buttons , commands, not allow udf's in worksheets. or we've read. also, have read com add-ins can made automation add-ins (allowing udf's after all), work 2 separate entities inside excel environment (one com , 1 add-in), 1 half not communicating other. that's not acceptable us. again, we'd learn more other's experiences in regard.
then there managed code (.net, interop, , vsto) other viable options. however, while simple started with, not clear interop came stay, , not clear best strategy managed code. again, we'd learn other's experiences in realm.
so, questions final is: given our requirements (i.e., load @ startup, access data through soap based web-service (msxml 6.0), udf's functions, login/logout session control, user-friendly error handling, etc.), , fact have 15.000 lines of vba code, best technology continue develop excel component, in order make , safely distributable product? comments , thoughts in regard welcome.
great summary of project.
i'm curious other thinks "right" solution such task. won't easy decision though.
my short answer "stick vba" unless concerned stealing code great vba add-in.
the reason i'd go vba longer i've been working vsto/com better i've found vba best handling tasks closely related excel (understand ms office) object model. i'm saying have written 0 lines of vba code in last 4 years. understand using webservices , other dependencies i'd if have progress , add-in working expected i'd not throw myself new world of development (vsto & c#) cool, gain not value of this, if know that
- deploying managed code harder copy add-in folder, set registry, done
- troubleshooting way harder managed code, have log more , trying reproduce issues may not happen in environment happens in clients
- re-engineering of managed code not such hard if people wants steal code can unless use obfuscation
- and last , important you as i'm aware there no easy way udfs in vsto
i have minimal experience vb6/ com automation i'd love hear opinion of guys have done similar before
re: vsto & udf, @ job, have vsto add-in somehow handles udfs large project. i'm not main developer of application believe use excel dna there check explore managed code option further
hope helps
Comments
Post a Comment