Add-in opens as new spreadsheet w/ ASCII chars, bitness correct

[johnk...@gmail.com]

Hi,

We have an add-in which is not loading properly for some users in an enterprise environment. 

The add-in is installed via a package manager which correctly writes an "OPEN" key the Excel\Options registry settings.

When users open excel, the add-in shows in the splash screen as "Text Opening: XXX.xll". When open, the ASCII values from the add-in binary are shown in a sheet and no code is executed.

I double checked that the user was not using the wrong version of the .xll(i.e. they are using 32bit excel and our standard 32 bit packed .xll:).

Any idea on where to begin? It seems sort of like a file association issue inside of excel, but that's a wild guess.

Thanks,

John

[Govert van Drimmelen]

I would suggest you first re-check the 32-bit / 64-bit issue.

The symptom would be exactly what you are seeing, and things have gotten a bit more confusing these days, since 64-bit Excel is now the default.

Also, the package manager or installer might be failing to detect the Excel bitness, or installing the wrong version of the add-in.

 

You could give such a user the two versions of your add-in, and ask them to try both from File -> Open to see if either one works.

 

If it really is not that, you’ve discovered a new problem, and we would have to examine further.

 

-Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/dc02e858-de54-419a-8309-0018ef9e41d9n%40googlegroups.com.

[Gareth Hayter]

One of my users is having exactly the same problem. I think it is to do with the version of Excel that runs with the virtualised registry. If he loads the XLL by double-clicking it, or by opening via Excel's File>Open, then it loads correctly. It's only when installed via my installer which writes the usual entries to the registry that this problem occurs.

Kind regards,

Gareth.

[John Reagan]

Thanks to you both, Govert & Garrett. 

I did confirm the user is using the correct version(my first suspicion was that they had renamed the 64 bit file while packaging the app). I compared the timestamp from our 32 bit xll to the version Excel was referencing(confirmed it's 32) and then confirmed their version of outlook is 32 bit.

I will ask the user to try opening the .xll by clicking on the file. That would also rule out bitness/missing dependencies being the causec and confirm my user's symptoms are the same as Garrett's. 

I'm also still using version 0.33.9 so I will get a build ready with the latest prod version of Excel DNA and also ask them to try that.

We didn't see anything in the event log and no logs from the add-in are generated, do you have any other strategies for debugging/collecting information in situations like this?

Thank you again,

John

You received this message because you are subscribed to a topic in the Google Groups "Excel-DNA" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/exceldna/Ybhzi82onE8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/7dd7b256-4ecb-47e5-8d13-19c98fd894a1n%40googlegroups.com.

[C. Augusto Proiete]

Excel-DNA Diagnostic Logging
https://github.com/Excel-DNA/ExcelDna/wiki/Diagnostic-Logging

ExcelDna.Diagnostics.Serilog (if you're using Serilog for logging)
https://github.com/augustoproiete/exceldna-diagnostics-serilog

---

Cheers,

C. Augusto Proiete

https://augustoproiete.net

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/CAP%2BZkYyKQCe19HQkSvvsnjO-4%3DQcR2YghkttxAv2W-q3zcZkqg%40mail.gmail.com.

[johnk...@gmail.com]

Thanks to everyone for their help.

First, I have been unable to get ExcelDNA logs due write restrictions in their environment. I'm working with them to determine an appropriate/predicatable path to write to, but that is proving challenging.

Second, I confirmed bitness was not the issue by sending the user only the 32 bit version of the add-in. 

Third, I got process monitor logs which I am currently analyzing, though the amount of information is difficult to parse. I have logs from a user who could successfully load one package and not another. We also tried installing an 'unpacked' version of the add-in and that seemed to make no difference.

One thing I noticed was that these users are in a citrix environment. Looking in the history of the group, I see some references to issues, but not much specific in terms of the issues the environment causes or how to possibly address. Obviously, registry and file system redirection seem like they could cause issues, but I'm unsure of what specifically. Could a lack of permissions on the directory be causing an issue? 

Any advice on how to proceed?

Thanks,

John 

[Govert van Drimmelen]

Hi John,

 

1. If the .xll is never loaded as code (which is the case when Excel shows you the insides) then there will be no logging from the Excel-DNA side either.

There really is no add-in code running in this situation, so there’s no using bothering with logging paths etc.

 

2. Are you able to confirm that the add-in also fails to load if the user goes File->Open to open it directly (instead of the registry entry).

That means you have different symptoms to what Gareth reports.

 

3. I still suggest you also send them the 64-bit version of the add-in.

I say this even though you have “confirmed their version of outlook is 32 bit.”

4. It is possible to install Excel without the VBA component, in which case no .xll add-ins are supported by Excel either.

You can confirm with the user that the VBA feature is present by having them press Alt+F11 in Excel and seeing the VBA interface pop up.

I don’t know how Excel behaves when in this situation.

 

5. Can you explain what you mean by “a user who could successfully load one package and not another”?

 

6. There are various ways of disabling add-ins through the Trust Center, but I would not expect these settings to cause the file to open in Excel that way.

 

7. After these are checked and if they shed no light, the next step I would suggest is to build one of the Excel SDK samples for 32-bit and 64-bit. Then check that both of these also cannot be loaded via File -> Open. At that point I think you have a simple enough situation to get Microsoft support involved.

 

If you need some formal support from my side, you’re welcome to get in touch directly.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/2b5788b0-028a-4743-87d2-d5f313f082ecn%40googlegroups.com.

[Govert van Drimmelen]

8. If your users has applied some Administrative Group Policies, they might be in a situation where a list of allowed add-ins is managed centrally. See https://docs.microsoft.com/en-us/office365/troubleshoot/group-policy/office-add-in-not-loaded and https://getadmx.com/?Category=Office2016&Policy=excel16.Office.Microsoft.Policies.Windows::L_ListOfManagedAddins

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/013701d6bc5c%24dba5af10%2492f10d30%24%40icon.co.za.

[johnk...@gmail.com]

Thank you again. We may reach out about formal support. I very much appreciate your responsiveness.

1. Thanks, I won't waste time on ExcelDNA logs and will assume that code is simply not running.

2. That did not change the user's ability to load the add-in. I believe my symptoms are different than what Garret described.

3. Yes, good idea. I will do that and confirm.

4. Good to know. We will test if VBA is enabled. If it is disabled, we will try to enable and re-test.
5. Yes, let me clarify what I meant by a user is "able to load one package, but not another"

 - I'm working with an app support engineer responsible for building distribution packages for the company via AppV. The AppV package consists of a powershell script which loads the add-in on startup(via the OPEN /R methodology) and the xll.  

- In his case, he's built 3 packages. The first loaded without issue for him, so he pushed to other users who found the issue I described above.

- I sent him a new version, just the 32 bit as I mentioned, which also updated to Excel DNA Integration 1.1.1(along with the other dependency updates). He was Unable to load that one and experiences the same issue.

- Finally, today he received and packaged the 'unpacked' version of the application. He was also unable to load that successfully. 

6. Yeah, we checked those for any obvious issues(also made sure the folder referenced by Excel is in Trusted Locations)

7. I will do that.

8. I don't see that message or same behavior, but thanks. I will double check that.  

[johnk...@gmail.com]

Hi again,

Thank you all for your assistance. I've made progress on the issue.

I built and distributed the sample XLL and the same failure pattern occurred. It worked on the machine that the original package worked on and failed on the same machine the other packages failed on. From my side, I can pretty much rule out our code as being related to the failure.

I'm out of my depths a bit in C++/C, and have one question regarding building the .xll relating to this SO post:

https://stackoverflow.com/questions/46046362/c-excel-add-in-loading-error-xll-file-is-loaded-by-excel-as-text-file

I can see the /MD flag mentioned in the article being set when the sample XLL is being built:

1>Copyright (C) Microsoft Corporation.  All rights reserved.
1>
1> cl /nologo /W3 /WX /EHsc /MT /Fo".\RELEASE\\" /I"." /I"..\..\include" /I"..\..\src" /D"WIN32" /D"_WINDOWS" /D"_MBCS" /D"_USRDLL" /D"EXAMPLE_EXPORTS" /D "NDEBUG" /c EXAMPLE.c
1>EXAMPLE.c
1> cd .\RELEASE
1> link.exe /DLL /manifest /nologo EXAMPLE.obj /OUT:EXAMPLE.xll  /subsystem:windows -def:.\..\example.def /RELEASE /NODEFAULTLIB:msvcrtd.lib /OPT:NOICF msvcrt.lib  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib .\..\..\..\lib\Frmwrk32.lib .\..\..\..\lib\xlcall32.lib
1>   Creating library EXAMPLE.lib and object EXAMPLE.exp
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1> mt.exe /nologo /outputresource:"EXAMPLE.xll;#2" /manifest "EXAMPLE.xll.manifest"

When ExcelDNA builds an .xll file, does it use the /MD or /MT flag? Is there a setting I can use to control that?

I'm out of my depth getting into C/C++ library linking, but didn't find anything obvious in the ExcelDNA documentation.  I can tweak the flag and send another build to the end users, but I'm a bit hesitant to do so unless I understand the implications of the change and if I could make a similar change to our add-in. 

Any help/insight would be greatly appreciated!

Thanks again,

John

[johnk...@gmail.com]

I should add that I understand the basic natures of /MT /MD flags, i.e. dynamic vs static linking, but I'm unsure of the implications when we would be using a more complex add-in, including the .NET framework. 

[Govert van Drimmelen]

Hi John,

 

Excel-DNA statically links the C/C++ runtime:

 

 

.NET (since 4.) manages its own instance of the C/C++ runtime, called msvcr100_clr0400.dll.

 

There is no interaction between the native code part of Excel-DNA, which is small and statically links in the bits of the runtime it needs, and how .NET uses the C/C++ runtime.

 

Changing Excel-DNA to dynamically link to the runtime (which version?) would mean you have to distribute and install the relevant runtime package too. I don’t know of any downside to the static linking, since the native part is really small.

To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/0ddb324f-92db-4c88-b430-90f98e17f53cn%40googlegroups.com.