Registering Excel-DNA XLL via startup of VSTO addin

Aug 22, 2013 at 2:54 PM
Edited Aug 22, 2013 at 2:55 PM
Hi

We are deploying via Clickonce a VSTO addin which at startup registers a XLL exposing a function to Excel.
I've seen plenty of posts on the subject and on our development machines with local admin rights it's all fine.
We do something like that in ThisAddIn_Startup where our XLL file has the same assembly name as the main VSTO addin (MyAddin.dll and MyAddin.xll) :

string assemblyPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase);
string xllPath = Path.Combine(assemblyPath, Assembly.GetExecutingAssembly().ManifestModule.Name.Replace("dll", "xll"));
xllPath = xllPath.Substring(6);
Application.RegisterXLL(xllPath);

As stated previously it's perfectly fine when with local admin rights but without it it doesn't work and Application.RegisterXLL will always return false no matter what.

I am testing this on Win 7x64 and Excel 2010 x86 using the release 0.3 x86 Excel DNA xll loader.

The odd thing is when double clicking the XLL file directly from a machine without local admin rights will enable the function to be available to Excel so the issue seems to be around registering the DLL from the VSTO addin itself.
We've tried by removing pretty much every security restrictions in Excel and it still didn't help, nothing shows up in the registry neither and with fusion logging turned on I don't see anything showing up in the log directory (might be my problem that one).

Many thanks
Coordinator
Aug 22, 2013 at 6:16 PM
Hi,

What version of the .NET runtime are you targeting - both for VSTO and Excel-DNA?
(I.e. is there a RuntimeVersion attribute in your .dna file?).

It's more likely to work under .NET 4 than under the .NET 2.0 runtime.

-Govert
Aug 23, 2013 at 8:38 AM
Hi Govert
This is a .Net 4.0 compiled application with Visual Studio 2012 compiled with Any CPU switch and we run this with Excel 2010 x86.
To help simplify my issue I created a brand new VSTO Excel Addin and even though it works fine on my machine with local admin rights it doesn't without.

C# project:
  • Name: ExcelAddin1
  • VSTO40
  • Any CPU
  • Target : .Net Framework 4
  • Added reference to ExcelDna.Integration with Copy Local = true (without it ClickOnce wouldn't work, might need to sign it possibly..)
  • Added files as content for ExcelAddin1.dna and ExcelAddin1.XLL build of 0.30 x86
In ThisAddin:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
    {
        MessageBox.Show("Starting...");

        string assemblyPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase);
        string xllPath = Path.Combine(assemblyPath, Assembly.GetExecutingAssembly().ManifestModule.Name.Replace("dll", "xll"));
        xllPath = xllPath.Substring(6);

        Application.RegisterXLL(xllPath);
        var registered = Application.RegisterXLL(xllPath);
        MessageBox.Show("Registered " + registered);
    }
In ExcelAddin1.dna:
<DnaLibrary RuntimeVersion="v4.0">
<ExternalLibrary Path="ExcelAddin1.dll" />
</DnaLibrary>

Excel DNA integration :

public class ExcelDnaBootStrapper : IExcelAddIn {
public void AutoOpen()
    {
        MessageBox.Show("IExcelAddIn.AutoOpen()");
        RegisterErrorHandlers();
    }
}

To run this lot I just compile it and then double click on the VSTO file in the bin directory to install it.

What we've witnessed is that on x64 Windows 7 machines with local admin it works (registerd property is true) whilst on x86 Windows 7 with local admin doesn't work. Really confusing.


Daniel
Aug 23, 2013 at 11:30 AM
UPDATE: On a x64 Windows 7 machine which could run the VSTO bit but where the Application.RegisterXLL(pathToXllFile) would always return false can now fully function (XLL loaded correctly and Application.RegisterXLL returns true) after having installed Visual Studio 2012 on it.
Aug 27, 2013 at 10:43 AM
A colleague of mine is suspecting that it might be due to possibly an older revision of Visual C++ Redistributables that get updated when installing Visual Studio 2012 (not tried if adding Visual Studio 2010 solves the XLL loading issue or not).
Would any of you know which version of these DLLs are required by either EXCEL, VSTO runtime and Excel DNA ?
Thanks!
Coordinator
Aug 27, 2013 at 10:55 AM
Hi Daniel,

The native part of Excel-DNA is statically linked to the C runtime libraries and does not require any C/C++ runtime library on the machine. Only the .NET framework is required. Am I right to understand that the Excel-DNA loads correctly when you just copy it and File->Open or double-click, and that you only have problems when loading via the VSTO add-in?

I don't know about the requirements VSTO - there are different versions but you need to install the VSTO runtime in some way (though I'd expect the installer wizard to help with that.) Maybe the Microsoft VSTO forums can help.

A large motivation for the existence of Excel-DNA is so that VSTO can be completely avoided. You might want to consider going in that direction...

Regards,
Govert
Aug 27, 2013 at 12:23 PM
Hi
Thanks for your reply.
We're looking at what's wrong in our setup and what we have is a standard Visual Studio 2012 compiled with .Net 4.0 VSTO 4.0 project which only does one thing which is Application.RegisterXLL which will always return false unless Visual Studio 2012 is installed on the client (all Windows 7) whether it's running with local admin rights or not.
We've used Process Monitor and on my DEV machine I see events related to loading up .DNA and .XLL files but none of that on the client.
We've enabled Fusion Logging, VSTO logging but nothing's showing up there or in Event Viewer.
I appreciate your advice with regard to VSTO and so far we'd still like to go down this route to benefit from the build-in support of ClickOnce deployed application by Excel but again my exp
Thanks
Aug 27, 2013 at 12:37 PM
Would you believe it, our issue might have been related to case sensitivity!
So what we saw is that on machines without Visual Studio installed the call to Assembly.GetExecutingAssembly().ManifestModule.Name would have at least the extension file type upper case and our code wasn't case insensitive to find the XLL name by convention.
string xllPath = Path.Combine(assemblyPath,
                                      Assembly.GetExecutingAssembly().ManifestModule.Name.__ToLowerInvariant()__.Replace("dll", "xll"));
Weird bug happening to me in a long time.
Coordinator
Aug 27, 2013 at 2:29 PM
Hi Daniel,

OK - that's a pretty nasty bug. Well done on tracking it down!

Earlier versions of Excel-DNA running under .NET 2.0 had problems due to the VSTO security model, but those issues have been resolved AFAIK.

Anyway, if you're just using VSTO for deployment, I'd really suggest you consider other approaches. A few users use a meta add-in that downloads and loads different versions of the real add-in. So the meta add-in must be installed on the client once (copy the file and "Alt+t, i" to add as an Excel add-in) and then the rest is managed through a ribbon or form from Excel.

VSTO is particularly problematic is you're dealing with different Office versions.
I think the version of VSTO that works with Excel 2013 requires .NET 4.5...?

Cheers,
Govert