Feature/watchdog thread

[asparrowhawk]

Watchdog

This pull request contains a significant number of changes. Notable are the addition of a native assembly which contains COM interop code that is responsible for retrieving the process id of a COM server given a IUnknown interface pointer. This interface is typically the Office application that is being automated. A separate README.md in the COMServer project directory provides additional information and insight into how it is implemented and used.

With the functionality delivered by the COMServer assembly, a new /timeout <seconds> command line option was added that informed how long the OfficeToPDF application should wait for the conversion process to happen. This involved the addition of the following new classes and interfaces:

• IWatchdog
• NullWatchdog
• Watchdog
• WatchdogFactory

Other changes are the addition of the ArgParser class. This is a class that is derived from the Systems.Collections.Hashtable that was employed by the original code. The new class pulls together all the related command line parsing logic and state. It also adds type safe access to the contents of the hash table removing the need for the client code to perform a cast to the expected type at point of access.

For example:

Boolean running = (Boolean)options["noquit"];

becomes

Boolean running = options.noquit;

The code changes also introduce the IConverter interface and ConverterFactory class. These provide a uniform function for conversion and a simple way to create the required converter based on the source filename's extension.

All of the Converter class implementations remain as per the original master branch. Any changes were limited to using the ArgParser class instead of the Hashtable.

Also added were a number of NUnit based tests that ensure the correct behaviour of a lot of the new classes. The test project also contains a number of 'Explicit' tests that can be used to verify the behaviour of the Watchdog and that the COMServer code retrieves the process id.

There is also a GitHub actions workflow that builds the source code and runs the unit tests that are NOT marked as Explicit. See the .github\workflows\build.yml that is part of the solution.

With the introduction of the COMServer assembly the projects must be built as either x86 or by default x64. Therefore the "Mixed Platforms" and "Any CPU" build configurations have been removed from the projects and the solution.

For the Unit tests, some custom MSBuild configuration, copies the required native assembly to the output directory:

  <Target Name="CopyDependents" AfterTargets="Build">
    <ItemGroup>
      <DependentFile Include="COMServer.dll;COMServer.pdb" />
    </ItemGroup>
    <PropertyGroup Condition="'$(Platform)' == 'x86'">
      <DependentDir>$(Configuration)</DependentDir>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Platform)' != 'x86'">
      <DependentDir>$(Platform)\$(Configuration)</DependentDir>
    </PropertyGroup>
    <Copy SourceFiles="@(DependentFile -> '$(SolutionDir)COMServer\$(DependentDir)\%(Identity)')" DestinationFolder="$(TargetDir)" SkipUnchangedFiles="true" Condition="'$(NCrunch)' != '1'" />
  </Target>

The projects have been updated to use .NET Framework version 4.8. All work was carried out using Visual Studio 2022. The existing NuGet packages were NOT updated. The Unit test project references the latest NUnit NuGet packages.

Deployment still just requires the OfficeToPdf.exe and OfficeToPdf.exe.config files. The COMServer.dll has been added to OfficeToPdf project as embedded resources as detailed in the Costura documentation.

[asparrowhawk]

I am having problems with GitHub actions. The build agents do not seem to have the Microsoft.mshtml.dll assembly registered on them. This is required in order to build the COMServer and OfficeToPdf projects due to their reliance COM and the Office Primary Interop Assemblies.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2926,5): warning MSB3284: Cannot get the file path for type library "0002e157-0000-0000-c000-000000000046" version 5.3. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)) [D:\a\OfficeToPDF\OfficeToPDF\OfficeToPDF\OfficeToPDF.csproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2926,5): warning MSB3283: Cannot find wrapper assembly for type library "MSHTML". Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform must not be 64-bit. [D:\a\OfficeToPDF\OfficeToPDF\OfficeToPDF\OfficeToPDF.csproj]

I have tried registering the Microsoft.mshtml.dll assembly as part of the workflow, but that needs admin permissions on the build agent.

I will have to look at other work arounds and the possibility of using a docker container to build the code. But this may take a little bit of time.

[asparrowhawk]

I have solved the build issue by removing the COM references to MSHTML and VBIDE from the OfficeToPdf project.