Protobuf Support

Add-in Express™ Support Service
That's what is more important than anything else

Protobuf Support
 
Craig Callender




Posts: 21
Joined: 2021-07-06
I'm attempted to add a protobuf client to an add-in express Outlook add-in. I have a sample project that exhibits the behavior (Let me know how I can provide it to you). While everything compiles, I can't seem to register the add-in via addin express in visual studio 2019 as I get the error:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(5199,5): warning : Type library exporter warning processing 'Tessian.Outlook.Addin.Eventing.Greeter+GreeterClient, Protobuf.Addin'. Warning: Type library exporter encountered a type that derives from a generic class and is not marked as [ClassInterface(ClassInterfaceType.None)]. Class interfaces cannot be exposed for such types. Consider marking the type with [ClassInterface(ClassInterfaceType.None)] and exposing an explicit interface as the default interface to COM using the ComDefaultInterface attribute.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(5199,5): error MSB3211: The assembly 'Google.Protobuf, Version=3.17.3.0, Culture=neutral, PublicKeyToken=a7d26565bac4d604' is not registered for COM Interop. Please register it with regasm.exe /tlb.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(5199,5): error MSB3212: The assembly "C:\Users\Username\source\repos\Protobuf.Addin\Protobuf.Addin\bin\Debug\Protobuf.Addin.dll" could not be converted to a type library. Type library exporter encountered an error while processing 'Tessian.Outlook.Addin.Eventing.HelloRequest, Protobuf.Addin'. Error: Error loading type library/DLL.


Any thoughts on how to move forward?

Thanks!
Craig
Posted 01 Aug, 2021 08:04:03 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Hello Craig,

Could you send me a test solution reproducing the issue?


Andrei Smolin
Add-in Express Team Leader
Posted 02 Aug, 2021 06:38:06 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
You can find the support email address in {Add-in Express installation folder}\readme.txt.


Andrei Smolin
Add-in Express Team Leader
Posted 02 Aug, 2021 06:54:55 Top
Craig Callender




Posts: 21
Joined: 2021-07-06
Hi Andrei,
I just sent the example over. I did end up coming up with a work around. I was able to:

1. In AssemblyInfo.cs, set ComVisible(false):

[assembly: ComVisible(false)]


2. Add the ComVisible(true) attribute on the AddinModule.cs class:

[ComVisible(true)]
public partial class AddinModule : AddinExpress.MSO.ADXAddinModule
{
}


I'm not sure if that's the preferred method though. I did *not* include those fixes in the project I sent you so you can see the issue in that.
Posted 02 Aug, 2021 07:40:32 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Thank you, Craig,

I didn't receive the example.


Andrei Smolin
Add-in Express Team Leader
Posted 02 Aug, 2021 07:53:52 Top
Craig Callender




Posts: 21
Joined: 2021-07-06
I had some trouble with gmail that I've sorted. If you get the error
Grpc.Tools.2.38.1\build\_protobuf\Google.Protobuf.Tools.targets(51,5): error : Google.Protobuf.Tools proto compilation is only supported by default in a C# project (extension .csproj)


Just right click on the solution in VS and select Clean. Then use add-in express's vs plug-in to register the project with Outlook. You're looking for this error:
The assembly "C:\Users\UserName\Downloads\Protobuf.Addin\Protobuf.Addin\Protobuf.Addin\bin\Debug\Protobuf.Addin.dll" could not be converted to a type library. Type library exporter encountered an error while processing 'Tessian.Outlook.Addin.Eventing.HelloRequest, Protobuf.Addin'. Error: Error loading type library/DLL.
Posted 02 Aug, 2021 09:26:21 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Hello Craig,

I suppose you may be wrong. According to https://betterprogramming.pub/understanding-protocol-buffers-43c5bced0d47, we are supposed to compile a .proto file "to generate the code in the user?Â?Ð?és programming language". The add-in registers okay if I exclude the .proto file from the project.


Andrei Smolin
Add-in Express Team Leader
Posted 03 Aug, 2021 05:21:28 Top
Craig Callender




Posts: 21
Joined: 2021-07-06
Hi Andrei,
I don't think you can remove the .proto file(s) from the project or else you'll never be able to use the types that get generated from that file. For reference, https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-5.0&tabs=visual-studio how MSFT says you should create a server/client project. You can see that the proto files need to be in there and that's how the Greeter.GreeterClient and HelloRequests get generated into .Net objects so you can use them in code.

The linked example shows how to get it working in .Net Core/.Net 5, but the concept is the same in .Net Framework 4.6.2+, as shown https://docs.microsoft.com/en-us/aspnet/core/grpc/netstandard?view=aspnetcore-5.0#net-framework.
Posted 03 Aug, 2021 05:30:32 Top
Andrei Smolin


Add-in Express team


Posts: 18829
Joined: 2006-05-11
Hello Craig,

I've studied the issue. Below are my findings.

It looks like Protobuf generates types on the fly. These types are public which may relate to serialization/deserialization. Anyway, they create a type which cannot be used in COM; you get a warning on this type. In other words, they don't expect that that type will be used in COM-aware applications.

At the same time, in an Add-in Express project all public types are COM-visible by default and this contradicts to what Protobuf expects.

You solve this contradiction in two steps:
- set ComVisible(false) on the assembly; you can do this by clearing the "Make assembly COM-Visible" - open project properties via menu Project | {project name} Properties; on the Application tab click the Assembly information button.
- set ComVisible(true) on the add-in module class. In 99.99% this would be all you need. If, in a rare case, your add-in provides COM objects other than (or in addition to) the add-in module, set ComVisible(true) on all classes that you need to be visible through COM. Again, you would only need this in rare cases; most rare, I'd say.


Andrei Smolin
Add-in Express Team Leader
Posted 05 Aug, 2021 04:43:18 Top
Craig Callender




Posts: 21
Joined: 2021-07-06
Thanks Andrei. I appreciate the confirmation that switching ComVisible to false for the assembly and only applying it to the add-in module class (and in rare instances, other classes needing to expose to COM) is the way to go. :)
Posted 09 Aug, 2021 05:40:22 Top