Wix install for local machine and blank workbook at startup

Jul 8, 2014 at 1:54 PM
Hello, we are facing a problem with our install process.

Indeed, we had a wix project for the installation of our addin that was similar with the ExcelDNA / Wix Installer sample. The problem was that the installation is performed per user (using a registry key for the current user). However this solution was not a viable one for us. We install addins from midsize companies to large ones where we needed a local machine install not a current user one (SCCM, Citrix etc.). The OPEN registry key used in the process mentioned above does not work with HKEY_LOCAL_MACHINE registry. Finally, we rewrote our wix so that the .xll is copied to the XLStart directory and we do not use registry key anymore.

The problem we are facing now is the following: when the user opens Excel, alone not with a double click on an excel file, we do not have the expected empty workbook. It seems that putting the addin in XLStart changes the default behavior of excel which was to open alone with a blank workbook.

If we install the packed .xll addin "manually" we do not have this problem. We have tested it with Office 2010.

Do you have a suggestion regarding this problem?
Coordinator
Jul 8, 2014 at 2:15 PM
Hi,

I presume you mean you are copying the .xll file into the C:\Program Files (x86)\Microsoft Office\Office14\XLStart\ directory (I have Excel 2013, so it's \Office15\XLStart for me).

When I just copy a single -packed.xll file in there (I have no other files there at the moment) I don't see the behaviour you report. If you start from an Excel that works normally (i.e. opens a blank workbook) and then manually copy the .xll into that directory, do you then have the problem?

-Govert
Jul 8, 2014 at 2:54 PM
Edited Jul 8, 2014 at 2:55 PM
Hi Govert,

sorry for not being very precise in my original post.

When I just copy a single -packed.xll file in there (I have no other files there at the moment) I don't see the behaviour you report. If you start from an Excel that works normally (i.e. opens a blank workbook) and then manually copy the .xll into that directory, do you then have the problem?

Yes it is the very action of putting the packed.xll addin in the XLStart directory that changes the behavior when opening excel alone (no double click on a file). I have tested on three machines two with Excel 2013 (x86 and x64) and one with Excel 2010 (x64) that works normally.

Without the addin in XLStart directory
Excel2010: opens a blank workbook
Excel2013: opens the startup excel 2013 page

With the -packed.xll file copied in XLStart directory
Both excel 2010 and 2013 starts with the addin loaded but without a default workbook. The startup page is skipped with Excel2013

In addition, to reproduce my problem I have just found out that all previous instances of excel must be closed.
Coordinator
Jul 8, 2014 at 3:09 PM
Hi,

Could you try with a trivial Excel-DNA add-in that has no Ribbon or anything strange (maybe just some UDFs), and has nothing in an AutoOpen() routine?

When trying to load the Ribbon, Excel-DNA needs to get hold of the Excel Application COM object. This is very hard when Excel starts up - so Excel-DNA sometimes loads a workbook behind the scenes to force creation of the Application object. Maybe this is causing the trouble. If you have no ribbon or anything that uses Application early on, this won't be happening, so that's a useful test.

-Govert
Jul 8, 2014 at 3:48 PM
Thank you for your quick replies,
indeed, I have also tried with a very basic addin, that is created with the sample project provided while installing with the 0.32 Nuget package. There is no ribbon, only a basic UDF.
Coordinator
Jul 8, 2014 at 3:53 PM
OK, that's strange. I don't see the same on my machine.

Can you make sure to disable all other add-ins, both Excel Add-Ins and COM Add-Ins?

If you still get it, then I'm not sure how to reproduce it.

-Govert
Jul 8, 2014 at 4:51 PM
Hi Govert,

I have retried with an addin created from scratch after having disabled all other addins. I am still experiencing the same problem with many different configs but all within my company (same install process etc.). I will try with my personal laptop tonight and keep you in touch....

To make sure that we agree, I detail below my current configuration and my minimal reproduction scenario.
  • Open Visual Solution 2013 and create a .NET 4.5 class library project called mysample.
  • Use the Nuget Package Manager for the solution and look for the ExcelDNA 0.32 sample Online. Install it for the only project mysample.csproj.
  • Create a static class with the basic UDF provided here ( the SayHello one).
  • Right click project properties and make sure that in Start external prorame the path to Excel.exe is ok. In addition fill up the path towards the generated (non packed) .xll that is appropriated with the bitness of your office version wich is "C:\mysample\bin\Debug\mysample-AddIn64.xll" in my case.
  • Press F5 and make sure that the addin is well loaded and the UDF SayHello is recognized
The addin is created and works fine.
  • Close all Excel instances. In the task bar look for Excel and open it. With Excel2013 you should see the start up page (see post above).
  • Close Excel again
  • In the XLSTART empty directory whose path is "C:\Program Files\Microsoft Office\Office15\XLSTART" for my x64 Excel2013 put the mysample-AddIn64-packed.xll that has been produced either in Debug or Release output directory.
  • All excel instances being shut. Open excel similarly to the first bullet (e.g. Search from windows start the Excel application).
    Excel2013 does not open with its usual startup page but empty. see my screenshot
Thank you very much!
Jul 9, 2014 at 9:30 AM
Hi again,
I have tried with Excel 2013 SP1 x86 on my Windows 8.1 x64 Home and I do experience the same issues: addin well loaded (the Udf is well executed) but the default workbook is skipped when excel is started alone.

Some things that I have remarked:
there are two XLSTART folders. Indeed, one which is per user and located under a path that looks like "C:\Users\<username>\AppData\Roaming\Microsoft\Excel\XLSTART"; and another one at "machine level" that is located next to the EXCEL.exe executable (the one that we use for the install). For both folders if I put my packed .xll in the folder and I have the issue.

Remark, that the XLSTART directory at "machine level" was not there with my "Home" config. However, I created it manually and experienced the same problem.

Govert, are you still unable to reproduce? Do you want us to push the minimal sample project to a public github, so that you can try?

Do you think of an alternative that we could think of? For example, Office COM ADD-In for all Users or the HKLM propagation

Thank you
Coordinator
Jul 9, 2014 at 1:27 PM
Hi,

OK, I was a bit more careful now, and I get the same behaviour you report on my machine, both with an Excel-DNA add-in and with a sample from the official Excel SDK. So the behaviour is not related to Excel-DNA, but true for all .xll-based Excel add-ins.

As far as I know, the key propagation introduced in Excel 2010 won't apply to regular .xll Excel add-ins.

The only other approach I know of is to use the Active Setup feature - though I've not tried this myself.
This allows you to run some setup code at the first time a new user logs in, so you could write the registry key then.
(I would love to know if you try and whether it works.)

See:
-Govert
Jul 9, 2014 at 3:16 PM
Thank you very much Govert,

I think we will give a try with ActiveSetup for setting HKCU key each time a new user logs in. We will keep you in touch.

A note to those who would stick with XLSTART folder despite of the problem mentioned here. You may have a surprise: we found out a situation where an Excel32bits is installed on the Program Files folder instead of the Program Files (x86).
see this post