I am making an excel vba program which will be distributed accross my entire organization, to people I don't even know.
I have been building it with early binding everywhere to make the code more readable, enable intellisense and easier to write.
The side effect of this is, I am not sure my program will work on another computer.
How can I write code with early binding in a way that it will run everywhere without explaining to the user how to add the references for every single computer it will run on ?
Related
tl;dr - I'm attempting to open internal and external port 4305 to my local address at 192.168.1.103 through UPnP with Visual Basic code.
I've been searching for the better part of 20 hours looking for a way to open these ports on my router through UPnP code for VB. So far, nothing has enabled me to trigger a port through VB. To keep a long story short, I've attempted about 4.3 different options with varying success. These are:
Microsoft's Interop/COM NATUPnP Library (https://learn.microsoft.com/en-gb/previous-versions/windows/desktop/ics/network-address-translation-traversal-interfaces)
NetworkLight_VB (An old program I hoped I could use for reference, http://www.thijsschreijer.nl/blog/?p=450)
ManagedUPnP Library (This is the .3, I spent little time exploring this lib as it's C#, but still think it's worth mentioning, https://archive.codeplex.com/?p=managedupnp)
UPnPc/MiniUPnPc (http://miniupnp.free.fr/)
Portmapper (https://github.com/kaklakariada/portmapper)
NATUPnP 1.0 Type Library
Having a little prior knowledge with Interop services through excel based programs, this seemed like a pretty good solution, however it didn't get very far as the COM object NATUPNPLib.IStaticPortMappingCollection would always return as nothing. I imagine this would be due to NATUPNPLib.UPnPNAT also returning empty, despite Visual Studio showing it as an initialised COM object. With little info or guidance other than "Your UPnP is probably off" (It wasn't) I decided to see if there was another way, and moved on.
NetworkLight_VB
In an attempt to look for working examples of UPnP triggering through VB I quickly realised that this isn't a very hot topic and has barely been talked about in years, with this program being no exception. Opening the program it seemed to run fine, though I had no indication of it actually working as intended, with my router showing no UPnP activity on the port it was trying to hit. I believe there's still potential here with the library being used, but I'm not sure how to utilise it properly or reference it within my own program.
ManagedUPnP Library
This is the same as with the UPnP library used by the NetworkLight_VB program; not sure how to use it. (Being entirely self taught, my knowledge foundations are shaky at best. The only references I've used successfully are through Visual Studios 'add reference' option like with the NATUPnP Interop service)
UPnPc/MiniUPnPc
This showed a lot of promise as a potential workaround, allowing the use of a stealth CMD window to do the dirty work, but this also failed. The worst part is that I have no idea why. Running it seemed to work without issue, and it echoed a success in triggering UPnP, however my router told me otherwise. Checking the UPnP list showed no open port, and any attempt to communicate between my host and client programs failed.
By this point I was ready to just give up and port forward manually. Surely, if everything I was trying kept failing then there must be something wrong with my setup, computer, something that was misbehaving. But I gave it one more shot.
Portmapper
This nifty little java program worked like a charm. I entered the info, checked my router wizard and, lo and behold, there was the port sitting open and ready. Testing my client and host programs, I confirmed that it was working exactly the way I wanted it to. There was just one problem: getting it into my program. Browsing the author's website I found that it did in fact have a command line interface with examples, though my pitiful (and very tired) attempts to use that CLI didn't work. This shouldn't be too hard to work out though.
What does bother me however is that it needs Java installed on the computer to run, and since this is a peer-to-peer based program, replacing 'asking a user to port forward' with 'asking a user to install Java' is undesirable (Though, if all else fails, then so be it. Pressing install is far easier than navigating a router gateway wizard).
Ideally I would like to have the NATUPnP Interop service or any of the libraries work so that I'm not running code outside of the main program, but I really want this to work so anything that does is probably what I'll use.
Any guides on how to use the libraries, examples of working programs or suggestions on alternative methods is very much appreciated.
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 would like to subscribe to a RabbitMQ message queue from Excel 2013.
The ultimate aim is to allow data contained within a MQ message to be processed within Excel and to also allow Excel to send a formatted message via a RabbitMQ message queue.
Is this possible?
The message which is sent down the message queue is comprised of 7 fields, each field is delimited by a ; symbol - however the message is sent as one string over the message queue...
e.g. "text;number;number;number;text,text,timestamp"
I would like to be able to split the raw message as above, into formatted cells in Excel 2013.
Can this be done?
I have limited coding experience and I am trying to learn so please forgive me if this is a 'silly' question.
Any pointers will be much appreciated, for example can this be done via VBA code or an Excel Add-In?
Thanks in advance...
First, the bad news: there is no easy way to do this.
Now, the good news: if you really want to, you probably can do it, in at least two different ways.
Disclaimer I have not tested anything, cannot guarantee that it will work, and you (probably) will need to level up your coding skills to achieve what you want. These are just ideas that I would explore myself if I had requirements like yours, and should give you some pointers to get started. They're not necessarily good or functional.
There are various approaches to explore in order to achieve what you want:
Write an Excel addin in .NET to actually consume/publish to the queue. This may actually be the easiest solution, but it requires both Visual Studio and a bit of .NET knowledge. Some good resources to get started:
https://msdn.microsoft.com/en-us/library/bb157876.aspx and the always-so-good https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html .
Pros: probably the easiest solution
Cons: you'll probably end up with an addin tied to your current requirements, and will have to update your addin when specifications change
Leverage COM Interop in .NET to write a wrapper DLL around RabbitMQ's .NET client library. If you've never done .NET, this approach may not be appropriate, as it will involve marshalling datatypes and function pointers. Some more pointers if you choose this (difficult) path: Easiest way to make .NET DLL visible to COM?. You can then import your COM wrapper into any Excel/Office project by adding the generated DLL to your VBA project.
Pros: you can create a generic wrapper that exposes RabbitMQ to Excel VBA and reuse it in any other Excel based project
Cons: the learning curve will be steep.
Use the STOMP adapter on your RabbitMQ server (if you have that option available, which may or may not be possible depending on your setup/sys admin), and write your own implementation in VBA. This is a bit hardcore, but works without any .NET voodoo, but you will need a special ActiveX control called MSWINSCK.OCX, and some event handling. StackOverflow has a question with decent answers samples here: MSWinsock.Winsock event handling in VisualBasic
Pros: once again, you can create re-usable code (via a class that you can import in other projects)
Cons: you have to implement a protocol, and it depends on an ActiveX control. Also requires the use of a RabbitMQ adapter, which you may not be able to use in your context.
I'm sorry that I can't provide actual code showing how you'd go at any of this, but as you've probably guessed by now, all solutions imply a fair amount of work. So at least, you know where to look...
One of my customers asked us to develop a "VBA macro". However, in the 2010s, it seems weird to me to still use such outdated language, and I'm thinking about trying to convince the customer to use VSTO dev instead. However, as I'm new to both worlds, I need help to fill a pro/cons page to be able to argue this.
Of course, the answer can't come without the actual requirement, let me try to resume:
Target : Word 2003/2007 (but I'm suspecting 2010 as a not yet known requirement) edit 2010 requirement confirmed
An external publishing system requires .doc file as input. The .doc file must have some specific styles applied : "Custom Header 1", "Custom header 2", etc.
The user can build documents, using Word, using two possible ways:
Start the new document using a .dot file deployed on the computer
Transform any existing document to match the target template
Users can "apply" the styles "simply" (simple UI): context menu, styles menu, custom action pane, etc.
By now, I see the following pro/cons:
VBA
Pros:
?
quick and dirty development (quick part of the sentence)
The customer has already some in production macro
Cons:
hard to find skilled developer
quick and dirty development (dirty part of the sentence)
VSTO
Pros:
benefits of the .Net language (compiled, typed, rigorous, class library, etc.)
security model more flexible and powerful (trusting code signed with a trusted authority)
bridge to WPF panes possible
You work in Visual Studio and have access to its full set of features: refactoring, source control, etc.
Cons:
requires installation of the .Net framework (probably not an issue today) and VSTO runtime
harder to deploy
slightly more work at the start (but less in long term)
I am not familiar enough to .NET but here is my humble opinion about VBA:
VBA
Pros :
easy to deploy and to make it work with the Office apps
quick and dirty development (quick part of the sentence) - agreed
Cons :
hard to find skilled developer
hard to select a skilled developer and explain your customer he needs to invest in this skill
quick and dirty development (dirty part of the sentence) - partial agreement. It will be dirty if:
you give the project to a VBA beginner and don't frame him/her
your project gets too big in terms of requirements
requires to have the .Net framework installed (probably not an issue today) I don't think so (maybe a CONS of VSTO?)
I would say that if you only want to have some code or add-in to merge some syles, you could easily do it with VBA and it won't be dirty (unless you really want it to).
I'm answering myself to the question, as the project is finished.
I finally decided to write the application using a VBA macro. Here is the post-mortem conclusion of this choice :
Pros:
The team that will maintains the application has no C# knowledge, only VBA (main reason of my choice).
Poor security model : it's a pro because there is no other setup that putting the files in the right place.
No runtime prerequisites
Cons:
The deployment was supposed to be simple.
I was counting of the possibility to play with Word options "User-template directory" and "Startup template directory". But it wasn't possible, because the app is not related to a specific entity in the customer organisation. I wasn't allowed to "take ownership" of this settings for this application.
I ended in writing a custom NSIS script to deploy the application on the correct folders. With VSTO, a simple setup project (clickonce?) would have done the job.
The language is so prehistoric ! Collections index starts to 1, array to 0, no OOP, poor out-of-the box language and library feature. That is not always a problem, but in my case, modeling the business rule was a bit painful (representing hierarchical data in a tree was not an easy job)
Very limited integration with source control (code, as it's embeded in the .dot files, was not historisable. Only the full .dot was)
Error management very limited with VBA
Poor IDE
Remark:
As an experienced C# developer, the pros/cons may be partial a bit.
I am a heavy Excel VBA developer.
VBA pro:
One of the major hurdles for me switching over to VSTO from VBA - and believe me, I love C# coding - is that there's no debug-on-the-fly which my userbase has got used to. I often jump straight into a VBA problem on the user's PC as it is happening, but with VSTO, that's not possible. (Unless someone can correct me.)
If your users have no such expectations this might be something you can easily live without.
VBA con:
VBA is one of the those languages that are easy to play with and thus easy to make a mess with. It doesn't enforce "clean coding" principles which means while decent programmers can make great applications with them, VBA can become associated with hackjobs and sprawling, organic code due to its low bar of entry. VBA developers are often considered a lower class of developer for this reason, when really there is a failure to distinguish between those that use it wisely and those that don't.
I doubt anyone chooses VBA as their career language of choice, it just sort of happens to them. Aside from being hard to find skilled developers, too much VBA work might turn away potential hires as they don't want to be associated with the "quagmire of another unmanaged VBA sprawl". Some people take use of VBA as a statement about how "serious" you are about technology.
(I tend to see Perl in the same light; great for short scripts but when someone used to using for scripting starts to use for a larger piece of work - you tend to get something that's a bit unwieldy.)
In this article I tried to summarize similar questions, in the context of Excel. Same arguments apply for all of the Office applications including word.
According to my observations :
VSTO :
CONS : that if we have developed Addins ribbons control for word 2007, we can only deploy with word 2007, but we can not deploy with word 2010 or word 2013.
This is major drawback for me to develop Addins for word and excel for all its versions like 2007, 2010 and 2013. plz correct me if am wrong or suggest me how could I develop Single Addins for all office version.
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