I have worked and read through various StackOverflow questions and other tutorials and documentation over the past weeks (N.B. some of them below) to try and find a way of unit testing a VSTO AddIn.
Unfortunately, it always results in an E_NOINTERFACE exception in my tests.
The code I am using is below - one extract of the ThisAddin partial class overriding the RequestComAddinAutomationService, another describing the test utility interface, the test itself, as well as an additional assembly extract proving that the AddIn assembly and its internals are visible to the test.
My question is: why is this not working? I am pretty sure that this follows the generally accepted practices of VSTO testing.
If the below is not possible anymore, how should one go about testing VSTO? Is .NET remoting/IPC the only solution?
ThisAddin.cs
public partial class ThisAddin
{
#region Testing Utilities
private AddinHelper _comAddinObject;
protected override object RequestComAddInAutomationService()
{
// This is being called when I debug/run my project, but not when I run the tests
return _comAddinObject ?? (_comAddinObject = new AddinHelper());
}
#endregion
}
#region Testing Utilities
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IAddinHelper
{
Presentation GetPresentation();
string GetString();
}
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[ComSourceInterfaces(typeof(IAddinHelper))]
public class AddinHelper : StandardOleMarshalObject, IAddinHelper
{
public Presentation GetPresentation()
{
return Globals.ThisAddin... [...];
}
public string GetString()
{
return "Hello World!";
}
}
#endregion
AssemblyInfo.cs
[assembly: InternalsVisibleTo("MyProject.Tests")]
MyUnitTest.cs (has a reference to MyProject)
[TestClass]
public class BasicTest
{
[TestMethod]
public void TestInstantiates()
{
var application = new Application();
var doc = application.Presentations.Open(#"C:\Presentation.pptx",
MsoTriState.msoFalse, MsoTriState.msoFalse, MsoTriState.msoFalse);
var comAddins = application.COMAddIns;
var comAddin = comAddins.Item("MyProject"); // Returns okay
var comObject = (IAddinHelper) comAddin.Object; // Exception occurs
Assert.AreEqual(true, true); // Never reached
doc.Close();
}
}
Furthermore, the project's settings are set to "Register for COM interop" and Visual Studio runs elevated without errors - running it as non-admin results in the DLLs not being registered; therefore, I also know that the COM objects are registered.
Resulting Exception
An exception of type 'System.InvalidCastException' occurred in MyProject.Tests.dll but was not handled in user code
Additional information: Unable to cast COM object of type 'System.__ComObject' to interface type 'MyProject.IAddinHelper'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{59977378-CC79-3B27-9093-82CD7A05CF74}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
StackOverflow
How to call VSTO class from other c# project
Unit Testing VSTO projects
VSTO Add-ins, COMAddIns and RequestComAddInAutomationService (Register for COM Interop doesn't change anything)
Why cannot I cast my COM object to the interface it implements in C#? (the issue is likely not STAThread related)
https://sqa.stackexchange.com/questions/2545/how-do-i-unit-test-word-addin-written-in-c
Microsoft
https://blogs.msdn.microsoft.com/varsha/2010/08/17/writing-automated-test-cases-for-vsto-application/ <-- Even with this supposedly working sample project, I am getting the exact same error.
https://msdn.microsoft.com/en-us/library/bb608621.aspx
General workflow background: https://msdn.microsoft.com/en-us/library/bb386298.aspx
I honestly don't know how one is supposed to test VSTO Add-Ins without this working.
Solution
The Project with methods to be Tested has to use the PIA Microsoft.Office.Interop.PowerPoint via the .Net reference tab.
In the Unit Test Project you have to use the Microsoft Powerpoint 1X.0 Object Library via the COM reference tab - its an ActiveX.
The confusing thing is in Solution Explorer they are both called: Microsoft.Office.Interop.Powerpoint
When you specify the correct References you'll see this error on the line where the exception occurs:
Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'
To solve that simply add a .Net reference to the Microsoft.CSharp.dll in the Unit Test project.
Next we will run into the error you're seeing.
Firstly add a unique GUID to the Interface & class (this will overcome the error):
[ComVisible(true)]
[Guid("B523844E-1A41-4118-A0F0-FDFA7BCD77C9")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IAddinHelper
{
string GetPresentation();
string GetString();
}
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("A523844E-1A41-4118-A0F0-FDFA7BCD77C9")]
[ComSourceInterfaces(typeof(IAddinHelper))]
public class AddinHelper : StandardOleMarshalObject, IAddinHelper
Secondly temporarily make the private AddinHelper _comAddinObject; public in Scope (you can do your [assembly: InternalsVisibleTo("MyProject.Tests")] later when its working).
Thirdly, check that Powerpoint has not disabled the COM add-in. This sometimes happens silently, without the Office App complaining.
Lastly, make sure Register for COM is ticked.
Viola:
Ref: I pulled my hair out working this out years ago helping this fellow SO'r: Moq & Interop Types: works in VS2012, fails in VS2010?
Related
We have a .Net assembly, A, that makes use of a class Foo from a COM library, B.
We've created an interop for B (Interop.b.dll) and A makes use of Foo via the interop.
If I decompile Interop.b.dll I can see the following interface defined within it:
using System.Runtime.InteropServices;
namespace Interop.b
{
[Guid("SOME-GUID")]
[CoClass(typeof (FooClass))]
[ComImport]
public interface Foo : _Foo
{
}
}
In the references settings of .Net assembly A, I have the option to embed the interop types for Interop.b.dll. If I set this to true the interfaces defined within Interop.b.dll are embedded within A.dll. If I then decompile A.dll I can see the same interface as I found in the interop:
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
namespace Interop.b
{
[CompilerGenerated]
[Guid("SOME-GUID")]
[CoClass(typeof (object))]
[TypeIdentifier]
[ComImport]
public interface Foo : _Foo
{
}
}
Except that it's not the same. In this version we have [TypeIdentifier] as an additional attribute and the parameter of the CoClass attribute has changed from typeof(FooClass) to typeof(object).
I note that Interop.b.dll contains the type FooClass, which I believe is a wrapper class for the COM type Foo that is responsible for marshalling parameter types between .Net and COM, but this type has not been embedded in A.dll.
Within A.dll, Foo is used like this:
using Interop.b;
namespace My.Product
{
public class AClass: IAClass
{
private Foo LocalFoo { get; }
public AClass()
{
LocalFoo = new Foo();
}
}
}
On a clean install, this fails with the following exception:
System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'Interop.b.Foo'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{SOME-GUID}' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
(Interop.b.dll has been installed to the GAC by the product installer)
On a development machine, reinstalling the product and running from installed binaries fails in the same way. Subsequently recompiling the product, which overwrites the installed binaries, and running from either code (in debug) or the fresh binaries then works.
Now, I believe the error is that the code in A.dll should be instantiating FooClass rather than Foo. i.e. something like this:
LocalFoo = new FooClass();
...because Foo is an interface (in the interop) and FooClass is the thing that handles the marshalling of the parameter types between .Net and COM.
So, questions:
1) Am I correct that the code should be instantiating FooClass rather than Foo?
2) Why does it work at all on a dev machine?
3) Why is the embedded interface using typeof(object) instead of typeof(FooClass)?
4) What is the benefit of embedding the interfaces from the interop in A.dll when we will still need Interop.b.dll on the target machine to allow us to make use of FooClass?
I am working on a application which needs to communicate via COM interface with multiple CAD applications (not in the same time). I want to have nice and reusable code, but I came across problems with type casting of COM objects when I made generic application handle getter method.
What I tried so far:
This is the attempt I would like the most if it worked.
public static TCadAppType CadApp<TCadAppType>()
{
dynamic cadApp = default(TCadAppType);
//Here under Dynamic View/Message there is already an error
// Message = "Element not found. (Exception from HRESULT: 0x8002802B (TYPE_E_ELEMENTNOTFOUND))"
// cadVersion.Value evaluates to "SldWorks.Application"
cadApp = (TCadAppType)Marshal.GetActiveObject(cadVersion.Value);
//Following 2 lines of code are for testing purposes only, i am testing with Solidworks API
AssemblyDoc Assembly;
//The exception is thrown when I try to access some method from the Solidworks API
Assembly = (AssemblyDoc)cadApp.OpenDoc6("some parametras...");
}
Attempt using Convert class
// Another attempt using Convert class
public static TCadAppType CadApp<TCadAppType>()
{
dynamic cadApp = default(TCadAppType);
// cadVersion.Value evaluates to "SldWorks.Application"
cadApp = Marshal.GetActiveObject(cadVersion.Value);
cadApp = Convert.ChangeType(cadApp, typeof(SldWorks.SldWorks));
// Exception is thrown with the following message:
// Message = "Object must implement IConvertible."
}
I really thought that I am on the right track, since there is an article on Microsoft Docs website explaining how dynamic can help you with com interopt: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic#com-interop
Any ideas how I can do this runtime casting a keep my code as reusable as possible?
My software setup:
Win 10
Project is targeted for .NET 4.7.2
First Tests are with Solidworks 2019
Turns out that the my coding attempt 1 was valid c# code indeed.
I tried it using with Autodesk Inventor, and it works.
So the only thing left for me is to conclude that this is some bug from Solidworks and their COM interfacing.
Thank you Optional Option for your interest in the topic.
I've been trying to test my addin without success, and even after looking at various sources like MSDN and StackOverflow
I can't seem to be able to do it.
Here's my current code (I trimmed to only have the relevant parts)
AssemblyInfo.cs
[assembly: ComVisible(true)]
[assembly: InternalsVisibleTo("MyAddInTest")]
ThisAddIn.cs
private AddinHelper _comAddinObject;
protected override object RequestComAddInAutomationService()
{
return _comAddinObject ?? (_comAddinObject = new AddinHelper());
}
AddinHelper.cs
[ComVisible(true)]
[Guid("B523844E-1A41-4118-A0F0-FDFA7BCD77C9")]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
public interface IAddinHelper
{
string GetString();
}
[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("A523844E-1A41-4118-A0F0-FDFA7BCD77C9")]
[ComSourceInterfaces(typeof(IAddinHelper))]
public class AddinHelper : StandardOleMarshalObject, IAddinHelper
{
public string GetString()
{
return Globals.ThisAddIn.Application.ActiveWorkbook.Name;
}
}
ThisAddInTest.cs
Application = new Application();
Workbook = Application.Workbooks.Add();
COMAddIns comAddins = Application.COMAddIns;
COMAddIn comAddin = comAddins.Item("MyAddIn");
IAddinHelper comObject = (IAddinHelper) comAddin.Object;
The main project references the .NET Assembly version of Microsoft.Office.Interop.Excel with Embed Interop Types set to true.
My test project references my VSTO project, and the COM (ActiveX) version of the Interop.
The exception I get is:
Unable to cast COM object of type 'System.__ComObject' to interface type 'MyAddIn.IAddinHelper'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{B523844E-1A41-4118-A0F0-FDFA7BCD77C9}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
I currently use Office 2013 (so Office 15.0) and the references are all pointing to that version, .NET 4.5.3 and Visual Stuio Community 2017. The SO link that I provided seems to be the exact same issue, however I still have the exception when running my tests unlike there.
I have a COM visible class (marked with [ComVisible(true)] and registered with RegAsm) in C# that I want to unit-test.
My assembly is an unsigned/weakly named dll (and it has to remain this). The class that I want to test has a private member that is not COM visible.
My problem is when I want to instantiate this class in a test it fails with this message:
Test method %MyTestMethod% threw exception
System.EnterpriesServices.RegistreationException: The assembly
%MyAssembly% does not have a strong name.
So how can I use the unit-test framework on an unsigned/weakly named dll?
using System.EnterpriseServices;
using System.Runtime.InteropServices;
[ComVisible( true )]
public class MyComClass: ServicedComponent, IMyClass
{
//SomeAttribute
private MyNonComClass nonCom;
public MyComClass( MyNonComClass _nonCom )
{
this.nonCom = _nonCom;
}
}
As Hans Passant suggested when I removed the ServicedComponent class from inheritance, the unit-tests are running as supposed.
I'm trying to create unit tests for an Excel VSTO add-in I've created, but I've ran into an incredibly mysterious issue that feels well beyond my experience.
In this case, I have a presenter:
public class Presenter
{
private readonly Excel.Application Application;
public Presenter(Excel.Application Application)
{
this.Application = Application;
Application.WorkbookActivate += Application_WorkbookActivate;
}
private void Application_WorkbookActivate(Excel.Workbook Wb)
{
// logic to be tested
}
}
My unit test is to verify that when WorkbookActivate is called, it performs a specific action, e.g.:
[Test]
public void TestLogicWhenWorkbookActivates()
{
var mockApplication = new Mock<Excel.Application>();
presenter = new Presenter(mockApplication.Object);
// Act
mockApplication.Raise(a => a.WorkbookActivate += null, (Excel.Workbook)null);
// Assert
// ...
}
Now, when I run this test, it fails when the event is added (which occurs in the presenter's constructor), throwing the following:
System.MissingMethodException : Error: Missing method 'instance void [ExcelAddIns.TestControl] Microsoft.Office.Interop.Excel.AppEvents_Event::add_WorkbookActivate(class Microsoft.Office.Interop.Excel.AppEvents_WorkbookActivateEventHandler)' from class 'Castle.Proxies.ApplicationProxy'.
My understanding, based on this related Stack Overflow post was that what I am performing is a third party callback, and that failed prior to Moq 4.0. I am using Moq 4.2.1402.2112.
So here's the weird part: in that Stack Overflow answer, the Moq bug report is mentioned, which possesses a unit test to test this very concept:
[Test]
public void InteropExcelTest()
{
var mockAppExcel = new Mock<Excel.Application>();
bool isDelegateCalled = false;
mockAppExcel.Object.WorkbookActivate += delegate { isDelegateCalled = true; };
mockAppExcel.Raise(ae => ae.WorkbookActivate += null, (Excel.Workbook)null);
Assert.True(isDelegateCalled);
}
And this test, indeed, passes, which implies that my first test should be valid as it is properly handling the event. But what's even stranger is that the inclusion of this test into my unit test .cs file causes the previously failing test (TestLogicWhenWorkbookActivates) to pass!
These tests are completely independent. Why is the presence of the second causing the first to pass?
After some additional research and experimentation, I believe I have solved my problem. I'm not an expert on interop, so if I make any false conclusions here please feel free to edit or correct me.
I was working with two projects:
ExcelAddIns.TestControl
ExcelAddIns.TestControl.Tests
Both required VSTO references (including Microsoft.Office.Interop.Excel, among others). All VSTO references had Embed Interop Types set to true (which I believe is the default). Based on what I've read (see references below), this was the key to the problem, as it effectively separated the assemblies' embedded types, causing a clash when my Unit Test referenced the TestControl project.
Thus, my solution was to set Embed Interop Types to false for all VSTO assembly references in both projects. This caused the unit test to pass without the presence of the second test.
References:
Stack Overflow: Moq & Interop Types: works in VS2012, fails in VS2010?
Stack Overflow: What's the difference setting Embed Interop Types true and false in Visual Studio?
Daniel Cazzulino's Blog: Check your Embed Interop Types flag when doing Visual Studio extensibility work