I'm developing an Outlook add-in using the NetOffice library.
It was a nice experience, but lastly I changed my drive, reinstalled windows, office etc.
Now my add in doesn't run, and in the "COM Add-Ins" in Outlook options I see:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in
And this problem is even on the simples example from NetOffice, that is the NetOffice Tools - Simple project, which basically doesn't do anything.
I put in the constructor of the add in a logging code (to a file), but it doesn't run, so even the constructor isn't hit.
Any tips how to troubleshoot it?
EDIT: using AddInSpy I found out, that the Add-in status is:
Add-in DLL path is not found.
but no idea how to move on with this information.
Worked it out! :)
After reinstalling windows, I installed Office 2013 64 bit whereas earlier I had the 32 bit version, that caused a lot of trouble.
To run it on 64 bit:
Target 64 bit when compiling the add-in (AnyCPU is not enough!)
VS can use the 32 bit regasm, so add to the post build event following line:
"%Windir%\Microsoft.NET\Framework64\v4.0.30319\regasm" "$(TargetPath)"
and it works again.
Related
I'm getting the following error message
Cannot access a disposed object. Object name: 'MarshalingWindowFrame'.
This message came when I tried to load a SLN file into VS2013.
What is the reason?
I am using VS2013 Ultimate with Update 4 on Windows8.1 pro x64 bit OS (8GB RAM, 500GB HDD)
If you get that when opening a solution, either an addon is bugging out or (worse, but less likely) you found a bug in VS itself. Try safe mode and see if that helps.
If however you get the error when opening a form rather than the solution itself (remember opening a solution loads the various forms), there's a bug in an user control that's trying to access a disposed object. Remember that user controls run as binaries when hosted in VS, so make sure you put actual code inside guards that require you not to be in design mode.
Was that project created in the earlier versions or in the Visual Studio 2013 Preview? Because, if you update this project from Visual Studio 2013 Preview, you have to check the update procedure (http://blogs.msdn.com/b/lightswitch/archive/2013/08/12/upgrading-your-lightswitch-projects-raghuveer-gopalakrishnan.aspx) first, perhaps it can give some hints why this happens.
After installing all latest windows updates my Excel VBA code is showing an automation error at the very start of the first module. It contains some forms as well as numerous modules of VBA code. However, when removing the forms (and associated code) everything is fine.
The same thing happened about a year ago after some other windows updates. Back then deleting the .exd files did the trick, but the current updates (including Service Pack 3) seem to be different.
What is going on and how can I get the forms to work? All the code is unchanged and has survived all previous windows/office updates. Running Windows 7 (same happening on Vista machine) and Office 2007.
I used to see this a lot with Visual Basic and Crystal Reports; either due to a bad deployment or DLL Hell.
So, my guess is that it's not the code but perhaps some 3rd party controls (OCXs, DLLs) you're using.
Check your References (In VBA IDE, click Tools and References) and to see where each DLL is pointing.
See if any of the dates on the libraries are different than a working machine and you may find the culprit.
Edit
The OP found the problem by following the steps above.
The fix for this particular issue is to unregister mscomctl.ocx:
regsvr32 /u mscomctl.ocx
Then register it:
regsvr32 mscomctl.ocx
Same issue here, problem completely solved after registering mscomctl.ocx!
for Windows 7 or 2008 - remember to run cmd.exe "as administrator", and then:
for 32bit Windows systems:
regsvr32 c:\windows\system32\mscomctl.ocx
for 64bit Windows systems:
regsvr32 c:\windows\syswow64\mscomctl.ocx
Same issue with VBA for AutoCAD. In my case, registering the new mscomctl.ocx with regsvr32 was enough to fix the issue.
We couldn´t solve the problem by re-registering mscomctl.ocx.
But we solved it by removing a "progress bar object form" wich calls mscomctl.ocx... We replaced it with application.statusbar.
Check out http://support.microsoft.com/kb/2687441 for an update that may fix this problem
We have the same problem. In our Add-In, we were able to trace the problem to a declaration of a variable as Excel.Application. The reference to this object is in the Excel.exe file, so it is very unclear as to which files got messed up.
The machines that have this problem were all updated early this morning (15 Aug 2012) with the following updates (sorry for not posting links, as a new user, I'm limited to only two per post):
Security Update for Microsoft Office 2007 suites (KB2596615)
Security Update for Microsoft Office 2007 suites (KB2596754)
Security Update for Microsoft Office 2007 suites (KB2596856)
Security Update for Microsoft Office 2007 suites (KB2687441)
Update for Microsoft Office Outlook 2007 Junk Email Filter (KB2687400)
Windows Malicious Software Removal Tool x64 - August 2012 (KB890830)
At present, we have not found any information on the MSDN site that could clear this up. We're still trying to isolate this down further.
I had the same problem. I got an unspecified error opening excel with my Add-In loading.
In the past, deleting the *.exd files in C:\Documents and Settings\%USERNAME%\Application Data\Microsoft\Forms\
did the trick, but not this time.
When I attempted to open up the forms in my addin, I got a different error and I could not open the forms.
I ended up rolling back to last night prior to the update and everything works again.
Same issue here today after performing the update for Office 2007 Excel. Oddly, one system had no issues despite the update - the newest system. So after some inspection, I noticed this trouble-free system had different version of MSCOMCTL.OCX in windows\sysWOW64 then others. Here are the details of this activeX
Size: 1,070,152 bytes
created: 6/3/2012
modified: 6/6/2012
product version: 6.01.9834
So I copied this to the trouble one and it did the trick.
Also, you might want to check if these application extensions are present in windows\sysWOW64 or windows\system32 for 32-bit system
FM20.DLL (Modified Date: 7/7/2011, version 12.0.6604.1000, 1.13MB)
FM20ENU.DLL (Modified Date: 10/24/2008, version 12.0.6413.1000, 32.3KB)
Not sure where you can download these. I cannibalized them from other systems.
Had the same issue on all of our terminal servers after one of the updates last night. Registering mscomctl.ocx fixed the problem for all users.
Un- and registering the MSCOMCTL.ocx did the trick for me:
Open an administrative-level command prompt. Click START, and type RUN in the run command line. On Windows Vista and Windows 7 you will
see CMD.EXE appear in the quick search list. Right click CMD.EXE and
left click Run As Administrator. A black command prompt opens.
If on a 64-bit machine, type the following: regsvr32.exe /u C:\Windows\SysWOW64\MSCOMCTL.OCX
Hit ENTER then type regsvr32.exe C:\Windows\SysWOW64\MSCOMCTL.OCX
If on a 32-bit machine, type the following: regsvr32.exe /u
C:\Windows\System32\MSCOMCTL.OCX hit ENTER then type
regsvr32.exe C:\Windows\System32\MSCOMCTL.OCX Your Office program
should work again after doing this.
Please see also: http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2012/08/15/quot-unspecified-automation-error-quot-after-applying-ms12-060.aspx
son of a gun...I re-registered C:\Windows\System32\MSCOMCTL.OCX and everything works again. Thanks so much to all that pointed that out.
I think I'll soon will regret the day I chose to use InstallShield and not WiX.
I had a bit of experience with WiX, and it seemed a bit complicated to use, so when the time came for a real project, I chose to use the new Flexera InstallShield LE for Visual Studio 2010.
At first it seemed so easy, I created and compiled the first installation project without any issues. It even managed to extract COM information from some 3rd party library (which was compiled using VC 6, as far as I know).
But when I added some more InstallShield installation (ISL) projects to the same solution, strange problems appeared. If I edit the General information page of one ISL project and then click Save All button, suddenly the information gets messed up with parts from other ISL projects, some fields show up as UNITITIALIZED STRING, and some fields just mix up. And when I open the other ISL projects, I see, that the info is messed up there, too. The only solution seems to be to unload all other ISL projects while editing the General information page.
The problem number two: crashes. My project is a mixed C++/C# application. Sometimes while editing unmanaged C++ code, Visual Studio just crashes on some certain operations (like commenting out some blocks of code, cutting, pasting). I even installed Visual Studio 2010 SP1, but that did not help. The crashes completely stopped occurring when I unloaded all ISL projects.
Anyway, I am frustrated and now I have a choice:
stay with ISL, create my own executable which will get installed and will run regsvr32. Still I'll have to live with Visual Studio crashes and General Information page problems.
move to Windows Installer XML. But I am not sure at what stage it is now, won't I have the same problems? Can WiX register COMs for me (also can it register 32 bit dlls on 64 bit systems using regsvr32 from syswow64 folder)? Is it stable with Visual Studio 2010?
I will really appreciate your suggestions about what should I do - stay with ISL or move to WiX, especially from those who are experienced WiX users on Visual Studio 2010.
I would highly recommend migrating your setup installers to use Windows Installer XML (WiX).
I did this years ago and have never looked back. :)
Wix v3.5 is very stable.
I haven't had any problems with its integration with Visual Studio, among a lot of its other features.
It's open source and the community is very helpful.
You can use heat.exe to extract COM information from a file.
http://wix.sourceforge.net/manual-wix3/heat.htm
You can call regsvr32.exe for example on the target machine using the built-in Quiet Execution CustomAction
http://wix.sourceforge.net/manual-wix3/qtexec.htm
That link also documents how to run 64-bit executables.
You can use the [SystemFolder] property to execute a file in c:\windows\syswow64 for example.
http://msdn.microsoft.com/en-us/library/aa372055.aspx
WiX's DTF technology is perfect for writing msi custom actions in c#.
HTH.
I am trying to distribute my Outlook Add-In to the rest of the company.
I'm using Visual Studio 2008 Professional and Outlook 2003. In VS I used an installed template for Outlook 2003. It created a solution with BOTH a project and an installer.
I use the project and created an Add-In. It works GREAT on my PC in development. Now, I want to distribute it. Here's where things go haywire. The nice little installer they provide DOESN'T ACTUALLY WORK.
The installer runs and places the files where they are to go, but the add-in doesn't run. Instead it gets errors about not having permissions. The installer didn't automatically set the security settings for you.
No problem. You just have to set those settings... right? But no where can I find a simple list of those settings.
I've been to http://msdn.microsoft.com/en-us/library/bb332051.aspx a thousand times from almost every possible link on the web. I've read every Microsoft paper that I can find on VSTO add-Ins. Unfortunately everything seems to reference some magic script... "Just include the sample code..."
[rant] IF A SECTION OF CODE OR AN ENTIRE SOLUTION IS REQUIRED TO DISTRIBUTE YOUR CODE IT IS NOT SAMPLE!! IT IS REQUIRED !!! [/rant]
There. I feel better.
Since I installed VS2008, I don't have the directory:
C:\Program Files\Microsoft Visual Studio 2005 Tools for Office SE Resources\Samples
No problem, right? Just DL it from microsoft. I've downloaded every "vstor.exe" that I can get my hands on. They all offer to "repair or uninstall" my current installation, but no matter what I choose, the vstor.exe crashes.
HELP!!!
I just want to know what I need to do (the manual steps, if necessary!!!!!) to get my friggin app distributed.
No magic "include this gizmo". No fifty-thousand page diatribes.
Anyone know how this is ACTUALLY done?!
I got it to work.
I was able to get a "sample code" update from Microsoft that allowed me to follow the walk-through.
I still think that's utterly ridiculous to HAVE to use sample code to easily distribute your app. However it is working at the moment.
The link I used was given to me by anonymous use on a different board. Whoever you are THANK YOU!!!!
Here is the link I was given:
http://www.microsoft.com/downloads/details.aspx?familyid=6991E869-8D5B-45F4-91E7-B527BD236F4C&displaylang=en
This allowed me to actually get my hands on that mysterious "sample" code even though I use VS2008 Professional.
Using VB6, I have created an Outlook plugin, that has a property page. The property page is an OCX control.
When I compile the project to an OCX file, and then run OUTLOOK, things work fine: I am able to see my OCX as a tab in the Outlook options.
However, when I try to debug by running the OCX in VB6 I get an error. My debugging is started like this:
1) Debug options set to Wait for components to be created"
2) F5-RUN project in VB6.
3) Start Outlook.
4) Get the error: "Cannot display "MyOcx" page. This page will remain visible, but is not available. An OLE registration error occurred. The program is not correctly installed. Run Setup again for the program"
I suspect this is because, when debugging, the OCX is being created out-of-proc and Outlook doesn't like that.
Is there a good technique to use the VB6 debugger on the OCX in this scenario?
The VB6 debugger is sometimes flaky when debugging DLLs or OCXs.
You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 OCX into native code with no optimisation and "create symbolic debug info" (i.e. create PDB files), and you will be able to debug your OCX in-process in Outlook. Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). EDIT see Kris's answer for more details.
EDIT: Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the OCX was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives - or I'm told the serious way is to use a Symbol Server.
(Les serious) you could do without those newfangled interactive debuggers, just log to a file, or with DebugMessage calls from your VB6.
The only way you are really going to be able to Debug this is In Process as MarkJ said. Using the free Visual Studio 2008 C++ Express Edition (or even better, Visual Studio 2008 Professional if you have it, and it is available for a 90 day trial) and a PDB.
To make sure you are creating the PDB, go into Visual Basic, check the P)roject / P)roperties and click on the Compile tag. Make sure "Create Symbolic Debug Info" is checked.
Next start up Outlook, and attach to that process from Visual Studio (T)ools / Attach To Process. Make sure your Ocx is shown in the modules window, and then load the PDB (right click on the Ocx in the modules window). You will probably have to add the source code in the Solution Properties (for more details on how to do that, read this post).
It's a bit of a pain in the butt the first time, but once you can do it, it becomes pretty easy, and is far easier than trying to determine what is going on from a log.
I don't have much idea on the OCX.
However, you can use a tool which was part of visual studio named something like "activex control test tool".
As far as I know (based on my understanding of documentation), OCX is created in-proc.