I am developing an application where I want to sync the outlook calendar, mail, etc.
The piece of code which is there with me is working fine for outlook 2003, 2007.
but I don't know what's the problem it is causing for outlook 2010.
I use the following:
redemption dll 5.4 version-32 bit
office object core 14 dll-32 bit
office -32 bit version
visual studio 2008
I am getting this error:
Cannot create ActiveX component.
On the following line:
session = CreateObject("Redemption.RDOSession")
Where session is:
Dim session As Redemption.RDOSession
After which the following error is displayed:
Either there is no default mail client or the current mail client cannot fulfill the messaging request
I have tried various things but it's same. I also reinstalled, repaired outlook, repaired registry.
Any ideas?
this worked for me:
first, I will say I used the Customize.exe that comes with redemption to create a dll called ffloader.dll
Next, I registered that dll as follows (32 bit)
regsvr32 ffloader.dll
Finally in the vb.net code I created the session as follows:
Dim Session As Redemption.RDOSession = CreateObject("ffloader.ffRDOSession")
Hope that helps!
Related
I'm using IConverterSession to create mail items from mhtm files. This works fine with Outlook Versions < 2016. With Office 2016, IConverterSession cannot be created.
If you are running C2R (click-to-run) version of Outlook 2016, all registry keys are virtualized - see the registry keys below (%s needs to be replaced by the Outlook version, e.g. 16.0). Since the COM system does not look there, you will need to implement your own version of CoCreateInstance that reads the default value from the key to figure out the dll file name, then calls LoadLibrary / GetProcAddress("DllGetClassObject") / DllGetClassObject(..., IID_IClassFactory, ...) / IClassFactory.CreateInstance.
SOFTWARE\Microsoft\Office\%s.0\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\%s\InprocServer32
SOFTWARE\Microsoft\Office\%s.0\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\%s\InprocServer32
SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\%s\InprocServer32
SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\%s\InprocServer32
Instead of implementing CoCreateInstance() on your own, you have to enable registry redirection to enable C2R (click-to-run) virtualization of Outlook which is using detours to redirect the call to RegOpenKey(). After enabling that redirection just use the normal CoCreateInstance().
The reason why implementing CoCreateInstance() on your own doesn't work is, that the converter will also call CoCreateInstance() internally and that will fail like your original call because it doesn't find the CLSID in the normal hive of the registry.
I found out the code myself by looking on the jitv.dll exports. The parameters may be wrong, but as a first start it was working without a crash. To find out the parameters I have to debug an Office application and look at the disassembly (or any volunteers?).
Here the experimental code that worked for me :
HMODULE jitv = ::LoadLibrary(TEXT("jitv.dll"));
if (jitv) {
FARPROC efv = ::GetProcAddress(jitv, "EnableFullVirtualization");
if(efv)
efv();
// call CoCreateInstance(guid::CLSID_IConverterSession)
// and do your work
}
if (jitv)
FreeLibrary(jitv);
There are some other exports in the jitv.dll whose names are mostly selfexplanary:
"APIExportForDetours"
"DisableVirtualizationOnThread"
"EnableVirtualizationOnThread"
"IsCurrentThreadVirtualized"
Thanks to this posting by nickekallen which mentioned that dll and brought me to that idea.
The problem I am trying to solve is that I want Excel to send an email through Outlook. This is worked fine when I am using a local installation of Excel.
However I need to be able to do the same using an installation of Excel on a server. The debugger points to this line in the code:
Set OutApp = CreateObject("Outlook.Application", "localcomputername")
At first I tried without reference to local computer this gave me error:
Runtime Error 429 - ActiveX Component Can't Create Object
With the line above I get the following errormessage:
Runtime error 463 - class not registered on local machine
Hope someone can help me
When you use the New operator or the CreateObject function in Microsoft Visual Basic to create an instance of a Microsoft Office application, you may receive the following error message:
Run-time error '429': ActiveX component can't create object
This error occurs when the Component Object Model (COM) cannot create the requested Automation object, and the Automation object is therefore unavailable to Visual Basic. This error does not occur on all computers.
View this for More information - https://support.microsoft.com/en-in/kb/828550
I have a vb.net script that sends automatic emails from Outlook. It currently works in the Office 2010 Suite. I upgraded my environments to 2013 and now it is not working. What I'm doing isn't complicated. All I want to do is grab a .pdf and attache it to an email. Then add the recipients and send the email. The place where it crashes is the actual sending of the email. It throws this execption
System.Runtime.InteropServices.COMEception occurred in Microsoft.VisualBasic.dll
Additional information: Operation aborted (Execption from HRESULT: 0x80004004 (E_ABORT))
I'm thinking because I upgraded environments something isn't referenced correctly. But I can't seem to find a fix. Below is my code, any help would be greatly appreciated! Thanks in advanced.
Imports Outlook = Microsoft.Office.Interop.Outlook
Module Module1
Sub main()
sendEmail()
End Sub
Public Sub sendEmail()
Dim ol As Object
Dim mail AS Object
ol = CreateObject("Outlook.Application")
mail = ol.CreateItem(0)
mail.To = "email#example.com"
mail.Subject = "Subject Line"
mail.Body = "Body text"
mail.Attachments.Add("path\to\attachment.pdf")
mail.Send() 'crashes on this line
mail = Nothing
ol = Nothing
End Sub
End Module
Also I am running on Windows 7 with the Office 2013 suite. Looking at the App.config my supported Runtime version is v4.0 and the .NetFramework version is v4.5
Since your solution is automating Outlook cross-process you first need to ensure that these types of applications are authorized so check your anti-virus state in Outlook's Trust Center:
https://msdn.microsoft.com/en-us/library/office/ff864479.aspx
I would also wrap the CreateObject call in a Try/Catch block to ensure that isn't failing to begin with. Also make sure that you have an Outlook profile created and that your application isn't running under a non-authorized security context like via a Task Scheduler process or in a web application.
I am the IT department of a Non-Profit organization. I have a question today which might be too specialized for this forum and I hope I do not waste my time writing it up. We are using Blackbaud's 'Raiser's Edge' (RE) Software (written in VB6 and VB.net as far as I know) to keep track of our membership and donations. We have an MS Access application (have been using it since before we got RE) to process donations and for now I want to keep it and only do minor changes to adapt it to the new software.
The MS Access program is now doing a few calls to the RE API which work great. To login and establish a connection I have to create a new 'REAPI' object and use it for other API calls. That REAPI object has a method called: SignOutOnTerminate which needs to be set to TRUE when creating that object. It is supposed to kill all connections to RE once my application closes. There is no regular .close method.
Once I create the object I can do work as many times as I want and there is no problem at all as far as I can see.
However when trying to close the application or set the object to nothing (Set REAPI = Nothing) Access crashes immediately (It fades out and I get the message that Windows is looking for a solution to the problem. Then Access closes and restarts itself.)
It is more annoying and unprofessional then hindering production but I want to fix it.
The App was developed on Windows 7 64-bit with Access 2010 32-bit. It was tested on Windows XP with Office 2003 or 2007 machines (32-bit) and behaves the same way.
I have posted this problem already on 2 Blackbaud forums and tried a suggested a work around which did not work (kill the process with a shell command and then set the object to nothing). Hopefully I will get more answers soon.
I tried to just exclude the SignOutOnTerminate when creating the object. But got the same behavior.
I looked in the Event Manager --> Application Log and found the Crash. It reported that access crashed because of this dll: C:\Windows\System32\MSVBVM60.dll (It is actually located in the SysWos64 folder as it is a 32-bit application).
Looking up this error I found some suggestions to replace it with an earlier version of the dll, the one which ships with XP. I found a file and tried the suggestion but it still crashed. The error log reported the older version number as faulting so I registered it correctly.
I also created a case with Blackbaud but the rep did not know what the problem is and did not have MS Access installed. He is trying to get his support team to install it for him so he can test and investigate this error.
The last suspicion I have is that the API is causing the error and my code is fine.
But before I make this assumption and until I get my answer from Blackbaud I want to do a final check, but I have run out of ideas for further trouble shooting and resorted to pose this problem in this forum.
Any Ideas?
I realise that this is an old thread and if you have solved this by now then that is great. However this is a known issue with The Raiser's Edge API. If you use .NET with RE's API (which is COM based) there is definitely some resource that is not cleaned up properly. At one point I suspected that it was something to with making use of RE's graphical interface i.e. by calling the regular login method to log you into RE. However even if you log in to RE using the "as a server" method supplying the user name and password it still crashes on exiting the application.
We have an installer that sets up credentials in RE. The installer is in .NET and accesses the RE API. We now show a message just before the end of the application telling users to ignore the impending crash... Not a great solution by any means.
I have an application which creates a MAPI profile to send mails/messages. The profile is getting created properly on Outlook2007 environment, but it is not getting created properly on Outlook2007 SP2 environment. Both the source code and "exchange environment to which MAPI/outlook profile" are same. The profile is created using MAPI subsystem.
Description about the application: The application is a windows service-based application. The service executes a COM application. The COM application spawns a new thread to create a new profile and sends a sample message.
Actual problem: During the profile creation, the call to the ConfigureMsgService function (that belongs to IMsgServiceAdmin) is not working properly even though it returns S_OK. The value for the 5th parameter "lpProps" of ConfigureMsgService function is given below.
// First, the mailbox name.
ZeroMemory(&rgval[0], sizeof(SPropValue) );
rgval[0].ulPropTag = PR_PROFILE_UNRESOLVED_NAME;
rgval[0].Value.lpszA = szMailbox;
// Next, the server name.
ZeroMemory(&rgval[1], sizeof(SPropValue) );
rgval[1].ulPropTag = PR_PROFILE_UNRESOLVED_SERVER;
rgval[1].Value.lpszA = szServer;
// For NT Services, need to do this to keep MAPI from
// displaying dialog boxes.
ZeroMemory(&rgval[2], sizeof(SPropValue) );
rgval[2].ulPropTag = PR_CONVERSION_PROHIBITED; //As the com application is executed by the NT service, this parameter is specified.
rgval[2].Value.b = TRUE;
Also note, prior to ConfigureMsgService function call, all the other MAPI calls such as MAPIInitialize, MAPIAdminProfiles, CreateProfile, AdminServices, CreateMsgService, GetMsgServiceTable etc are succeeded.
My question, the same code was working properly with Outlook 2007 environment, but it failed in Outlook 2007 SP2 environment.
Please note,
1. when the same code is executed from a stand-alone application, it worked fine.
2. The code didn't work properly if the service is executed as a Local System account or as a network service account.
What could be the problem? Am I missing some thing.
Is there any work-around is available?
Thanks in advance
Saravanan
Your problem is in #2 of your note:
Please note, 1. when the same code is
executed from a stand-alone
application, it worked fine. 2. The
code didn't work properly if the
service is executed as a Local System
account or as a network service
account.
MAPI profiles are stored in the current user's hive* in the registry (HKEY_CURRENT_USER and HKEY_USERS{user SID}). The system accounts (LocalSystem and NetworkService) don't present a user hive which MAPI needs to write the profile information.
The easiest fix is to have your service run under a user account which has been granted the Log On As Service right. Depending on how your COM app is run as (in proc vs out of proc) you may be able to have it run as a specific user instead of a system account.
*Hive is the term used for the different sections of the registry. Here we're just dealing with the user's own section of the registry.
Thanks for your reply.
I tried your idea, but it doesn't worked. I spoke to Microsoft in this case, they have provided a fix for this issue(http://support.microsoft.com/kb/972363), it fixed it.
Saravanan