/****************************** Module Header ******************************\
Module Name: SimpleObject.h
Project:     CppDllCOMServer
Copyright (c) Microsoft Corporation.

This source is subject to the Microsoft Public License.
See https://www.microsoft.com/en-us/openness/resources/licenses.aspx#MPL.
All other rights reserved.

THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
\***************************************************************************/

#pragma once

#include 
#include "CppDllCOMServer_h.h" 

class SimpleObject : public ISimpleObject
{
public:
// IUnknown
IFACEMETHODIMP QueryInterface(REFIID riid, void **ppv);
IFACEMETHODIMP_(ULONG) AddRef();
IFACEMETHODIMP_(ULONG) Release();

// IDispatch
IFACEMETHODIMP GetTypeInfoCount(UINT *pctinfo);
IFACEMETHODIMP GetTypeInfo(UINT itinfo, LCID lcid, ITypeInfo **pptinfo);
IFACEMETHODIMP GetIDsOfNames(REFIID riid, LPOLESTR *rgszNames, UINT cNames, LCID lcid, DISPID* rgdispid);
IFACEMETHODIMP Invoke(DISPID dispidMember, REFIID riid, LCID lcid, WORD wFlags, DISPPARAMS *pdispParams,   
                      VARIANT *pvarResult, EXCEPINFO *pExcepInfo, UINT *puArgErr);

// ISimpleObject
IFACEMETHODIMP get_FloatProperty(FLOAT *pVal);
IFACEMETHODIMP put_FloatProperty(FLOAT newVal);
IFACEMETHODIMP HelloWorld(BSTR *pRet);
IFACEMETHODIMP GetProcessThreadID(LONG *pdwProcessId, LONG *pdwThreadId);

SimpleObject();

Sub test()
Dim comObj As CppDllCOMServerLib.SimpleObject
Set comObj = New SimpleObject

Debug.Print comObj.HelloWorld

End Sub

#include 
#include 
namespace SimplePInvokeDLL
{
  #import "C:\\..\\C++ COM DLL\Debug\\CppDllCOMServer.dll"
  using namespace CppDllCOMServerLib;
  extern "C"
  {
   __declspec(dllexport) int __stdcall API_DummyCOMCall(ISimpleObject* iso);
   // Returns random number
   __declspec(dllexport) long API_DummyCall();
  }
}

#include "stdafx.h"
#include "Pinvoke_CppDllCOMServer.h"
#include <stdlib.h> 
#include <time.h>  

using namespace std;
namespace SimplePInvokeDLL
{
  __declspec(dllexport) long SimplePInvokeDLL::API_DummyCall()
 {
  /* initialize random seed: */
  srand(GetTickCount());

  /* generate a random number*/
  return rand();
 }

 __declspec(dllexport) int __stdcall API_DummyCOMCall(ISimpleObject* iso)
 {
  //_bstr_t Class  https://msdn.microsoft.com/en-us/library/zthfhkd6.aspx
  /*
  A _bstr_t object encapsulates the BSTR data type. The class manages resource
  allocation and deallocation through function calls to SysAllocString and SysFreeString
  and other BSTR APIs when appropriate. The _bstr_t class uses reference counting to
  avoid excessive overhead.
  */
		
  _bstr_t strComResult = iso->HelloWorld();
  _bstr_t strLocal = _bstr_t(L"HelloWorld");
 
  return strComResult == strLocal;
 }
}

Declare Function API_DummyCOMCall Lib "C:\...\Debug\Pinvoke_CppDllCOMServer.dll" _
                (simpleObj As CppDllCOMServerLib.SimpleObject) As Integer

Sub test()

Dim comObj As CppDllCOMServerLib.SimpleObject
Set comObj = New SimpleObject

Debug.Print comObj.HelloWorld

Debug.Print API_DummyCOMCall(comObj)

End Sub

Declare Function API_DummyCOMCall Lib "C:\...\Debug\Pinvoke_CppDllCOMServer.dll" _
                (ByVal simpleObj As LongPtr) As Integer

Sub test()

Dim comObj As CppDllCOMServerLib.SimpleObject
Set comObj = New SimpleObject

Debug.Print comObj.HelloWorld

Debug.Print API_DummyCOMCall(ObjPtr(comObj))

End Sub

Declare Function API_DummyCOMCall Lib "C:\...\Debug\Pinvoke_CppDllCOMServer.dll" _
                 Alias "_API_DummyCOMCall@4"(ByVal simpleObj As LongPtr) As Integer

Sub test()

Dim comObj As CppDllCOMServerLib.SimpleObject
Set comObj = New SimpleObject

Debug.Print comObj.HelloWorld

Debug.Print API_DummyCOMCall(ObjPtr(comObj))

End Sub

DISCLAIMER:

Please note that the code I have offered is just a proof of concept and should not be put into 
production without a thorough testing! 

Microsoft is not responsible if your users will lose data because of this programming solution. 
It’s your responsibility to test it before deployment in your organization.

THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR 
FITNESS FOR A PARTICULAR PURPOSE.

We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and
distribute the object code form of the Sample Code, provided that. You agree: 
(i) to not use Our name, logo, or trademarks to market Your software product in which the Sample Code 
is embedded; 
(ii) to include a valid copyright notice on Your software product in which the Sample Code is embedded;
and 
(iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits,
including attorneys’ fees, that arise or result from the use or distribution of the Sample Code.

openssl genrsa -out "C:\OpenSSL\Test_CertAuthority.key" 4096

openssl req -new -x509 
        -days 365
        -key "C:\OpenSSL\Test_CertAuthority.key"
        -out "C:\OpenSSL\Test_CertAuthority.crt"
        -config "C:\OpenSSL-Win32\bin\openssl.cfg"

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TestMS
Organizational Unit Name (eg, section) []:TestOrgUnit
Common Name (e.g. server FQDN or YOUR name) []:CristiB
Email Address []:cristib@microsoft.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

openssl genrsa -out "C:\OpenSSL\Test_IntermediateCertAuthority.key" 4096

openssl req -new
        -key "C:\OpenSSL\Test_IntermediateCertAuthority.key" 
        -out "C:\OpenSSL\Test_IntermediateCertAuthority.csr"
        -config "C:\OpenSSL-Win32\bin\openssl.cfg"

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:TestMS
Organizational Unit Name (eg, section) []:TestOrgUnit_IntermediateAuthority
Common Name (e.g. server FQDN or YOUR name) []:CristiB_IntermediateAuthority
Email Address []:cristib@microsoft.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

openssl x509 -req 
        -days 365
        -in "C:\OpenSSL\Test_IntermediateCertAuthority.csr" 
        -CA "C:\OpenSSL\Test_CertAuthority.crt"
        -CAkey "C:\OpenSSL\Test_CertAuthority.key" 
        -set_serial 01
        -sha256
        -out "C:\OpenSSL\Test_IntermediateCertAuthority.crt"

openssl pkcs12 -export
        -out "C:\OpenSSL\SHA2_IA_Cert.p12" 
        -inkey "C:\OpenSSL\Test_IntermediateCertAuthority.key"
        -in "C:\OpenSSL\Test_IntermediateCertAuthority.cer" 
        -chain -CAfile "C:\OpenSSL\Test_CertAuthority.crt" 
        -passout pass:123456 
        -name My_SHA2_Cert

signtool sign /v /t https://timestamp.verisign.com/scripts/timestamp.dll
         /f "C:\OpenSSL\SHA2_IA_Cert.p12" 
         /p 123456 
         MSI_Signed_Installer.msi 

signtool sign /v /t https://timestamp.verisign.com/scripts/timestamp.dll
         /f "C:\OpenSSL\SHA2_IA_Cert.p12" 
         /p 123456 
         Setup.exe

signtool verify /v /a setup.exe

Note:  It is very important to deploy your certificates in the correct place. Double-clicking on them will
           get them installed into your Local User's store which is not going to be seen by AppLocker.
           If you're not careful, you might spend hours troubleshooting Rules that would otherwise work
           perfectly fine.  

           For AppLocker to work properly and let you block .MSI installers based on Publishers, you will
           have to deploy any certificate referenced in your Rules into the Local Computer store.

Note:  For the following steps you will need to be logged on using an Administrative account.

Note:  AppLocker only applies to normal user accounts, so members of the Administrators group will
          not be blocked from running any MSI installers!

Note:  In case you haven't installed the root CA and intermediate CA, the AppLocker Wizard will
           display the following error when you will attempt to browse for a .MSI file:
 
The publisher information cannot be extracted from the specified file <path>. Reason: The object identifier does not represent a valid object. (Exception from HRESULT: 0x800710D8);

The system administrator has set policies to prevent this installation.

The installation of <MSI package> is not permitted by software restriction
policy. The Windows Installer only allows installation of unrestricted
items. The authorization level returned by software restriction policy was
0x0.

Understanding AppLocker Rules (LINK)
-------------------------------------------------------------------

[...]

AppLocker rule behavior

If no AppLocker rules for a specific rule collection exist, all files
with that file format are allowed to run. However, when an AppLocker
rule for a specific rule collection is created, only the files
explicitly allowed in a rule are permitted to run. For example, if you
create an executable rule that allows .exe files in
%SystemDrive%\FilePath to run, only executable files located in that
path are allowed to run.

A rule can be configured to use either an allow or deny action:

• Allow. You can specify which files are allowed to run in your
  environment and for which users or groups of users. You can also
  configure exceptions to identify files that are excluded from the
  rule.
  
• Deny. You can specify which files are not allowed to run in your
  environment and for which users or groups of users. You can also
  configure exceptions to identify files that are excluded from the
  rule.

 [...]

 "Data provider could not be initialized"  

   CREATE PROCEDURE TestSP_SQLServer
    AS
    BEGIN
     SET NOCOUNT ON;
     SELECT * FROM dbo.tblSourceData;
    END
    GO

Sub Test()

Dim o_rs          As New ADODB.Recordset
Dim connectionStr As String
Dim connection    As ADODB.connection
Dim cmd           As ADODB.Command

'https://msdn.microsoft.com/en-us/library/ms130822.aspx (Using Connection
'String Keywords with SQL Server Native Client)

connectionStr = "Provider=SQLNCLI11.1;" & _
                "Server=CRISTISQL2;" & _
                "Initial Catalog=TestStoredProcedure;" & _
                "User ID=sa;" & _
                "Password=123;"

Set connection = New ADODB.connection
connection.ConnectionString = connectionStr
connection.Open

Set cmd = New ADODB.Command
cmd.ActiveConnection = connection
cmd.CommandType = adCmdStoredProc
cmd.CommandText = "TestSP_SQLServer"

Set o_rs = New ADODB.Recordset

'https://www.access-programmers.co.uk/forums/showthread.php?t=62482
'the following line is needed to avoid a runtime error when attempting
'to programmatically bind the Form to the 'o_rs' RecordSet object:
'_________________________________________________________________
' Run-time error '7965':
' The object you entered is not a valid Recordset property.
'_________________________________________________________________

o_rs.CursorLocation = adUseClient

o_rs.Open "TestSP_SQLServer", connection, adOpenKeyset, adLockOptimistic

DoCmd.OpenForm "frmSQL_StoredProc_SourceData", acFormDS, , , acFormEdit, acWindowNormal

Set [Form_frmSQL_StoredProc_SourceData].Recordset = o_rs
DoCmd.OpenForm "frmSQL_StoredProc_SourceData", acFormDS

'-------------------------------------------------------------------------
'Display the data we fetched from SQL in the VBA Immediate window:

Dim item_fld As Variant
Dim strCols As String
strCols = ""
For Each item_fld In o_rs.Fields
    strCols = strCols & item_fld.Name & vbTab
Next
Debug.Print strCols

Dim strItems As String
strItems = ""
Do While Not o_rs.EOF
    strItems = o_rs(0).Value & vbTab & o_rs(1).Value & vbTab & o_rs(2).Value
    Debug.Print strItems
    strItems = ""
    o_rs.MoveNext
Loop

End Sub

https://msdn.microsoft.com/en-us/library/aa261340(v=vs.60).aspx

ADO Compared with RDO and DAO
------------------------------------------------------------------------------

ADO isn't automatically code-compatible with your existing data access applications. While ADO encapsulates the functionality of DAO and RDO, you must convert many of the language elements over to ADO syntax. In some cases, this will mean only a simple conversion of some functions of your existing code. In other cases, it might be best to rewrite the application using ADO's new features.

DAO (Data Access Objects) was the first object-oriented interface that exposed the Microsoft Jet database engine (used by Microsoft Access) and allowed Visual Basic developers to directly connect to Access tables - as well as other databases - through ODBC. DAO is suited best for either single-system applications or for small, local deployments.

RDO (Remote Data Objects) is an object-oriented data access interface to ODBC combined with the easy-to-use style of DAO, providing an interface that exposes virtually all of ODBC�s low-level power and flexibility. RDO is limited, though, in that it doesn't access Jet or ISAM databases very well, and that it can access relational databases only through existing ODBC drivers. However, RDO has proven to be the interface of choice for a large number of SQL Server, Oracle, and other large relational database developers. RDO provides the objects, properties, and methods needed to access the more complex aspects of stored procedures and complex resultsets.

ADO is the successor to DAO/RDO. Functionally ADO 2.0 is most similar to RDO, and there's generally a similar mapping between the two models. ADO "flattens" the object model used by DAO and RDO, meaning that it contains fewer objects and more properties, methods (and arguments), and events. For example, ADO has no equivalents to the rdoEngine and rdoEnvironment objects, which exposed the ODBC driver manager and hEnv interfaces. Nor can you currently create ODBC data sources from ADO, despite the fact that your interface might be through the ODBC OLE DB service provider.

Much of the functionality contained in the DAO and RDO models was consolidated into single objects, making for a much simpler object model. Because of this, however, you might initially find it difficult to find the appropriate ADO object, collection, property, method, or event. Unlike DAO and RDO, although ADO objects are hierarchical, they are also creatable outside the scope of the hierarchy.

It should be noted, however, that ADO currently doesn't support all of DAO's functionality. ADO mostly includes RDO-style functionality to interact with OLE DB data sources, plus remoting and DHTML technology.

In general, it's probably too early in the evolution of ADO to migrate most DAO applications (except possibly ones using ODBCDirect) to ADO right now, since ADO doesn't currently support data definition (DDL), users, groups, and so forth. If you use DAO only for client-server applications and don't rely on the Jet database engine or use DDL, however, then you can probably migrate to ADO now. Eventually, Microsoft will provide an ADO DDL component to aid in DAO-to-ADO migration and provide generic DDL support for OLE DB providers.

USE TestStoredProcedure
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE TestSP_SQLServer2
                 @strSqlOutputTempTableName NVARCHAR(100),
                 @strSqlSourceTableName NVARCHAR(100)
AS
BEGIN
 DECLARE @SQLQuery NVARCHAR(100);
 DECLARE @NewLineChar AS CHAR(2) = CHAR(13) + CHAR(10)
 SET nocount on

 SET @SQLQuery = 'SELECT * INTO ' + 
                 CAST(@strTmpOutputTableName As NVARCHAR) + @NewLineChar +
                 'FROM ' + CAST(@strSourceTableName As NVARCHAR) + ';'
 PRINT @SQLQuery
 EXEC (@SQLQuery)
 -- EXEC parameter needs to be enclosed in "( )", else we get this error:
 -- "Could not find stored procedure 'CREATE TABLE ..."

END

exec dbo.TestSP_SQLServer2 @strTmpOutputTableName = 'tmpTbl',
                                                  @strSourceTableName        = 'tblSourceData';

Dim oShell As Object

Set oShell = CreateObject("WScript.Shell")

strSqlOutputTempTableName = "tmp_" & _ 
Replace(oShell.ExpandEnvironmentStrings("%ComputerName%"), "-", "_") & "_" & _
Format(Now, "yyyymmddhhms")

Set oShell = Nothing

Module1
---------------------------------------------------------------------------------
Sub Execute_SQL_StoredProc(strSqlStoredProcName As String,
                           strSqlOutputTempTableName As String,  
                           strSqlSourceTableName As String)

Dim m_cnnStr        As String
Dim m_cnn           As New ADODB.Connection
Dim m_cmd           As New ADODB.Command
Dim m_rst           As New ADODB.Recordset
Dim tmpRowsAffected As Long

'SQL Native Client 2012
'----------------------------------------------------------------
m_cnnStr = "Provider=SQLNCLI11.1;" & _
           "Data Source=CRISTISQL2;" & _
           "Persist Security Info=False;" & _
           "Initial Catalog=TestStoredProcedure;" & _
           "User ID=sa;" & _
           "Password=123;"

'"Integrated Security=false;" https://support.microsoft.com/kb/269495

'When you try to open an ActiveX Data Objects (ADO) connection, you may receive
'the following error message:
' > Run-time error '-2147217887 (80040e21):'
' > Multiple-step OLE DB operation generated errors. Check each OLE DB
'   status value, if available. No work was done.
'----------------------------------------------------------------

m_cnn.Open m_cnnStr
m_cmd.ActiveConnection = m_cnn 

m_cmd.CommandText = strSqlStoredProcName
m_cmd.CommandType = adCmdStoredProc

'https://msdn.microsoft.com/en-us/library/windows/desktop/ms675318(v=vs.85).aspx
- DataTypeEnum

'https://msdn.microsoft.com/en-us/library/windows/desktop/ms677209(v=vs.85).aspx
- CreateParameter Method (ADO) 

m_cmd.Parameters.Append m_cmd.CreateParameter("@strSqlOutputTempTableName",
                                              adWChar, 
                                              adParamInput,
                                              100,
                                              strSqlOutputTempTableName)

m_cmd.Parameters.Append m_cmd.CreateParameter("@strSqlSourceTableName", 
                                              adWChar, 
                                              adParamInput,
                                              100,
                                              strSqlSourceTableName)

m_cmd.Execute tmpRowsAffected     

'https://support.microsoft.com/kb/195048 - How To Determine Number of Records Affected by an ADO UPDATE

Debug.Print vbNewLine
Debug.Print "[Execute_SQL_StoredProc] SQL stored procedure completed."
Debug.Print " > SQL StoredProc name:        " & strSqlStoredProcName
Debug.Print " > SQL output Temp table name: " & strSqlOutputTempTableName
Debug.Print " > SQL source table name:      " & strSqlSourceTableName
Debug.Print " > Rows affected:              " & tmpRowsAffected

End Sub

Module1
---------------------------------------------------------------------------------
Sub CreateLocal_SQL_TempLinkedTable(strSqlOutputTempTableName As String)

If Len(strSqlOutputTempTableName) = 0 Then
    MsgBox "Error![CreateLocal_SQL_TempLinkedTable] function didn't receive" & _ 
           "a valid SQL server table name!"
    Exit Sub
End If

Dim dbCurr As Database, dbLink As Database
Dim tdfLocal As TableDef

'https://support.microsoft.com/kb/892490 How to create a DSN-less connection to SQL Server for linked tables in Access

Dim td               As TableDef
Dim stConnect        As String

Dim stLocalTableName As String 'Name of the table that you are creating in
                               'the local Access database

Dim stRemoteTableName As String 'Name of the table that you are linking to on
                                'the SQL Server database

stLocalTableName  = strSqlOutputTempTableName & "_ExternalLink"
stRemoteTableName = strSqlOutputTempTableName 

'delete any existing linked SQL tables

For Each td In CurrentDb.TableDefs
    Debug.Print "  > Checking table [" & td.Name & "] .."

    If td.Name = stLocalTableName Then
       Debug.Print "    Table found and deleted!"
       CurrentDb.TableDefs.Delete stLocalTableName
    End If
Next 

'//WARNING: This will save the username and the password with the linked table
information.

'SQL Native Client 2012
'----------------------------------------------------------------

stConnect = "ODBC;DRIVER=SQL Server Native Client 11.0;" & _
            "SERVER=CRISTISQL2;" & _
            "APP=Microsoft Office 2013;" & _
            "DATABASE=TestStoredProcedure;" & _
            "User ID=sa;" & _
            "Password=123;"

'Microsoft OLEDB Provider for SQL Server
'----------------------------------------------------------------
'stConnect = "ODBC;DRIVER=SQL Server;" & _
'            "SERVER=CRISTISQL2;" & _
'            "DATABASE=TestStoredProcedure;" & _
'            "UID=sa;" & _
'            "PWD=123;"

Set td = CurrentDb.CreateTableDef(stLocalTableName, 
                                  dbAttachSavePWD, 
                                  stRemoteTableName,
                                  stConnect)

CurrentDb.TableDefs.Append td

Set Form_frmSQL_StoredProc_SourceData.Recordset =
CurrentDb.TableDefs(stLocalTableName).OpenRecordset

Set td = Nothing

End Sub

Form_frmSQL_StoredProc_SourceData
---------------------------------------------------------------------------------
Option Compare Database

Private strSqlOutputTempTableName As String

Private Sub Form_Close()
  DoCmd.DeleteObject acTable, strSqlOutputTempTableName & "_ExternalLink"
End Sub

Private Sub Form_Load()

Dim oShell As Object
Set oShell = CreateObject("WScript.Shell")

strSqlOutputTempTableName = "tmp_" & _
Replace(oShell.ExpandEnvironmentStrings("%ComputerName%"), "-", "_") & "_" & _
Format(Now, "yyyymmddhhms")

Set oShell = Nothing

Execute_SQL_StoredProc "dbo.TestSP_SQLServer2",
                       strSqlOutputTempTableName,
                       "tblSourceData"

CreateLocal_SQL_TempLinkedTable strSqlOutputTempTableName

End Sub

'DISCLAIMER:

Please note that the code I have offered is just a proof of concept and should not be put into
production without a thorough testing!

Microsoft is not responsible if your users will lose data because of this programming solution.
It’s your responsibility to test it before deployment in your organization.

THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object code form of the Sample Code, provided that. You agree:
(i) to not use Our name, logo, or trademarks to market Your software product in which the Sample Code is embedded;
(ii) to include a valid copyright notice on Your software product in which the Sample Code is embedded; and
(iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits, including attorneys’ fees, that arise or result from the use or distribution of the Sample Code.

Deploying a VSTO 2003 add-in is a little more complicated than the 2007 and 2010 versions. This is because VSTO 2003 solutions require explicit code execution permissions to be assigned using the CASPOL tool, otherwise they will fail to load.

First we need to build a very simple Word 2003 add-in project.    

1.  Open 'Visual Studio 2008';
2.  Go to 'File' > 'New' > 'Project';
3.  In 'Project Types' > go to 'Visual C#' > 'Office' > '2003' and select 'Word 2003 Add-in';
4.  Choose a Name and a Location for the project, then click 'OK';
5.  Insert the following code in 'ThisAddIn.cs':

 
Customizing the deployment project

As you might have noticed, the Visual Studio wizard already built a Setup Project for our add-in Solution. If we take a look at its Properties, we'll notice that the add-in is already selected as 'Primary Output'.

The next thing we need to check are the Registry settings: right-click on the Setup project from 'Solution Explorer' view, select 'View' > 'Registry'. 

 If we dump the key structure in Notepad, it will look like this:

Manually granting CASPOL access to our solution  

The article https://msdn.microsoft.com/en-us/library/6exya3kf.aspx (Security Requirements to Run Office Solutions (2003 System)) states that Application-level and Document-level 2003 solutions will require full trust permission in .Net Framework .. 

We can manually grant full trust permission to our add-in using these steps: 

How to: Grant Permissions to Folders and Assemblies (2003 System)https://msdn.microsoft.com/en-us/library/zdc263t0.aspx ======================================================================= [..] The following procedures grant full trust permissions to an assembly or folder in a Visual Studio Tools for Office solution. Normally, you grant permissions to a specific assembly. If you have several assemblies, and you are certain that the location is secure, you can grant full trust to the folder where the assemblies are located. If you grant trust to the folder, all the assemblies in that folder and its subfolders are also trusted.  There are three ways to grant permissions to folders and assemblies in Office solutions: Using the Trust Assemblies Location property in Visual Studio. (Useful only during development.) The Trust Assemblies Location property only works during development; it has no effect on end users. For this reason, you cannot use this method for deployment. For more information, see Properties in Visual Studio Tools for Office Projects. Using the Microsoft .NET Framework 2.0 Configuration tool. This tool provides a graphical user interface for working with security policy. It is not included with Visual Studio 2008. You can download the tool as part of the .NET Framework 2.0 SDK from the Microsoft Download Center. For an example, see .NET Framework 2.0 Software Development Kit (SDK) (x86). Using the Code Access Security Policy tool (Caspol.exe). This tool is a command-line interface for working with security policy.  [..] Using the .NET Framework 2.0 Configuration Tool    To install this tool, download and install the .NET Framework 2.0 Software   Development Kit (SDK) from the Microsoft Download Center.    The procedure to follow depends on where the assembly or folder is located:           > On your local computer.      > On another computer on a network (or a mapped drive). To grant full trust to an assembly or folder on your local computer  1. In Control Panel, open Administrative Tools.  2. Run Microsoft .NET Framework 2.0 Configuration.   Note:   There might be several similar tools with names that start with     Microsoft .NET Framework. Ensure that the configuration tool you   use matches your version of the runtime.  3. In the treeview on the left side, expand .NET Framework 2.0 Configuration,     expand My Computer, expand Runtime Security Policy, expand User,     expand Code Groups, expand All_Code, and then expand VSTOProjects.   Note:   If you have not compiled a Visual Studio Tools for Office project   before, you will not have the VSTOProjects folder. You can add the   new code group to the All_Code root node, or you can compile a Visual   Studio Tools for Office project to have the VSTOProjects folder created   automatically.   On the right is the VSTOProjects Code Group description, which has a Tasks section at the bottom of the page.  4. In the Tasks section, click Add a Child Code Group.The Create Code     Group wizard starts.  5. Select Create a new code group, and type a name and description that     will help you identify the project. Click Next.  6. In the Choose the condition type for this code group list, click URL.  7. In the URL box, type the full path to the assembly, or the path to the     bin folder of the project followed by an asterisk (for example,     c:\path\ExcelApplication1.dll or c:\path\ExcelApplication1\bin\*).     Click Next.  Note:   If you type the path to the bin folder, all assemblies in that folder and   all its subfolders are granted full trust on your computer. Ensure that no   unauthorized people have access to folders that are fully trusted, or   someone could put a malicious assembly in the folder and the assembly would   run with full trust.  Caution:   Do not grant permissions to an entire hard disk (such as C:\*) or to general   folders such as My Documents, because you might grant permissions to cached   assemblies from the Internet or from e-mail messages. Only grant permissions   to specific project folders that contain assemblies you know are safe to     run.  9. Select Use existing permission set, and then select FullTrust from the      list.  10. Click Next.  11. Click Finish. [..] Using the Code Access Security Policy Tool (Caspol.exe) You can also grant full trust to a folder from a command prompt by using the Code Access Security Policy tool (Caspol.exe). For more information about Caspol.exe, see Code Access Security Policy Tool (Caspol.exe). You can grant trust to a folder on your local computer at the User level with normal user permissions. To grant trust to a network location, you must have administrator privileges and change the security policy  at the Machine level. The Machine policy level acts independently of the User policy level, and the Machine policy level does not grant full trust to the Intranet zone even if the User policy does. The policy levels must agree.   Tip: Type the commands manually. Copying and pasting the commands into the command prompt might result in Unknown Option errors. To grant full trust to a local folder   > Type the following command at the Visual Studio Command Prompt.   caspol -u -ag All_Code -url C:\<FolderName>\<FolderName>\* FullTrust   -n "<Name>" -d "<Description>" [..] For more information, see How to: Add Code Groups Using Caspol.exe. Note:   After policy is deployed, everyone that is affected by the policy change    must quit and then restart all Office applications used in the solution   before the policy changes are enforced. If Microsoft Office Word is part of   the solution, users must also quit and restart Microsoft Office Outlook.   Also, if a user has opened a document or workbook in Internet Explorer, the   process could still be running. Check Windows Task Manager to ensure there   are no instances of the Office application. Other applications that host   Office applications can also prevent the new permissions from being   enforced. Users should quit all applications that use Office, hosted or   stand-alone, when security policies are changed.

 
Here is how my .NET Framework 2.0 Configuration console looks like:

If you don't feel like downloading the entire .NET SDK to be able to use this tool (while the add-in is still under development and you need to experiment with CASPOL permissions), you may download MSCORCFG.MSC from here: https://blogs.msdn.com/b/astebner/archive/2006/01/23/516671.aspx. Once you run the setup project, the tool found at "C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\mscorcfg.msc" or at "C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorcfg.msc".

If you prefer the command-line version, you may create the same setup by running these commands:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>CasPol.exe
   -machine
   -addgroup 1.1. 
   -zone MyComputer FullTrust
   -n "VSTOProjects"

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>CasPol.exe
   -machine
   -addgroup "VSTOProjects"
   -zone MyComputer FullTrust
   -n "{461A2C5C-EF1D-4E58-AF67-225827B056E4}"

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>CasPol.exe
  -machine
  -addgroup "{461A2C5C-EF1D-4E58-AF67-225827B056E4}"
  -url "C:\Program Files\ms\OfficeAddinDummySetup\*" FullTrust
  -n "DummyVSTOAdd-in" -d "some text"

 .. and as you can see from the screenshot below, the results are similar.

Of course .. you can just run this commandline: CasPol.exe -m -listgroups .. to visualize your entries, but mscorcfg.msc makes it a lot more easier in my opinion.

How to automate the CASPOL tool? 

 We need to add a special type of class which executes our custom code when the MSI Installer is executed on the end-user's machine:

1.  Right-click on the entire Solution in 'Solution Explorer' and select 'Add' > 'New Project...';
2.  From the 'Visual Studio installed templates' list, select 'Empty Project'; Enter some name (I
     chose the name InstallerOverrideProject for this example) and click OK;
3.  Right-click the newly inserted project and select 'Add' > 'New Item ...', select 'Installer Class';
     Enter any name you want (for this example I used: InstallerOverrideClass) and close the window;

 If you open the 'InstallerOverrideClass.cs', you will see that this class derives from System.Configuration.Install.Installer.

Delete the InstallerOverrideClass.Designer.cs:

4.  Repeat the same actions from the previous step to insert another simple C# class named
     'CaspolSecurityPolicyCreator.cs';  Paste the following code inside: 

5.  Paste the following code inside 'InstallerOverrideClass.cs':

6.  We need to change the default output type for our project to make it a ClassLibrary: right-click it
     from 'Solution Explorer' > go to 'Properties' > select 'Application' > and choose 'Class Library'
     from ' Output type'.

The last thing that needs to be done is finding a way to transmit information about the destination folder to our 'InstallerOverrideClass' at runtime. This is achieved using MSI Installer Setup project Custom 
Actions.


7. Right-click the MSI Setup project, select 'Add' > 'Project Output' > select
    'InstallerOverrideProject' > click OK.

8.  In the 'Solution Explorer', right-click again the Setup project > expand 'View' > 'Custom Actions' >
     in the Custom Actions editor window, right-click 'Custom Actions' root node and click 'Add
     Custom Action'.

9.  In the 'Select Item in Project' pop-up window, go to the 'Look In' drop-down list and click
     'Application Folder'. Select 'Primary Output from InstallerOverrideProject (Active)' and click
     OK.

10.  In the Custom Actions editor, right-click on Primary output from InstallerOverrideProject
       (Active) and click Properties.

11.  Enter the following value in the CustomActionData property: 

       /target_folder="[TARGETDIR]\"

      This passes in the location of the add-in's DLL at runtime to any class which derives from Installer. 

This article is split across two blog posts and this is part #1.. use this link (please be patient :), I am still working on part 2) to go to part #2.

When a beginner programmer needs to create a COM visible DLL which will be called from VBA, PowerShell, VBScript or .NET applications, he can find lots of tutorials on how to get started.

Some of the articles are just presenting the simplest possible steps to build the COM DLL, others go into more detail.

For someone that has not had the opportunity to work extensively with multiple versions of the same COM DLL, it is easy to overlook a couple of very important library design details. If this happens, and the project gets released to end-users, fixing the problem becomes a lot harder.

What's the most important choice when creating COM visible DLLs?  

ANSWER: Selecting AutoDual, AutoDispatch or None for its interface. 

Each COM visible library exposes a set of functions to the outside world. The programmer can choose how these functions are discovered by applications referencing his DLL.

As this MSDN article explains: https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.classinterfacetype.aspx
(ClassInterfaceType Enumeration), we basically have 3 options:

By-default, if you don't do anything to change the class interface settings, Visual Studio will automatically generate:
   > an AutoDispatch interface for your COM library if you create it using C#;
   > an AutoDual interface for your COM library if you create it using VB.Net;

Why is this choice so important?  

It matters because programs are caching (binding to) your DLL's interface information (it is an internal optimization designed to improve code execution speed - I'll give you more details later in the article).

If you plan to release new versions which will run side-by-side or will replace the old ones, you don't want everyone else to recompile the code which calls into your library.

Some background information about COM (how it works behind the scenes)

Microsoft has released a very nice article which explains how COM works from the Office point of view. However, its design principles apply to all COM libraries:

Sorry for using so many different colors to highlight the article from above, but it is vital that you don't miss one of those key concepts.

So .. to briefly summarize what's written above:

   > when COM libraries get registered on the client machine, they create a set of entries (PROGID,
      CLSID ..etc) in the Registry; These entries help client programs discover COM automation servers;

   > client programs can create instantiate COM server objects using their PROGID (example: CreateObject
  ("<some COM_DLL PROGID>") ) or CLSID (example: ProgIDFromCLSID(<some CLSID>", 
  &progid));

   > all COM libraries expose their internal functions using a dispatch interface (which is made of a collection
      of separate interfaces, such as IUnknown, IDispatch ..etc);

  >  specific functions inside the IDispatch interface are responsible for allowing client programs to "look up" 
      methods inside the COM library (GetIDsOfNames);

   >  if IDispatch::GetIDsOfNames returns a valid function pointer (DISPID), the client program calls
       IDispatch::Invoke and uses the DISPID pointer to execute it; 

   >  other functions exposed by the dispatch interface handle the lifetime of the COM object (we'll talk more
       about the IUnknown interface in the next paragraphs);

   >  but if the creator of the COM DLL wishes so, he can allow client programs to bind to his library's 
       vtable of DISPID function pointers; In this way, clients can optimize the execution speed (by not having
       to discover, then execute each COM method call .. they can use the DISPIDs which are already cached)
       of COM automation code.

This was a high level overview of what happens behind the scenes .. the whole process of calling and sending / receiving parameters to COM servers is more complex.

For the sake of completeness, I will go ahead and cite the rest of the article which talks about the inner workings of IDispatch and IUnknown. You will need this information if you decide to write your own COM automation client program in C++, or if you build your own compiler (which will need to do this kind of dirty work, to let the programmer concentrate on writing the code, without worrying how COM calls will be triggered).  

How are those internal COM mechanisms affecting your COM visible DLL?

As I wrote, you most probably won't actually need to call low-level IDispatch methods from your code just to execute a simple COM call .. if you are accessing COM objects from VBA, the compiler hides those things form you.  

But even if high-level programming languages hide those complex details away, you must be aware of what could happen if you allow client programs to cache your COM DLL's interface.

There are two ways in which you can import a COM DLL in Visual Basic..

Early binding:
  > go to Tools > References > locate the COM DLL > click OK to import it in your VBA project;
  > inside your code, create an object instance like this: Dim objCOM As New COM_Obj_ProgID;
  > from this point onwards, the VBIDE will discover the list of available methods and properties for
     your newly created COM object class instance and you will receive InteliSense suggestions about
     the name and list of accepted parameters, when you will try to call any method;

  > when using early binding, VBIDE reads and caches your DLL's vtable, containing all function pointers;
  > if at any point you try to call a method, the VBIDE doesn't call IDispatch to check if the method exists,
     it just calls the corresponding function pointer;

  > this is OK from the client's point of view, because the performance is optimized, and you get 
     design-time InteliSense suggestions from the IDE;
  > but if you later decide that some functions need to be removed or replaced and you roll out the new
     COM DLL version to all end-users, every VBA project referencing the previous version might throw
     a runtime error, because the DISPID table of pointers exposed by the new DLL is going to be
     different; 
 
Late binding:
  > you don't need to import any reference;
  > just instantiate the object like this: Dim objCOM As Object;
  > then you can create a new class instance using:
     Set objCOM = CreateObject("<COM PROGID>");
  > finally, you will be able to access all COM visible methods by calling them as usual;

  > because VBA has no way of knowing (until run-time) if the method you tried to execute is correctly
     accessed (such as the proper method name, the correct number of parameters, the expected data
     type), you can write any combination of method name and input parameters you want;
  > if you got it wrong, VBIDE will trigger a run-time error when the IDispatch interface returns an
     error code because the VBA compiler will first try to discover if the methods you are attempting
     to access are really available;  

  > however, this late binding mechanism has a big advantage; If the creator of the COM DLL decides to
     release a new version, with a different function interface layout, any VBA code calling those methods
     won't crash unless the methods are no longer available;
  > if they are still having their old names and the same input parameters, even if the virtual pointer table
     is different, VBA will discover the new DISPIDs and will call their appropriate methods;

 

Here is what the cited article says about binding:

In part two of this article I am going to demonstrate how we can create COM DLLs which allow for Late or Early Binding.

I will also show you the how Automation clients fail when they encounter a DLL with an unexpected vtable interface layout and what can be done to ensure that different versions of the same COM DLLs with the same PROGID can run side by side. 


Thank you for reading my article! Bye :-)

On 64-bit Windows, portions of the registry entries are stored separately for 32-bit application and 64-bit applications and mapped into separate logical registry views using the registry redirector and registry reflection, because the 64-bit version of an application may use different registry keys and values than the 32-bit version. There are also shared registry keys that are not redirected or reflected.

The parent of each 64-bit registry node is the Image-Specific Node or ISN. The registry redirector transparently directs an application's registry access to the appropriate ISN subnode. Redirection subnodes in the registry tree are created automatically by the WOW64 component using the name Wow6432Node. As a result, it is essential not to name any registry key you create Wow6432Node.

The KEY_WOW64_64KEY and KEY_WOW64_32KEY flags enable explicit access to the 64-bit registry view and the 32-bit view, respectively. For more information, see Accessing an Alternate Registry View.

To disable and enable registry reflection for a particular key, use the RegDisableReflectionKey and RegEnableReflectionKey functions. Applications should disable reflection only for the registry keys that they create and not attempt to disable reflection for the predefined keys such as HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. To determine which keys are on the reflection list, use the RegQueryReflectionKey function.

Registry Redirector
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384232(v=vs.85).aspx
=======================================================================

The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of certain portions of the registry on WOW64. The registry redirector intercepts 32-bit and 64-bit registry calls to their respective logical registry views and maps them to the corresponding physical registry location. The redirection process is transparent to the application. Therefore, a 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in a different location on 64-bit Windows.

A subset of keys under redirected registry paths are shared. 32-bit registry calls to shared keys are not redirected. Instead, one physical copy of the key is mapped into each logical view of the registry. For a list of redirected keys and shared keys, see Registry Keys Affected by WOW64.

Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP:  To enable application interoperability through COM and other mechanisms, a subset of redirected registry keys are also reflected. The process of registry reflection copies registry keys and values between two registry views to keep them synchronized. Registry reflection was removed starting with Windows 7 and Windows Server 2008 R2. For more information, see Registry Reflection.

 The following scenario illustrates the use of these logical views:

• A 32-bit application checks for the existence of the following registry key: HKEY_LOCAL_MACHINE\Software\Hello. If the key does not exist, the application creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value.
• The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.
• When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.

Redirected keys are mapped to physical locations under Wow6432Node. For example, HKEY_LOCAL_MACHINE\Software is redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node. However, the physical location of redirected keys should be considered reserved by the system. Applications should not access a key's physical location directly, because this location may change. For more information, see Accessing an Alternate Registry View.

To help 32-bit applications that write REG_SZ or REG_EXPAND_SZ data containing %ProgramFiles% or %commonprogramfiles% to the registry, WOW64 intercepts these write operations and replaces them with "%ProgramFiles(x86)%" and "%commonprogramfiles(x86)%". For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\Program Files (x86)".

[...]

.. also this how-to article makes it clear that we cannot search if a key exists unless it holds some non-empty value:

As the aforementioned article states, if we leave the 'Value' field empty, then we have to make sure that the key we are searching for has a non-empty (Default) value; Otherwise the setup project will mark this Launch Condition as failed; So this is why we have to introduce the value 'test' at step #19;

How to: Create a Windows Installer for a 64-bit Platform
https://msdn.microsoft.com/en-us/library/cd7a85k9(v=vs.100).aspx
=======================================================================

The deployment tools in Visual Studio allow you to create installers for 64-bit applications and components. The TargetPlatform Property of a deployment project determines whether an installer will target a 32-bit or a specific 64-bit platform. The target platforms are x86 for 32-bit platforms, x64 for computers supporting the AMD64 and EM64T instruction sets, and Itanium for the 64-bit Itanium processor.

In addition, three special folders are available in the File System editor: for 64-bit applications, Common Files (64-bit), Program Files (64-bit), and System (64-bit) are the native folders; Common Files, Program Files, and System are the Windows on Windows folders.

In general, 32- and 64-bit Microsoft Installer (MSI) packages are treated in the same way except for how Windows Installer treats folder variables such as [Program Files] and [System Folder], and how it writes components into the registry or GAC. When you create a 32- or 64-bit MSI package, the processor architecture is noted in the .NET Framework assembly's strong name identity when it is installed in the GAC. You can also create setup projects for 64-bit computers from 32-bit computers.

64-bit MSI packages can support both 32- and 64-bit DLLs or EXEs to perform custom actions; however, 32-bit MSI packages cannot support 64-bit DLLs or EXEs to perform custom actions.

[...]

To distribute a .NET Framework application both to 32- and 64-bit platforms, build two MSI packages, one targeted at a 32-bit and the other a 64-bit computer. The user can install the 32-bit setup project package and it will most likely run as a 64-bit application, only the 64-bit setup project will install to the "Program Files64" directory.

[...]

To create an installer for a 64-bit platform

1.  Open a deployment project. For more information, see How to: Create or Add Deployment Projects.
2.  In the Solution Explorer, select the deployment project.
3.  In the Properties window, select the TargetPlatform property.
4.  Choose either Itanium for an Intel Itanium 64-bit platform, or x64 for any other 64-bit platform (such as AMD64 and EM64T instruction sets).

At installation time, an error will be raised and installation will be halted if the target computer is not compatible with the specified platform.

[...]

Setup projects only ever do a registry search in the 32-bit part of the registry, even if they are built for x64. Internally, the RegLocator table does not have the msidbLocatorType64bit bit set in the Type field on x64 builds. So on an x64 system the MSCRM registry item might exist only in the 64-bit part of the registry, and not in the 32-bit view, the Wow6432Node, and both x86 and x64 setups would fail to find it. If you look at the registry and that's the issue, then I'm not sure what you'd do except use Orca to update your x64 MSI file in the RegLocator table: https://msdn.microsoft.com/en-us/library/aa371171(VS.85).aspx (RegLocator Table);

The RegLocator table holds the information needed to search for a file or directory using the registry, or to search for a particular registry entry itself. This table has the following columns.

The following table lists valid values. Set one of the first three values and msidbLocatorType64bit if necessary. If the entry in this field is absent, Type is set to be 1.

// Override the 'Install' method.

publicoverridevoid Install(IDictionary savedState)
{
  System.Windows.Forms.MessageBox.Show("Registry test value: [" + 
  this.Context.Parameters["regPath"] + "]");
  base.Install(savedState);
}
}
}

   With wrd.ActiveDocument.Selection.Find
     .Text = "-"
     .Replacement.Text = "-test-"
     .Forward = True
     .Wrap = Microsoft.Office.Interop.Word.WdFindWrap.wdFindContinue
     .Format = True
     .MatchCase = False
     .MatchWholeWord = False
     .MatchWildcards = False
     .MatchSoundsLike = False
     .MatchAllWordForms = False
   End With
  wrd.ActiveDocument.Selection.Find.Execute
     (Replace:=Microsoft.Office.Interop.Word.WdReplace.wdReplaceAll)
End Sub

Application: sampleApp.exe

Framework Version: v4.0.30319
Description:       The process was terminated due to an unhandled exception.
Exception Info:    System.AccessViolationException

Stack:
   at Microsoft.Office.Interop.Word.Find.set_Style(System.Object
      ByRef)
   at Word2WikiPlus.Form1.ConvertHeading(Int64, System.String, 
      System.String)
   at Word2WikiPlus.Form1.Transform(System.String ByRef, Int32)
   at Word2WikiPlus.Form1.Button_start_Click(System.Object,
      System.EventArgs)
   at System.Windows.Forms.Control.OnClick(System.EventArgs)
   at System.Windows.Forms.Button.OnClick(System.EventArgs)
   at System.Windows.Forms.Button.OnMouseUp
      (System.Windows.Forms.MouseEventArgs)
   at System.Windows.Forms.Control.WmMouseUp
      (System.Windows.Forms.Message ByRef,
      System.Windows.Forms.MouseButtons, Int32)
   at System.Windows.Forms.Control.WndProc(System.Windows.Forms.
      Message ByRef)
   at System.Windows.Forms.ButtonBase.WndProc
     (System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Button.WndProc(System.Windows.Forms.
      Message ByRef)
   at System.Windows.Forms.Control+ControlNativeWindow.OnMessage(
      System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.Control+ControlNativeWindow.WndProc(
      System.Windows.Forms.Message ByRef)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32,
      IntPtr, IntPtr)
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG
      ByRef)
   at System.Windows.Forms.Application+ComponentManager.System.
      Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.
      FPushMessageLoop(IntPtr,Int32,Int32)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoop
      Inner(Int32,System.Windows.Forms.ApplicationContext)
   at System.Windows.Forms.Application+ThreadContext.RunMessageLoop 
      (Int32,System.Windows.Forms.ApplicationContext)
   at Microsoft.VisualBasic.ApplicationServices.
      WindowsFormsApplicationBase.OnRun()
   at Microsoft.VisualBasic.ApplicationServices.
      WindowsFormsApplicationBase.DoApplicationModel()
   at Microsoft.VisualBasic.ApplicationServices.
      WindowsFormsApplicationBase.Run(System.String[])
   at Word2WikiPlus.My.MyApplication.Main(System.String[])

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

   sampleApp.exe
   0.3.3.0
   4eca4fbc
   oleaut32.dll
   5.1.2600.5512
   4802bdb7
   0
   0007c86c

Set objDOCXSourceApp = CreateObject("Word.Application")

objDOCXSourceApp.Visible       = false
objDOCXSourceApp.DisplayAlerts = false

wscript.echo " Open Input file..."

Set objDOCXSourceDoc = objDOCXSourceApp.Documents.Open(<inputPath>)

If Err.Number <> 0 Then
   objDOCXSourceApp.Application.Quit
   Set objDOCXSourceDoc = Nothing
   Set objDOCXSourceApp = Nothing
   wscript.Quit
End If

wscript.echo " File opened OK."

Dim newDocWin
Set newDocWin = objDOCXSourceDoc.ActiveWindow

newDocWin.Selection.Find.ClearFormatting()newDocWin.Selection.Find.Replacement.ClearFormatting()

If Err.Number <> 0 Then
   wscript.Quit
End If

wscript.echo " ClearFormatting .. OK."

With newDocWin.Selection.Find
    .Text = "-"
    .Replacement.Text = "-test-"
    .Forward = True
    .Wrap = 1 'Microsoft.Office.Interop.Word.WdFindWrap.wdFindContinue
    .Format = True
    .MatchCase = False
    .MatchWholeWord = False
    .MatchWildcards = False
    .MatchSoundsLike = False
    .MatchAllWordForms = False
End With

'WdReplace.wdReplaceAll = 2

newDocWin.Selection.Find.Execute ,,,,,,,,,,2

wscript.echo " newDocWin.Selection.Find.Execute(Replace) .. OK."

objDOCXSourceDoc.Close (False)
objDOCXSourceApp.Application.Quit

Set objDOCXSourceDoc = Nothing
Set objDOCXSourceApp = Nothing

BUG: Automation client receives an error message or crashes when the client calls the Find object in Word
https://support.microsoft.com/kb/292744
=======================================================================

...

Symptoms

When you use an out-of-process client application that uses early binding to Automate Microsoft Word 97 or later versions of Word, the application may crash with an access violation or you may receive one of the following error messages:

From Microsoft Visual Basic:

   > Run-time error '-2147023113 (800706f7)': The method '~' of object '~' failed
  > Run-time error '-2147023113 (800706f7)': Method 'Execute' of object 'Find' failed
  > Run-time error 430: Class does not support automation or does not support expected interface.

From Microsoft Visual C++:

  > HRESULT = 0x800706F7
    RPC_X_BAD_STUB_DATA - The stub received bad data.

Note In debug builds, you receive a corrupt stack warning message from an Assert dialog box, and the value of EAX is that listed above. In release builds, the stack corruption likely crashes the application soon after this point. However, the HRESULT value is likely to be similar to the above.

The problem occurs consistently on some computers, but may never occur on others. Installing a new application or a Microsoft Excel service pack can cause a computer that was working previously to experience the problem.

Cause

Several globally unique identifiers (GUIDs) that are used by Word for its interface identifiers were used by Excel 5.0 for an older object model that is now obsolete.

When the Excel 5.0 type library is reregistered on a system, the interface GUIDs in the registry that should point to the Word type library point to the Excel 5.0 library, and COM can mistakenly construct the wrong proxy v-table for an out-of-process client using early binding to Word. Calls that are made to this proxy return errors or crash because the proxy is configured for a dispinterface for Excel instead of for a dispinterface for the expected Word interface.

The following GUIDs are duplicated in the Excel 5.0 type library and the Word 8.0, 8.1, 10.0 and 11.0 type libraries.

The following GUIDs are affected:

  > Word.Replacement interface {000209B1-0000-0000-C000-000000000046}
  > Word.Dictionary            {000209AD-0000-0000-C000-000000000046}
  > Word.ReadabilityStatistics {000209AE-0000-0000-C000-000000000046}
  > Word.ReadabilityStatistic  {000209AF-0000-0000-C000-000000000046}
  > Word.Find                  {000209B0-0000-0000-C000-000000000046}

Resolution

To resolve this problem, use one of the following methods.

• Modify your code to use late binding when you call methods or properties on any of the above listed Word interfaces.
• Reregister the Word type library on the system on which the problem occurs.

The recommended solution is to use late binding. Because both type libraries describe interfaces that implement the IDispatch interface, calls to any of the IDispatch methods work regardless of which library was last registered on the system. This is the only way to be sure that your code does not encounter this error on systems that you do not administer.

For customers who use client applications that cannot be recompiled to use late binding, you can reregister the Word type library to resolve the problem in most cases. Because the problem returns if the Excel 5.0 library is reregistered again, this method is not an ideal resolution. However, the chances of the Excel 5.0 library being reregistered are low. Therefore, this method should work for most users.

To reregister the Word type library, find the appropriate type library for the version of Word that is installed on the system.

Version     Library name
--------------------------------------
Word 97     Msword8.olb
Word 2000   Msword9.olb
Word 2002   Msword.olb
Word 2003   Msword.olb

Then, from the command line, use Regtlib.exe together with the full path to the type library to reregister the library for COM. Regtlib.exe calls the LoadTypeLib and RegisterTypeLib application program interfaces (APIs) on the type library (.tlb or .olb) file that is passed in. COM repairs the misconfigured registry keys. 

This article is split across two blog posts and this is part #2 .. use this link to go to part #1.

In part #1 of this article, I demonstrated how words are counted using OpenXML and I warned about the dangers of not getting it done correctly.

Here is a short summary of the alternatives we have:   

Can we obtain 100% reliable statistics?

Method #1:
       When Word receives a query about the Document statistics (either manually through the Ribbon
       graphical interface or using VBA ObjectModel), it computes those results and always reports the
       correct numbers. All we have to do next, is to save and close the file and then send it to a program
       which accesses the OpenXML structure and reads those values.  

        The only difficult part is finding a way to trigger the update every time, to ensure that the
        information stored in the file is up to date.

        Advantages: 
                                       > easy to implement;
                                       > OpenXML code used to read the values is very simple;
                                       > works for all kinds of input files ... even very complex ones 
                                         (containing embedded charts, shapes, nested tables ..etc);

        Disadvantages:
                                       > we can only force the Word Count update if we rely on a VBA / VSTO
                                          add-in installed on the client-side;
                                      > somehow, the automated Statistics Update Add-in has to be
                                         deployed to all end-users; 
 Method #2:
       Write our own OpenXML code and count the words ourselves.

        Advantages: 
                                       > no need for 'helper' tools;

        Disadvantages:
                                       > because the OpenXML format is VERY complex, the code will run
                                          reliably only for basic input files; If you want to extend the program
                                          to be able to handle all kinds of input documents you will find that
                                          the complexity of the code increases up to the point where it is not
                                          feasible to continue with the project (you will very likely be forced
                                          to write individual code rules for targeting all kinds of
                                          exceptions and special conditions for XML text tags, that may
                                          appear in different combinations);

In this article, I would like to present the first method, where we use VBA to count our words. But first, we have to trigger the problem:

Triggering the Word statistics mismatch problem

1.   Just create a new Word document, type "=rand(1)" (without the quotes), then press Enter key;
2.   Save it file using .docx type, then close it;
3.   Open the file using an OpenXML editor, or rename the document from .docx to .zip, open the docProps folder and then edit the app.xml file;  Note the values of these XML items:
      >  Pages; 
      >  Words; 
      >  Characters;
      >  Lines;
      >  Paragraphs; 
      >  CharactersWithSpaces;
4.   Close the editor, or if you renamed the file to .zip, restore its original extension; Open it again in Word;
5.   On the Review tab, in the Proofing group, click Word Count;
6.   Compare the statistics in the Word Count dialog with those noted from the app.xml file;

 Result: we easily notice that the numbers are different ...

7.   Close the document again, you should be prompted to Save it. Go ahead and click OK to store the updated
      document information;
8.   Open its internal OpenXML structure and this time you should see that the numbers match; 
 

If we slightly change the order of execution for the aforementioned steps:

   > create a new file;
   > add some text;
   > save the file;
   > keep the document open, then go to 'Review' > 'Proofing';
   > click on 'Word Count';
   > close the file;
   > open it using an OpenXML editor, or rename the document from .docx to .zip, open the docProps
      folder and then edit the app.xml file;

... you'll notice that the correct statistics information is stored into the document.


But something interesting happens ... when we try to close the Word document after viewing the Statistics, even though we didn't add any modification (we simply clicked on 'Word Count') the application prompts us to save the file again!

The same behavior occurs if I go to VBA and execute:

"Debug.Print ActiveDocument.ComputeStatistics(wdStatisticCharactersWithSpaces)".

What this means is that when we first saved the file, Word just entered a rough estimation of the Character count, but when we clicked on 'Word Count', the application updated its Statistics.

Since we know that it’s enough to click on the 'Word Count' button or execute the VBA instruction to have the correct value stored in OpenXML, we can take advantage of it to force a computation before the user triggers a Save in Word.

In this way, each time the end-user sends his file to an automated code or script, it will contain the most up-to-date Statistics information.

A simple solution using VBA ...
 
I wrote a simple Word DOTM add-in which will trigger the statistics update before each save:

As you can see, everything seems to be working:

 .. but not for all scenarios.

Let's suppose the end-user starts by opening an older .DOC file, then he does a SaveAs to store it as an OpenXML format document. In this case, the newly saved .DOCX file will contain unreliable word count information ... But why ?

It seems this issue is being caused by the fact that my code is receiving a handle that points at the old .DOC file when this event occurs:

Private Sub clsWd_DocumentBeforeSave(ByVal Doc As Document ..

.. therefore Word computes the correct Statistics for a different file. This is not a problem in a normal Save action, but with a SaveAs, we get a handle on the new document only after we exit the BeforeSave event handler, and by that time it is too late for the code to act.


A less simple solution using VBA :) ...

There is no AfterSave event in Word, but I tried to simulate one:

>  first I am saving the name of the present document (DOC);
>  then I am executing a delayed call to another function (timerCallback) where I check if the
    active document (it becomes a DOCX format after SaveAs completes) has the same name
    as the one I recorded before;
>  if the names are not identical, we probably executed a SaveAs so we trigger the computation
    again;
>  I chose to introduce a 200ms delay .. but it doesn’t seem to matter whether this interval is
    smaller or larger; The Application.OnTime call schedules a timer callback at the first available
    moment, but it is done only after the SaveAs function completes .. so by that time we already
    have a new document name and can detect if we have to trigger a new computation;

The source code became more complex now … and with the added complexity, there may be problems. It’s up to you to decide if you want to keep the first design and just instruct your users to perform a normal Save after they convert a document, or keep this more complicated design.

Here is the output:

As I have shown inside the areas highlighted with red, at first we open an older document format: rand1.doc. When we trigger a SaveAs, my BeforeSave code runs but it just counts the words inside this old file and exits. The Save action is automatically performed by Word, and only after we exit that internal function (which is not reachable to us) we notice that the ActiveDocument has changed to rand9.docx.

When the control returns to the VBA macros and they get their chance to run (the Application.OnTime schedules my task to execute at the first available slot), my code performs a comparison and detects the new document: rand9.docx which is highlighted in blue. It will trigger another word count and exit the routine.

The End.

I hope you enjoyed my article.

For any questions, feel free to add a comment or write me at cristib@microsoft.com.

This article is split across two blog posts and this is part #1 .. use this link to go to part #2.

There are many scenarios when we have to know exactly how many words, pages, paragraphs or characters are found in a certain document:

   > we might be developing a tool which searches through files; If we want to add OpenXML files to
      its list of known formats, then it would be nice it we could offer a progress estimation when 
      users search inside a document (example: display [x% completed out of yyyy word count);

   > or you may need to count the number of words for a company that translates documents, to
      know how much they need to charge customers;
   
   > in case some public institution builds a web-page where documents can be uploaded; If there
      is a requirement / limitation that forces any uploaded document to contain up to xxxx words,
      then we need a code that reliably reads this information;

   .. and there are many other scenarios where counting words comes in handy. 

Let's assume that we have to count the number of words in an OpenXML Word document on a server.

If the 'word counter' tool runs on the server side, then you can't use COM automation, as this action would place you in an unsupported scenario. 

So what alternative do we have? Answer: use OpenXML API.

A quick search on the internet reveals this code snippet:

But will it work as expected? Does it report the same number of words as displayed inside MS Word editor?
Answer: Yes, it works but it's not reliable.  Sometimes it gives the expected results, sometimes it returns slightly different numbers ....

Triggering the Word statistics mismatch problem

1.   Just create a new Word document, type "=rand(1)" (without the quotes), then press Enter key;
2.   Save it file using .docx type, then close it;
3.   Open the file using an OpenXML editor, or rename the document from .docx to .zip, open the docProps
      folder and then edit the app.xml file;  Note the values of these XML items:
      >  Pages; 
      >  Words; 
      >  Characters;
      >  Lines;
      >  Paragraphs; 
      >  CharactersWithSpaces;
4.   Close the editor, or if you renamed the file to .zip, restore its original extension; Open it again in Word;
5.   On the Review tab, in the Proofing group, click Word Count;
6.   Compare the statistics in the Word Count dialog with those noted from the app.xml file;

 Result: we easily notice that the numbers are different ...

7.   Close the document again, you should be prompted to Save it. Go ahead and click OK to store the updated
      document information;
8.   Open its internal OpenXML structure and this time you should see that the numbers match; 

The Word Count difference is by-design

   >  MS Word has a set of tasks that are scheduled to run when the application is in idle mode;
   >  the Compute Document Statistics task has a low priority;
   >  when the user changes content inside a document, Word just estimates the number of characters,
       paragraphs ... etc. The data is stored in a special field inside a documents and is marked as
       'estimated';
   >  when we save a file and the document statistics task has not yet been executed, we just get an
       estimated value inside the xmlProperties.GetElementsByTagName("CharactersWithSpaces")
       OpenXML field;

 Our Product Group's developers were notified about the inconsistency between OpenXML and COM 
 ObjectModel results and they replied that it was their decision to store approximate values in OpenXML.
  
The main reason why things are happening in this way is performance. For a small file, the time needed to compute Word Count statistics is not a problem, but for a document with thousands of pages, it may take several seconds or even minutes. If Word application was set to compute all the statistics in real-time, before a save (or more often), the end-users would surely complain about application hangs during saves.

So the Product Group decided to compromise between speed and accuracy. As you have noticed, the difference between the estimated values and the real values are not bigger than 1 ~ 2% which is more than enough for regular users. 

Can we obtain 100% reliable statistics?

Method #1:
       The OpenXML data can be forced to update: when Word receives a query about the statistics (through 
       the Ribbon graphical interface or the VBA ObjectModel), it computes those results and always reports
       the correct numbers.

        The only difficult part is finding a way to trigger the update every time, so that we are sure that the 
        information stored in the file is up to data.

        Advantages: 
                                       > easy to implement;
                                       > OpenXML code is very simple;
                                       > works for all kinds of input files ... even very complex ones (containing
                                          embedded charts, shapes, nested tables ..etc);

         Disadvantages:
                                       > we can only force the Word Count update if we rely on a VBA / VSTO
                                          add-in installed on the client-side;
                                      > somehow, the automated Statistics Update Add-in has to be deployed to all 
                                         end-users; 
                     

Method #2:
        Write our own OpenXML code and count the words ourselves.

        Advantages: 
                                       > no need for 'helper' tools;

         Disadvantages:
                                       > because the OpenXML format is VERY complex, the code will run reliably
                                          only for basic input files; If you want to extend the program to be able to 
                                          handle all kinds of input documents you will find that the complexity of the 
                                          code increases up to the point where it is not fasible to continue with the 
                                          project (you will very likely be forced to write individual code rules for targeting
                                          all kinds of exceptions and special conditions for XML text tags, that may
                                          appear in different combinations);

Hmmm ... something tells me that when you read the lines about the disadvantages of using Method #2, some wheels already started turning in your head. You must be thinking: "there must be some trick to get all the words ...".

OK, let me show you how you get started on this path ... if you decide that this approach is right for you, then you can further develop my sample code:

 Code sample from below can be downloaded from this link.