This project has moved. For the latest updates, please go here.

Interop type 'Application' cannot be embedded. Use the applicable interface instead

Mar 28, 2012 at 9:26 PM

I copied in some source code from Example05 from SamplesVB and I ran into this compile time error:

Interop type 'Application' cannot be embedded. Use the applicable interface instead.

Searched about this and I resolved this by changin the Embed Interop Types property from True to False. 

I wonder if that could be the reason why I get a runtime error trying to open a workbook stored at bin\debug\DataFiles\Pipes.xlsx. 

Here is a bit of my code:

Private Sub LoadExcelData()
            ' Initialize Api COMObject Support
            LateBindingApi.Core.Factory.Initialize()
            ' start excel and turn off msg boxes
            excelApplication = New Excel.Application()
            excelApplication.DisplayAlerts = False
            excelApplication.Visible = False
            ' add a new workbook
            workBook = excelApplication.Workbooks.Open("\\DataFiles\\Pipes.xlsx")
            Dim workSheet As Excel.Worksheet = workBook.Worksheets(1)

Here is the error:

System.InvalidOperationException was unhandled
  Message=An error occurred creating the form. See Exception.InnerException for details.  The error is: See inner exception for details.
  Source=CBMI.InstrumentDemo
  StackTrace:
       at CBMI.InstrumentDemo.My.MyProject.MyForms.Create__Instance__[T](T Instance) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 190
       at CBMI.InstrumentDemo.My.MyProject.MyForms.get_MainForm()
       at CBMI.InstrumentDemo.My.MyApplication.OnCreateMainForm() in C:\Users\john\Documents\Visual Studio 2010\Projects\CBMI.PipeAnalyzer\Instrument\My Project\Application.Designer.vb:line 35
       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
       at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
       at CBMI.InstrumentDemo.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.Runtime.InteropServices.COMException
       Message=See inner exception for details.
       Source=LateBindingApi.Core
       ErrorCode=-2147467259
       StackTrace:
            at LateBindingApi.Core.Invoker.MethodReturn(COMObject comObject, String name, Object[] paramsArray)
            at NetOffice.ExcelApi.Workbooks.Open(String filename)
            at CBMI.InstrumentDemo.InstrumentDemo.MainForm.LoadExcelData() in C:\Users\john\Documents\Visual Studio 2010\Projects\CBMI.PipeAnalyzer\Instrument\Mainform.vb:line 657
            at CBMI.InstrumentDemo.InstrumentDemo.MainForm..ctor() in C:\Users\john\Documents\Visual Studio 2010\Projects\CBMI.PipeAnalyzer\Instrument\Mainform.vb:line 47
       InnerException: System.Reflection.TargetInvocationException
            Message=Exception has been thrown by the target of an invocation.
            Source=mscorlib
            StackTrace:
                 at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
                 at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
                 at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
                 at LateBindingApi.Core.Invoker.MethodReturn(COMObject comObject, String name, Object[] paramsArray)
            InnerException: System.Runtime.InteropServices.COMException
                 HelpLink=xlmain11.chm
                 Message=Microsoft Excel cannot access the file '\\DataFiles\pipes.xlsx'. There are several possible reasons:

� The file name or path does not exist.
� The file is being used by another program.
� The workbook you are trying to save has the same name as a currently open workbook.
                 Source=Microsoft Excel
                 ErrorCode=-2146827284
                 InnerException:
I am on a development machine, Excel is no longer open at all let alone to that file. 

Coordinator
Mar 28, 2012 at 9:46 PM

hello john,

the first one, yes set the embedd settings to false and it works. i'm still learning about the COM embedding feature, what i know so far is you cant embedd CoClasses, Excel.Application is a CoClass, just interfaces are supported for the embedding feature. The new NetOffice assemblies contains the PrimaryInteropAssembly attribute, thats the reason for the compiler option, but NetOffice assemblies are not really stupid interop assemblies of course.
the reason for the attribute in the NetOffice assemblies is easy. its make the IRibbon Interfaces usable, there also declarated in the NetOffice assemblies BUT as simple early bind declaration and not as a wrapper class. if you write an addin and implement IRibbonExtensibility the compiler try to register NetOffice for COM Interop and fails. the PrimaryInteropAssembly attribute make sure the compiler dont try to register Netoffice but a sideeffect is the IDE offers you the embedd feature with true by default. set always to false.

the second one, the error occured in the last line ? no i think one line before. you always need the absolute path to the file as i know so far.
the xlmain11.chm in the exception trace indicates you use excel 2003 maybe, you have different versions installed?

Sebastian

Mar 28, 2012 at 11:05 PM
Edited Mar 28, 2012 at 11:06 PM

Hi Sebastian,

The 1st error was just a guess of mine (wondering if affected 2nd error); anyway, thanks for the explanation.

The 2nd error you also helped me on. Most examples I have seen show something in the root drive like:

workBook = excelApplication.Workbooks.Open("c:\\Pipes.xlsx")

As soon as I disabled the User Access Control on my PC of which I am the only user and an administrator, I was able to create a little XLSX file in the root and then in turn my code works. But your observation that you always need the absolute path to the file is very interesting and helpful. I will explore that more because I  am just getting started. I think your product is very, very cool (I worked on an Outlook Addin sometime ago and it WAS a hassle with different versions of Office.

Coordinator
Mar 28, 2012 at 11:22 PM

hello john,

looks like you convert some VBA stuff to a VB.NET application. its different maybe in a VBA environment and you dont need a full qualified path here.
since windows vista you dont have permission to write in a root directory like C: or D: you have also no permissions to write in your own application folder by default (unfortunately) a secure method is Environment.SpecialFolder.

Console.WriteLine("GetFolderPath: {0}", Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData));

you have full access by default for this directory.



Sebastian