For the preview version of NetOffice 1.4 you changed some instances of IEnumerable to IEnumerable<T>. In at least one case this is problematic when using NetOffice from VB.NET:
(ExcepApi) Application.Sheets returns an object of type Sheets. Sheets is an enumerable, but does not contain Worksheet objects only, it can contain Charts too. So in the COM TypeLib the Sheets.Item just returns an IDispatch*.
Now, in NetOffice 1.3.2, the Sheets implemented IEnumerable, and the following code worked fine:
Function SheetExists(SheetName As String) As Boolean
SheetExists = False
For Each Sheet In Application.Sheets
If Sheet.Name = SheetName Then ' <<< IMPORTANT LINE
SheetExists = True
This works because "Sheet" is implicitly typed "As Object" and so Sheet.Name is resolved late-bound, normally with no problem. This matches the behaviour in VBA.
However, in the NetOffice 1.4 preview the Sheets type implements IEnumerable<LateBindingApi.Core.COMObject>. Thise means the compiler tries to resolve the "Name" property at compile time, which fails.
I suggest IEnumerable<T> that would be of type COMObject should rather be left as IEnumerable, to return Object types allowing late-binding and to improve VBA compatibility.