Happy New Year everyone!
I'm building an Outlook Add-in (non-web), and it works really good at home (Office 365/2016). At work, I have office 2013, and some features don't work very well on it. So, since I have VS2017 on both computers, and my code is on Azure, I can go ahead, and download it, run it, and it should work, however I get the error that I can't debug it because of the version difference.
So, After digging around the net, the most popular answer was tell the add-in to run by giving the path to this version of outlook. The problem with this, is that I'm not able to hit break points, etc.
Now that you have some background, here is the problem I have and the question I need answered. Is there a definitive guide or best practice to allow me to 'debug' as well as test my add-in across different office platforms, or, is there a way to adjust the code/package to allow me to debug on any office platform out there?
Thanks for the help.
Related
In my workplace we have several different types of systems.
Surface Pro's running Office 2016
Surface Pro's running Office 2013
Thin Clients running Office 2010
Desktops for Accessibility users running Office 2010
I develop VBA solutions that have to work across all of the above, and run into trouble with only one scenario.
I use a Surface Pro with Office 2016. If I build a document, I can run the macros I create on the Surface Pro's and Thin clients without issue, but the Desktop PC's running Office 2010 don't even get the option to turn on the macros.
If I open the file up on a desktop (seldom have access to one) and save it using that system, any other user on a desktop can open it up and the macros will work, but if anyone from one of the other systems opens it up and saves it, the desktop users will go back to square one.
At first I thought this would have been a compatibility issue relating to architecture
Can anyone think of anything before I pull the remainder of my hair out? I really want to be able to solve issues for the people having problems on desktops without having to find one myself, or worse - give them any passwords
Cheers
Go to VBA Tools and uncheck all objects marked as missing under References.
I have created a working Powerpoint add-in (.ppam) that offers several time saving features, and added a custom UI ribbon tab to improve accessibility.
As I look to distribute this add-in to users, I'm looking to improve code security by compiling it into a COM add-in (.dll) via VS Express.
I have looked all over the web for documentation on this, and have found some promising source, such as:
http://www.cpearson.com/excel/creatingcomaddin.aspx
Unfortunately, nearly everything I find appear to be quite outdated and based on Office XP or 2003, when I'm looking at Office 2010. I'm probably doing something wrong here, but I'm having trouble replicating their instructions on my end, running into errors like being unable to add a reference library or the code they suggest is not recognized. I actually am even unsure how to open for example the sample VB project that the Pearson site provides from the link above to imitate. I think all this may be because of the different versions of Office and Visual Studio, but could certainly be wrong.
Could anyone point me in the right direction? My understanding is that it's actually quite simple to convert the code from VBA to VB (just involves adding "Powerpoint.Application." in front of things like "activewindow"). So I just need to figure out how to convert a very simple VBA add-in into a COM add-in in VS Exp 2012 for Office 2010, and then can leverage the process to convert the full add-in.
Apologies if I'm using any of the terms incorrectly.
I am afraid this is an untypical "unspecific" question...
I have a lot of code in Outlook, and this should also be used by other users. Up to now I am exporting the modules and forms from my Outlook, and import them on the other machines. But this of course is quite a hassle on every change.
So I thought about turning them into an adding - easy to do for example for Excel...
I have done some Research now and the following questions are left:
is it right that the only software really useful is Visual Studio?
i did download the Trial Version of Visual Studio, and digged into it... but it seems I can not copy/paste the existing code, but there are a lot of changes necessary in the code - is that right? Is there a Kind of "translation" for the most common things?
Thanks for your answers,
Max
Not sure if by trial version you mean Visual Studio Express which you can find here:
http://www.microsoft.com/visualstudio/eng/downloads#d-2013-express
In any case this should allow you to copy/paste your code. Also if you are a student/academic you can download the full version for free (https://www.dreamspark.com).
If you don't want to use VS, you could try SharpDevelop and NetOffice as an alternative.
I wrote a series on my blog about how to create an add-in for Outlook. There are quite specific instructions on how to get started, pitfalls I encountered along the way and tips/tricks to help you.
Here is where the series starts: http://www.midniteblog.com/?p=6. You can see all the links for the series here: http://www.midniteblog.com/?s=outlook.
Hope this is helpful for you!
P.S. You definitely want to use Visual Studio for a project like this because of the nature of Microsoft product integration.
Background:
I have come up with an idea that will make things easier for the company I work for. They even seem excited about the idea. The idea is to make an addin for Outlook to help with a task. So after doing a bit of research (obviously, not enough). I downloaded a trial copy of VS2010 pro and created a VSTO addin.
After creating the addin, it was time to package it for a small test deployment. That's when I found out that this is a much more difficult thing to do. It seems MS does not ship Office 2010 with the runtime needed to run VSTO, so i'd have to package that as well. In a company environment, this is not something simple to do.
So, I might have to go back to the drawing board.
Meat of the question:
I've never created an addin for office before, I really want more of a "drop in" solution. I'm not sure if VBA is the right solution. It seems more of a "document" level application (or macro?). Does any one know what would be the best type of solution for this?
Outlook API is not native .NET framework. To interact it with, .NET relies on marshaling and interrop assembly thus making it much more prone to errors and unstable.
From what I've seen so far with my outlook API experience, I would stick with VBA and you should consider retrieving a third party library that exposes outlook extended MAPI if you run in to much of trouble.
NetOffice is pretty good - it is a set of managed .NET libraries that handles the COM API with Office and only needs XCopy installation.
The best part is it tracks all runtime callable wrappers ('RCWs') you create when accessing objects through COM and automatically releases them when you dispose the top-level object (the Application in most cases), so you won't get the issue of an orphaned COM 'handle' preventing you from closing Office.
Alternatively, the Office Primary Interop Assemblies should be on any computer that has the relevant version of Office installed (at least for >= Office 2007). But there are cases when it won't so you will have to cover that possibility. VSTO redistributable should already be installed on any computer with Office 2010 or 2013. For Office 2007 you will need to install it. But again, better safe than sorry so you should include it in your installer in both cases.
For details on deployment options look at http://msdn.microsoft.com/en-us/library/bb386179.aspx
As for VBA, I don't have experience for Outlook addins so I leave that to others to explain. Other VBA Office app addins (Excel/Word/Visio/PPT at least - not sure about the others as I haven't used them) can be installed either using registry keys or through XCopying the addin to a trusted location and then telling the user to open Options/Manage addins and tick the tick box.
I highly recommend Add-in Express. They have tools that go beyond what Microsoft provides via Visual Studio.
Their features for Outlook development greatly reduce the amount of effort required to build Outlook add-ins
I work in an academic lab, and have been working on VSTO Add-In to Excel (primary to handle complex data analysis and generate reports, what I think is bread and butter for VSTO). At the lab we have Office 2010 almost exclusively (universities are like that). We are partnering with a drug company that is using Office 365.
They want to use the same Add-In I've been developing so we're all on the same page. I've let our Tech Transfer office know in case there are any licensing issues, as I don't think that's my problem to figure out.
On the tech side of things, I've been trying to figure out if the Add-In will work with 365. I built it in VS-2012 (academic version of professional) and it works well in Excel 2010 (though I keep adding to it).
I have read:
https://blogs.msdn.com/b/donovanf/archive/2011/06/29/office-365-developer-guidance-and-resources.aspx?Redirected=true
Which didn't make it sound hopeful, until I realized that if they get the premium edition it still includes a local install:
https://office.microsoft.com/en-us/business/office-online-microsoft-office-365-for-small-businesses-FX103037625.aspx
So my question is if someone is using the 365 Premium Edition with a local instal, then will a VSTO built for 2010 still work? I may be able to answer this in a few days when I actual meet them in person (and thus try it out), but I'd like to know the answer ahead of time if possible.
If not, would the best solution be to back track into VBA (that seems backwards) or try to work with SharePoint (for the first time in my life).
Thanks.
Well hopefully, someone can save some worry by knowing that infact it will work with Premium addition of 365. I was able to deploy the add-in without issue to their 365 local installs. I don't think it will work with the lower versions, but I haven't had a chance to test that yet.