I am having simple question.
I installed PIA Office 15.0 for outllook and gave reference in my winform .net application.
I just wanted to know if I deploy this application on machine which is having lower version of outlook(e.g. outlook 2007/2010) will my application work properly?
Sorry it is 14.0 outlook PIA refernece given by me to my app. and code is
` Dim OutlookMessage As outlook.MailItem
Dim AppOutlook As New outlook.Application
Try
Dim oApp As Microsoft.Office.Interop.Outlook._Application
oApp = New Microsoft.Office.Interop.Outlook.Application
Dim oMsg As Microsoft.Office.Interop.Outlook._MailItem
oMsg = oApp.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem)
oMsg.Subject = P_Subj
oMsg.Body = P_Body
oMsg.To = P_To
'oMsg.CC = sCC
If Trim(P_AttachPath) <> "" Then
Dim sBodyLen As Integer = Int(P_Body.Length)
Dim oAttachs As Microsoft.Office.Interop.Outlook.Attachments = oMsg.Attachments
Dim oAttach As Microsoft.Office.Interop.Outlook.Attachment
oAttach = oAttachs.Add(P_AttachPath, , sBodyLen, P_AttachPath)
End If
oMsg.Send()
MsgBox("Mail sent to outlook successfully. ", MsgBoxStyle.Information, "")
oApp = Nothing
oMsg = Nothing '
it is giving error for office 2007.
I'd recommend using PIAs that correspond to the lowest version of Outlook/Office. Thus, you can be sure that you don't use methods and properties introduced in later versions. In general, if you embed interop types (read more below) it will run without issues.
Beginning with the .NET Framework 4, the common language runtime supports embedding type information for COM types directly into managed assemblies, instead of requiring the managed assemblies to obtain type information for COM types from interop assemblies. Because the embedded type information includes only the types and members that are actually used by a managed assembly, two managed assemblies might have very different views of the same COM type. Each managed assembly has a different Type object to represent its view of the COM type. The common language runtime supports type equivalence between these different views for interfaces, structures, enumerations, and delegates. You can read more about that in the Type Equivalence and Embedded Interop Types article in MSDN.
Also see Walkthrough: Embedding Types from Managed Assemblies (C# and Visual Basic).
I have been using the Microsoft Office 2010: Primary Interop Assemblies Redistributable in several of my applications, and I can report that deployment on Windows 8.1/8/7 running Office 2013/2010 is flawless. I have also had some success deploying to XP machines running Office 2003, but this is not guaranteed.
The 2010 PIA Redistributable is available for download at http://www.microsoft.com/en-us/download/details.aspx?id=3508
Related
Scenario:
My company has a legacy (read that as 32 bit) windows form application that will be around for quite some time in the future. This application uses an embedded web browser control that is supplied pages that are contained within the database that it maintains. It was built like this so we could extend/modify as needed. I say this so that I can validate that security is not a concern. Only the application and developers with the correct tools have access to the pages or database. The application is only available inside the office.
There are some processes that I need to accomplish using ActiveX objects that are embedded within the pages/application. One of the biggest and most annoying thing that happens is the ActiveX security warning when I got to create instances of things like “scripting.filesystemobject”. Example:
Set oFSO = CreateObject("Scripting.FileSystemObject")
My solution is to create a DLL that is installed locally on each machine that needs access to the extended functions, have the all the functions (whole DLL ??) marked as safe so that the web browser control does not present the security warning. I have been searching using google and came across very few examples, and all of which are in C# which is not my strongest language.
I’ve had to convert from C to Vb.Net visual basic to get what I have now. When I go to register my DLL, I get the following error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>regasm
Z:\VBNet2017\APIInternal\APIInternal\bin\Debug\APIinternal.dll /tlb
Microsoft .NET Framework Assembly Registration Utility version 4.8.4084.0
for Microsoft .NET Framework version 4.8.4084.0
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
RegAsm : error RA0000 : Type 'APIInternal.API.Accupay' has an invalid default COM
interface: 'APIInternal.API.Accupay'
UPDATE: Thank you Hans; the error is gone. I've also made some changes in the source code; I changed the ProgID to something that closely resembles where and what this is for. I'm still having issues in creating the object in VB Script.
This is the output from the current version of the code. This is the code, stripped down for clarity:
Option Strict On
Imports System.Runtime.InteropServices
Imports System.IO
Namespace API
Public Interface IAccupay
<DispId(1)>
Function GetFiles(ByVal Folder As String) As List(Of String)
End Interface
<Guid("8B4B5CEF-8B3A-49A1-9053-E909F82D9E73"),
ProgId("AddIn.Accupay"), ClassInterface(ClassInterfaceType.None),
ComDefaultInterface(GetType(IAccupay)), ComVisible(True)>
Public Class Accupay
Implements IAccupay
Private Function GetFiles(Folder As String) As List(Of String) Implements IAccupay.GetFiles
Return Directory.GetFiles(Folder).ToList
End Function
End Class
I have tried just about every combination of ProgID, Name space, Interface name and class name to get this error to go away without any luck. I do know there are other elements that need to be addressed or added, such as error trapping and, if I’m not mistaken, how to actually implement the ObjectSafetyOption which I still don’t know how to do.
I have been using the Guide at the bottom of this article:
Is it possible to mark an ActiveX object as safe so that IE settings need not be changed?, the second answer, but I haven’t had any success.
Please, can someone point me in the right direction, maybe show me what’s wrong with the code that I have and how to physically implement the ObjectSafteyOption that is needed for the web control. Links, additional reading, code examples or comments on how to get this fixed and working would really be appreciated.
Thank you for reading and any help you send my way, Fred
PS: If you need more information, or have a better solution, please don’t hesitate to reply or comment.
UPDATE:
With the code that I have now, I am able to access the DLL in VB.Net visual basic:
Imports System
Imports APIInternal.API
Module Program
Sub Main(args As String())
Dim API As New Accupay
Dim FileList = API.GetFiles("C:\Windows\")
For Each Item As String In FileList
Console.WriteLine(Item)
Next
End Sub
End Module
However, I still can't seem to get the correct calling for a VB Script/html page:
Set Test = CreateObject("Test.Accupay")
Which returns the VB Script error "ActiveX Component can't create object: Test.Accupay or any other iteration of the parts of the name that I tried. I think part of this is that I don't understand how the creation of the project leads to the creation of the object in a com base environment like VB Script.
Fred
The answer to this problem is two fold: You must target the correct platform (X86) AND use the 32 bit version of regasm. Once I realized this was the issue, I was able to create the DLL and use it's functions in the Web Browser control without the active X warning. One example is I can now open the default browser (in this case, NOT IE/EDGE) from a link within the WB Control and another is to get the contents of a folder for further processing within the WB page.
I have code to generate an email based on data on a userform.
It worked for a long time across multiple machines, but when I changed machines it started throwing a run-time error 13 type mismatch on on the CreateItemFromTemplate method in the following section:
Private Sub AcaoEnviar_Click()
Dim OutlookApp As New Outlook.Application
Dim EmailKRI As Outlook.MailItem
Set EmailKRI = OutlookApp.CreateItemFromTemplate(PATH_EMAIL_TEMPLATE)
The code still runs on other machines, suggesting the problem is local. My Outlook library is the same as on the other machines, and the only difference I´m aware of is that I´m running it on a 64-bit system and 32-bit office, while most others have 32-bit systems (one other has the same 64-bit setup and runs fine).
Changing the object declaration from Outlook.MailItem to Object seems to solve the problem, which I think eliminates problems with Outlook's programmatic access, and in any case, my Antivirus status is valid.
I'm still confused as to why such an error would occur only with me.
Is there any solution so that I can go back to early binding for that email object?
You will get that error if CreateItemFromTemplate returns something other than MailItem object. Are you sure the OFT file is for a regular mail item.
As a test, declare EmailKRI as a generic Obejct and at run time check the value of the EmailKRI.Class property. It is supposed to be 43 (OlObjectClass.olMail) for the regular MailItem objects.
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 have an excel Macro that uses a webservice to authenticate if the user of the Excel is a valid user or not.
I declare my required objects as follows:
Dim ObjHTTP As New XMLHTTP
Dim xml As New MSXML2.DOMDocument
When I send this file to my end users, some of them get an error saying XMLHTTP is undefined. Using XMLHTTP60 and MSXML2.DOMDocument60 works for them
Is there a way to auto detect the correct ones available on the end user machine ?
Thanks
tldr: Use late binding.
You are currently using Early Binding which means you have the appropriate library loaded in your references. If the other person does not have that library, then the code will fail as you have seen.
Late Binding loses all the autocomplete hints you get with the reference loaded, but it means the reference can be loaded dynamically on another machine.
Your code would become:
Dim ObjHTTP As Object
Dim xml As Object
Set ObjHTTP = CreateObject("XMLHTTP")
Set xml = CreateObject("MSXML2.DOMDocument")
The rest of the code would remain the same, and the overhead of dynamically loading the library is so small as to be unworthy of optimization
I'd recommend using the XMLHTTP60, DOMDocument60, etc. ProgIDs unless you have to support Windows XP. MSXML 6.0 is included with .NET 3.0 and later, and Windows 7 includes .NET 3.5, so all semi-recent Windows installations will have MSXML6 installed.
I believe when you use the ProgIDs without specifying a version you get MSXML 3.0, which is pretty old by now (circa 2000).
Edit: according to Wikipedia MSXML 6.0 ships with XP SP3, so there really isn't a good reason to still be using 3.
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!