We have, as part of still used legacy code, a C++ application, written in 2009, that uses some customer-provided files, like application.h, application.tlb, and application_i.c.
The application has been written by my predecessor, who’s no longer available.
Everything builds nicely in VS2017 and VS2022 – on the one old build machine that had been doing the builds for years. It has Win10 Enterprise 22H2 installed.
Building exactly the same on any other machine (Win10, Win11, Windows Server) with exactly the same Visual Studio configuration fails:
It does succeed with the first part, building a COM module. The output generated is identical on all machines I tried – same files, same content.
The problem happens in the next part that uses the COM module. It imports the xxx.tlb file generated in the first part – only on the old build machine. On any other I get a C1084 error – “Cannot read type library file xxx.tlb”.
Registration can’t be the problem, running Visual Studio as Admin, the output shows no issues.
I’ve compared the configuration on all machines, the only obvious difference I can see is that the working build machine has .NET Framework 1.1 installed. Which I can’t install anywhere else as it’s too old. Version 3.5, according to Microsoft compatible with 1.1, is installed, as is 4.8.
The bit of code where it fails, except on the old build machine, is
#include <iostream>
#include <tchar.h>
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
#include <atlbase.h>
#import "......ThirdPartySuppliedsomething.tlb" raw_interfaces_only, no_namespace, exclude("ISomeObject" )
#ifdef _DEBUG
#import "..ComInterfaceDebugxxxCOM.tlb" raw_interfaces_only, no_namespace
#else
#import "..ComInterfaceReleasexxxCOM.tlb" raw_interfaces_only, no_namespace
#endif
It’s the lines importing xxxCOM.tlb where the error happens.
Again, the code hasn’t changed since 2009, it builds and works – only on one machine though.
Could .NET 1.1 be the reason? If yes, is there a way around it?
2