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

Remote Registration of NetOffice Assemblies

Sep 30, 2016 at 6:12 AM
Hi!

I'm currently developing a word add in, which by now runs perfectly in my local environment! Since I need to deploy this for multiple users, my created assemblies and all needed NO assemblies are placed on a fileserver, parallel to another application that contains some files, that I need (configuration files for servers and more). It's also necessary to know, that an excel instance is created after calling specific methods from inside word.

The problem is, the add in should be registered on a terminal server which is not the file server mentioned above! Currently it runs perfectly until the point excel starts. Actually excel runs fine and opens the file that I want to, but when the following code is going to be processed the software crashes with the message: "Worksheet not found in loaded assemblies."
foreach (NetOffice.ExcelApi._Worksheet sheet in excelWorkbook.Worksheets)
Again if the add in is registered localy, everything runs fine! The funny part is... it already worked with remote registration and after the last weekend, something changed. Maybe Windows Updates did things? The question is now if there's any setting/configuration/permission, that could trigger that issue or - which would be worse - specific code elements haven't been registered correctly.

The only useful information that I could find so far is related to this topic: http://netoffice3.rssing.com/chan-15397442/all_p32.html#item631
"Worksheet not found in loaded NetOffice Assemblies"
Sounds like a reference problem. NO cant' find the loaded ExcelApi.dll in the current AppDomain. I need to know your NetOffice version and operating system version to reproduce the problem. (op-system in test and failed prod system) BTW: make sure the solution is not loaded from a network ressource(forbidden in .NET default policies)
Any suggestions to determine issues? : (
Sep 30, 2016 at 6:18 AM
Edited Oct 4, 2016 at 5:58 AM
Oh! And some more information about the environment:

The terminal server is running Windows Server 2012 R2 Standard Edition. NetOffice is version 1.7.3. The add in is registered with:
cd \Windows\Microsoft.NET\Framework64\v4.0.30319
regasm \\RemoteFileServer\FileShare\MyAddIn.dll /tlb:MyAddIn.tlb /codebase
Oct 5, 2016 at 12:56 PM
UPDATE:

In my project I changed the "embed interop types" setting in the properties of the VBIDE reference from true to false. Since I'm not really shure how they work exactly and I don't mind having some more Mb in my assemblies, I skipped that 'optimization'. So far everything works fine! The error "Worksheet not found [...]" is gone and all my methods are working with registration by network!

But.. I'm a bit confused. This "emed interop types" thing should check your code and will embed the functionality of the used assembly functions into your own assembly... if I understand it correctly. So I asume there is an issue with the routine that checks "NetOffice.ExcelApi.Worksheet" and determines that my assembly isn't using it?

Maybe if someone can be a bit more specific what this property does and how it could effect the network registration? Because I'm a bit uncertain if this really is the solution, even though it works right now!

Thanks! : )
Oct 17, 2016 at 1:41 PM
Hi,

had nearly the same experience:
A method that defines a variable of type NetOffice.ExcelApi._WorkSheet fails on one computer (Win2012 x64 with Office 2016 x64):
        private bool hasSheet(string sheetName)
        {
            bool hasSheet = false;
            foreach (NetOffice.ExcelApi._Worksheet sheet in excelWorkbook.Worksheets)
            {
                if (sheet.Name.Equals(sheetName, StringComparison.InvariantCultureIgnoreCase))
                {
                    hasSheet = true;
                    break;
                }
            }
            return hasSheet;
        }
After searching google a long time (and found nothing) I changed my code in order to prevent using a reference to this type...
        private bool hasSheet(string sheetName)
        {
            bool hasSheet = false;
            try
            {
                var sheet = excelWorkbook.Sheets[sheetName];
                hasSheet = true;
            }
            catch (Exception ex)
            {
                Logger4net.Log("Sheet '{0}' does not exist in workbook", Logger4net.LoggerMsgType.ERROR, ex);
            }
            return hasSheet;
        }
HTH,
Karsten
Coordinator
Oct 17, 2016 at 8:09 PM
irgs

i do no understand the problem. "embed interop types" is a setting that gives you compile time errors. we talk about runtime errors right?
@karsten_prv: I do not understand your problem. If you german(it looks so for the name) please explain me the problem in german.

Sebastian