Add-Ins with VB.Net - Should I even bother?

[Rich Anderson]

Hi There, I'm pretty new to building add-ins and I was able to build a simple Hello world add-in and successfully register it with c# using the examples on the website.  I also tried to make a clone of it in VB.NET using VS2015 and I wasn't able to register it, getting the "missing  0x800401f3" error.   I've looked through all the posts I can find on this, and it appears to be a  C# kind of thing (although the SDK has lots of VB in it)

All things, being equal, I would rather use VB for this situation, but I'm wondering whether I'm just setting myself up for problems.  I can do C#, if I have to. 

Suggestions?

[Uffe]

Hi Rich,


The language itself shouldn't really be an issue. The EA API doesn't utilize any modern language features, it's all very basic. You can write Add-Ins in C++ if you like.

I'm not sure which examples you're referring to, but if they're telling you to run regasm manually or set your project up to auto-register the DLL for COM interoperability and you don't know what this does, then the problem is in the deployment space, not the source space or build space.

Are you developing an Add-In solely for use on your development machine, or will it need to be distributed to others?

If the latter, my best advice is to bite the bullet and add an installer project to your solution. I use WiX, which is what Microsoft recommends, and it's pretty easy to set the installer project up to harvest the necessary information from your DLL during build. Meaning you can set it up once and then forget about it.

Even if you're just doing something for yourself which you will never ever want to move to another machine either now or at any time in the future I'd advise you to set it up properly. Might as well do it right.

HTH,


/Uffe

[Geert Bellekens]

Rich,

All of the add-ins I know of are written in C# (except maybe eaDocX. Ian is kind of hush-hush about that ).
So although it should technically be perfectly possible to write an add-in in VB.Net, I think you are much better off using C#.

- There are a lot of open source add-ins available in C# => lots of example code.
- C# in general is used a lot more nowadays than VB.Net (and personally I like the syntax a lot better), so you'll find a lot more solutions online for the problems you will be facing.

Geert

PS. You can find some of the open source add-ins on my Github page

[EXploringEA]

Hi Rich,

Yes.

As pointed out it's not the language that's the issue with writing an AddIn - C+,C#, VB.net  - anything that can create a valid DLL.  In my experience writing AddIns is more about understanding the EA API and dealing with the quirks of windows.

BTW: These days I write nearly all my AddIns in VB.Net unless my customer specifically wants another language, although I'd probably draw the line at doing it in assembly language these days!

If it would help I'm sure I can provide some example VB.net projects including installers - what type of stuff are you trying to do?

Re the error, 800401F3 that is nothing to do with the language; the error message translates to Invalid class string, so this looks like your AddIn DLL isn't registered or name is not correct.  Suggest you download my free Installation Inspector as that may provide a bit of information.  V5 of the installer is in Beta but may be more useful as it includes registry search functions that may help find any mismatch between class name and the class names in your dll file.

I also have some information/examples on registration/installation on the public part of my tools site that may be of interest. As suggested by Uffe Wix works fine and worth getting a good working template sorted early on. 

And as you've probably guessed there are plenty of experts on the forum always ready to help.

Adrian

[Sunshine]

Just concurring with whats being said earlier. If you preserve you should be able to get VB.Net Add in working.  Personally I'd advise against using VB for future work and start learning C#.  Why? Well VB is no longer the cool kid on the block and its getting more and more difficult to find developers.
As you've found out you've managed to get a C# plug in working because more people are using it so C# would be the way to go.

[Rich Anderson]

Hi All,  First let me say THANKS for all the great help and advice.  I think I need a bit of time to go through all of this and make a call.  The reason I prefer VB.net is that I have at TON of EA automation "helpers" written VB.NET as separate executables to do all kinds of stuff and have gotten to know the EA API quite well. That includes this crazy thing (https://www.youtube.com/watch?v=tpvqeNLQnxQ) that I wrote about 2 years ago that I use all the time in my work.  Much of what I do involves interchanging data with MS Excel (both reading from Excel and writing to it).  In that world, it helps a lot to use a language similar to Excel VBA, so VB.Net works better for me for that reason, too.  Plus, I'm just old, and I don't want to change my ways!   

I can do C# if I need to and maybe I just need to eat my spinach in this case and get on with it (or maybe I don't).    I'll let you all know how I get on, but thanks again for all the help!

[Glassboy]

Plus, I'm just old, and I don't want to change my ways!   

Come now, I've met you, you are quite sprightly :-)

[Paolo F Cantoni]

Hi All,  First let me say THANKS for all the great help and advice.  I think I need a bit of time to go through all of this and make a call.  The reason I prefer VB.net is that I have at TON of EA automation "helpers" written VB.NET as separate executables to do all kinds of stuff and have gotten to know the EA API quite well. That includes this crazy thing (https://www.youtube.com/watch?v=tpvqeNLQnxQ) that I wrote about 2 years ago that I use all the time in my work.  Much of what I do involves interchanging data with MS Excel (both reading from Excel and writing to it).  In that world, it helps a lot to use a language similar to Excel VBA, so VB.Net works better for me for that reason, too.  Plus, I'm just old, and I don't want to change my ways!   

I can do C# if I need to and maybe I just need to eat my spinach in this case and get on with it (or maybe I don't).    I'll let you all know how I get on, but thanks again for all the help!

I hear you.  When interacting with MS office, we tend to use VBA - we have some libraries that we build on top of and so it makes it relatively easy.
We have our diagrammer Add-In in C#
We started to use JScript for scripts but found VBScript allowed us to leverage our investments in VBA.  There was also the issue of how to specify ByRef parameters in JScript (which we couldn't).

I, too, am old.  But fortunately, people tell me I look 10 years younger.

PAolo

[EXploringEA]

Rich,

Don't be put off by the "youngsters", I started using Excel VBA with EA in 2002, then later used VB.NET (At the time Java was my preference but couldn't get it to work with EA then; not sure where it is now).  Done a lot with EA and Excel including the XL part of eaDocX in VB.Net so know it is fit for purpose!

For some projects, where an off-the-shelf solution doesn't provide the functionality and dynamic interactions with Excel are not required I have used libraries both my own and the EPPlus open-source Excel library.  The later is a file based solution so useful for reading and creating /export Excel workbooks; it also avoids the need for the Excel Interop and the challenges that can present.

Adrian

[Sunshine]

Rich,
Don't be put off by the "youngsters"....

For the record I'm 1960's vintage so probably fall into the youngsters category. I hear what you are saying about VB.Net. Its now treat as first class language by MS so its more than capable. If folk have invested IP in that language then thats going to be the way to go for now to meet your goals as quickly as possible.
I too have a long pedigree with VB, C, C++, C#, Java etc. I even remember the days when VB was a second class language. However its not about putting people off particular language. Its about getting things done with the least impediment and what I'm observing is between C# and VB the former appears to have more momentum behind it. For those without prior investment in VB then for longevity its sometimes best to stick with the larger pack. Not that there is anything wrong with VB. I just recommend C# as its quicker for me and I can get my youngters to do some of the work for me so I can do other things.

[Ian Mitchell]

"I have at TON of EA automation "helpers" written VB.NET "....and that's precisely the reason why eaDocX was written in VB.net, and why it's still in VB.net.
It's about the usefulness of the function, not the language it's written in. And we've got a few 1000 customers who'll back that up.