🐛 NetOffice.Core 1.7.4.11: System.NullReferenceException: 'Object reference not set to an instance of an object.'

[jozefizso]

Quick Fix 🡒 Migrate to NetOfficeFw packages

To fix this issue, migrate your project to use our official packages which are named NetOfficeFw and are published by netoffice account.

This bug does not exists in the NetOfficeFw.Core v1.7.4.11 package and it is not a bug in the official NetOffice source code.

Symptoms

When you use packages like NetOffice.Word, NetOffice.Excel, NetOffice.Oulook and others published by netofficedotnet on NuGet.org, you will encounter error System.NullReferenceException: 'Object reference not set to an instance of an object.' when using NetOffice code.

Note the missing Fw in package names.

In Output window you will see an exception is thrown when calling NetOffice code:

Exception thrown: 'System.NullReferenceException' in NetOffice.dll
Object reference not set to an instance of an object.

This exception is thrown by method NetOffice.Core.TryLoadAssembly(string fileName):

NetOffice.dll!NetOffice.Core.TryLoadAssembly(string fileName)
NetOffice.dll!NetOffice.Core.Initialize(NetOffice.CacheOptions cacheOptions)
NetOffice.dll!NetOffice.Core.CreateKnownObjectFromComProxy(NetOffice.COMObject caller, object comProxy, System.Type wrapperClassType)
ExcelApi.dll!NetOffice.ExcelApi._Application.Workbooks.get()

Cause

There are packages on NuGet published by Erika LeBlanc (GitHub account erikaleblanc88, NuGet account netofficedotnet) which are fake packages of NetOffice assemblies. That account is doing a lot of shady stuff in the https://github.com/netoffice organization (rewriting code history, deleting comments and issues, etc).

Because the published packages contain fake assemblies, you will encounter this exception by using NetOffice.Core v1.7.4.11.

[jozefizso]

Another issue with the NetOffice.Core is error like this:

Factory is not initialized with NetOffice assemblies.

NetOffice.NetOfficeException: Factory is not initialized with NetOffice assemblies.
at NetOffice.Core.GetFactoryInfo(Object comProxy)
at NetOffice.Core.CreateObjectFromComProxy(COMObject caller, Object comProxy)
at NetOffice.ExcelApi.Sheets.Add()

[ErikDeRoos]

Ah, I feel sorry for you guys that this thing with erikaleblanc88 is happening to you.
But thanks @itsho for directing me from the 'Factory is not initialized' issue on that other repo (https://github.com/netoffice/NetOffice/issues/15) to here.

This switch to NetOfficeFw does help me. Just remove the other office package first, and then add this one. Using this exact sequence is key in upgrading: They have exactly the same names and namespaces and any other sequence will leave you with the package not dropping its content properly.

[kev160967]

Hi, just been caught out by this today. Initially we were getting the Factory is not initialised error. I switch the packages out to the FW equivalents, which fixed the issue for me, but our users then reported another error, running under Citrix. I jumped onto citrix to take a look, but couldn't reproduce the error. It's clear from our logs though that I'm the exception. This is the stack trace from the error they are getting:

Outer Exception:
   COMException
   Unable to create instance of:<Outlook.Application>  This is typically because you have no access to the desktop subsystem from a Windows Service/IIS module in default configuration because it is running in a restricted context/principal.
   at NetOffice.COMObject.CreateFromProgId(String progId, Boolean factoryAddObject)     
   at NetOffice.OutlookApi.Application..ctor(Boolean enableProxyService)     

Inner Exception:
Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 8000ffff Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)).

   at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(RuntimeType objectType)     
   at System.Runtime.Remoting.Activation.ActivationServices.CreateInstance(RuntimeType serverType)     
   at System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK(RuntimeType serverType, Object[] props, Boolean bNewObj)     
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)     
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)     
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)     
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)     
   at System.Activator.CreateInstance(Type type)     
   at NetOffice.COMObject.CreateFromProgId(String progId, Boolean factoryAddObject)

The above trace came when using FW package version 1.8.1.0. The error was triggered by the following line of code:

using (var outlookApp = New Outlook.Application())

Our previous release of this app in July was using 1.7.3.0. Our initial deployment today using the non FW packages was also reporting itself as 1.7.3.0, but a compare of the files shows they are different - this sounds very dodgy! For now I'm going to remove all the packages and add a static dependency to the working 1.7.3.0 files. It would be great if you were able to suggest how to fix our issues with 1.8.1.0

[jozefizso]

This is not issue with 1.8 packages. It's issue with the server configuration and you must use Office from a session which has desktop access. This requires correct configuration of user account and/or Windows Service settings.

Regarding 1.7.3 libraries - the issue you are reporting is because of using the NetOffice.Core nuget package and it does not happen with NetOfficeFw.Core package which always bundle the correct version of libraries.

[kev160967]

These sessions do have desktop access though, and indeed the same code worked this morning before a deployment, and worked again after we rolled back both the initial deployment with the old packages and the new deployment with the FW packages. The 1.8 packages also worked for me in my citrix session, just not for many (if not all) of our citrix users?

[kev160967]

Hello @jozefizso, I have some more information on this, but I will raise a new issue as its not related to this problem especially