What is excel dna

When cloning the main repository, a lot of files immediately appear as being modified because they are currently stored using Linux line-endings, and the .gitattributes file is set to make the transformations based on platform (LF => CRLF).

Hey Govert,

I recently updated from 0.32 to 0.33 to see if I can get that sweet Intellisense working. In doing so I noticed it’s now registering all public static methods in my assembly as excel functions.

My expectation (and I believe the prior behaviour) was that only methods with the [ExcelFunction()] attribute or similar would get registered. Is there an easy way to get back to that?

As discussed in #15 we should write one or more custom MSBuild tasks, ship them into one assembly, and have a custom build target to run them as part of the build.

These MSBuild tasks would be responsible for copying the XLL to the bin folder, as well as running ExcelDnaPack based on a conditional compilation symbol.

This is somewhat related to issue #18, where I’m proposing that we move the Excel.exe path and add-in to the project file, so that the debugging information is persisted in source control, and any developer that clones the repository would then be able to debug the add-in without having to configure anything.

We know that we can’t control what version of Excel each developer has installed on his/her machine… Some developers run Excel 2010 32-bit, others run Excel 2010 64-bit, others Excel 2013 64-bit, etc.

I’d like a developer to be able to clone my repository, open my solution in Visual Studio, and just hit F5 and be able to Debug it, starting an instance of the Excel installed on his/her machine, no matter what version is there, and with the right add-in XLL file (x64 or x86) for that debugging session.

Whilst I don’t have a perfect solution for that yet, I do have a workaround that have been working well for most cases:
Inside the project file, I add a few conditional property groups that define the StartProgram variable with the correct path of the Excel on the machine (if matches any, of course)

<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:Program FilesMicrosoft OfficeOffice15EXCEL.EXE')">
  <StartProgram>C:Program FilesMicrosoft OfficeOffice15EXCEL.EXE</StartProgram>
</PropertyGroup>
<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:Program FilesMicrosoft OfficeOffice14EXCEL.EXE')">
  <StartProgram>C:Program FilesMicrosoft OfficeOffice14EXCEL.EXE</StartProgram>
</PropertyGroup>
<!-- etc... -->

I also have the similar conditionals for 32-bit Excel installed on Windows 64-bit machines:

<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:Program Files (x86)Microsoft OfficeOffice15EXCEL.EXE')">
  <StartProgram>C:Program Files (x86)Microsoft OfficeOffice15EXCEL.EXE</StartProgram>
</PropertyGroup>
<PropertyGroup Condition="'$(StartProgram)' == '' AND Exists('C:Program Files (x86)Microsoft OfficeOffice14EXCEL.EXE')">
  <StartProgram>C:Program Files (x86)Microsoft OfficeOffice14EXCEL.EXE</StartProgram>
</PropertyGroup>
<!-- etc... -->

And a similar kind of test is applied to determine the right add-in to execute (32-bit or 64-bit)

  <PropertyGroup Condition="'$(StartProgram)' != '' AND $(StartProgram.Contains('Program Files (x86)'))">
    <StartArguments>"MyXL-AddIn.xll"</StartArguments>
  </PropertyGroup>
  <PropertyGroup Condition="'$(StartProgram)' != '' AND (! $(StartProgram.Contains('Program Files (x86)')) )">
    <StartArguments>"MyXL-AddIn64.xll"</StartArguments>
  </PropertyGroup>

And finally, conditional to set the StartAction property

<PropertyGroup Condition="'$(StartProgram)' != ''">
  <StartAction>Program</StartAction>
</PropertyGroup>

What are your thoughts on this (or something like this)?

ps: These MSBuild instructions don’t necessarily need to be on the .csproj (could be a custom .targets file added to the project to make it easier to edit from within Visual Studio).

I have compile my project and works good with Excel 2010 but its ribbon not showing in Excel 2007 version.

Is there any workaround to compstible ExcelDna with multiple Excel version?

Hello,
I added the following lines to an Excel Command (a brand new Excel-DNA project).
Trace.TraceInformation(«Trace information!»);
Trace.TraceWarning(«Trace warning!»);
Trace.TraceError(«Trace error!»);

I expect to see the LogDisplay opens (because of TraceError) and I expect to see the two last messages (because TraceInformation should not be logged by default).

The documentation states:
«If there is no .xll.config configuration file for the add-in, or there are no entries related to the ExcelDna.Integration TraceSource in the .config file, the following configuration is made»

Nonetheless, when I debug the running code, the Trace class has only the DefaultTraceListener.

Am I missing something or is this a bug?
Thanks in advance.

NB: I am running Excel 2013 64 bit

I find working with the App.Config file a really hard task. I have been wondering on how to actually ease my pain and I found a solution which seems to work partially : It gets done through a class that I found on SO :

Is there a better way to actually work with an app config file that is already built in? If not, would you consider integrating the class I have been using? The problem is that whenever I use the ConfigurationManager Excel looks for the config file in MyDocuments since that is the default working directory for Excel.

For add-ins that expose the COM Server, there is an additional step in the build process, to run TlbExp to generate a .tlb file from the compiled .dll.

It would be nice to have that as an option in the build process.

Minor issue worth resolving in the next release.

The code here meant to fix the «Excel Function Description bug» is resulting in already well formatted function argument descriptions getting two periods:

The solution is probably as simple as trimming off any trailing period and space before adding it back:

argumentDescriptions[j] = argumentDescriptions[j].TrimEnd(new[] { ' ', '.' }) + ". ";

This will play nice with people whose argument descriptions already end in «. » or just «.»;

If we want to be more sensitive to people who choose to have things like ellipses at the end of their descriptions (and we probably do), maybe something more long winded, like:

if (!argumentDescriptions[j].EndsWith(". "))
{
    if (argumentDescriptions[j].EndsWith("."))
        argumentDescriptions[j] += " ";
    else
        argumentDescriptions[j] += ". ";
}

That way descriptions like:
"Custom tags, metadata, etc..." will be converted to:
"Custom tags, metadata, etc... " rather than
"Custom tags, metadata, etc.... " or
"Custom tags, metadata, etc. "

     Running something like this on non-UI thread would cause Excel-Dna to throw an exception wihout any inner exception details.

        var addinPath = (string)XlCall.Excel(XlCall.xlGetName); // exception gets thrown over here.
        var addinDir = addinPath.Substring(0, addinPath.LastIndexOf('\'));
        var configPath = @"Resourcesconfig.xml";

        var filePath = Path.Combine(addinDir, configPath);

        return filePath;

I think ExplicitExports should be true by default as IMO this is what most ExcelDna developers would want/expect.

I’ve been bitten by this before I knew this attribute existed, and leaked a few static classes as formulas in an add-in, which caused me some pain.

I realize this could break existing add-ins, but sometimes breaking changes are necessary — and if documented well, should not cause too many issues.

If introducing this change is not an option in the short-term, I’d suggest at least update the ExcelDna-Template.dna to declare ExplicitExports="true” there so that anyone creating a new add-in will get the expected behavior (and also makes this attribute more discoverable).

<DnaLibrary Name="%ProjectName% Add-In" RuntimeVersion="v4.0">
  <ExternalLibrary Path="%OutputFileName%" LoadFromBytes="true" Pack="true" ExplicitExports="true” />
</DnaLibrary>

documentation suggestion

In Excel-DNA — Step-by-step C# add-in.doc, in addition to Load the corresponding ExcelDna64.xll file instead. can you please add Also, ensure that the ExcelDna64.xll file is used in the packing process if applicable? This would make it absolutely clear that this is necessary.

code changes necessary for x64 xll packing

The following code in SourceExcelDnaPackPackProgram.cs had to be changed from

xllInputPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, «ExcelDna.xll»);

to

xllInputPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, «ExcelDna64.xll»);

I get an ExcelDna.Integration.XlCallException after trying to access XlCall.Excel(XlCall.xlGetName) from a ribbon.

The same accessing technique works if I use it from an UDF.

The error comes from over here :

This is a (slightly modified) feature request that was asked in the mailing-list, so just adding as an issue so we can track this better and possibly encourage someone to implement and send a PR.

Original requests:

• Exposing resource info in ExcelDNAPack
• Versioning the xll for Windows Installer

My assumption is that the developer (or ideally the continuous integration system) should be responsible for setting the right version information about the add-in, in the main assembly (or in all of them). With that said, we should be able to describe in the Excel-DNA XML file which assembly should be used to read version information about the add-in (version number, copyright, product name, etc.) and any information available in this assembly should automatically replace what is in the XLL file, during the build of the project.

I would suggest this to be implemented as a regular MSBuild Task, rather than implementing this as part of the ExcelDnaPack utility given that people might not care about packing their add-ins — and still would like to get version information in the XLL that gets copied during the build.

This is a follow-up to the issue #61 . We have fixed the crash, but still con’t allow the .xll to unload completely if COM features were used.

Revisit this and implement DllCanUnloadNow() if possible.

They should use macros to determine the path based on the project (or solution path).

This would enhance the experience of developing an Excel add-in with a team or developing an open-source add-in, as any person would be able to clone the repository and compile the project, no matter what folder structure they used.

Add a way to monitor registration progress and particularly failures. It can be hard to see why some functions are not registered — perhaps because of incompatible signatures, scope or visibility. It would be useful to have a general logging mechanism to monitor the loading and registration, mainly for trouble shooting.

This should be an opt-in mechanism, perhaps defining an ILogging interface, and having a place to register a logger implementation early in the load sequence (AutoOpen might be too late).

@AlanStubbs wrote:

I’ve been working on an adaptation of the AddInReloader project and it all works fine until I have RtdServer-based UDF calls in the workbook. In this case, my «master» addin is unable to fully unregister the current «slave» addin (ExcelIntegration.UnregisterXLL(path)) so that subsequently trying to delete the current slave xll produces a System.UnauthorizedAccessException. Strangely, it allows me to rename the slave xll file to slave.backup but then when I register the new slave addin (RegisterXLL(slave)), it actually registers slave.backup again.

I’ve tried adding calls to ComServer.DllUnregisterServer() in various locations — the slave’s AutoClose, before/after the call to UnregisterXLL, etc — all to no avail. All the problem code is running inside QueueAsMacro.

Do you expect this behaviour — and do you know what I can do to fix it? With a blank workbook, everything works perfectly. I’m using Excel-DNA.0.32.0.

Many thanks,
Alan

Issue originally reported in the ExcelDna mailing-list:
https://groups.google.com/forum/#!topic/exceldna/LHsR2dZkl8g

A function like this

[ExcelFunction(IsExceptionSafe = true)]
public static string GetBool(bool b)
{
    return b.ToString();
}

called from Excel with an unrecognized string parameter like «a» will cause Excel to crash.

This is due to the marshaling failure in Excel-DNA causing an unhandled exception which is leaked to Excel (since the IsExceptionSafe=true inhibits generation of the exception handling wrapper).

The fix would be to ignore the IsExceptionSafe=true flag for functions that have a boolean parameter.

I am updating a client UDF package that included some ribbon menus and built in documentation so the function would show up in the function directory during spreadsheet entry and the types would validate.

The demo software DOES NOT FUNCTION out of the box on 64 bit.
I had to fall back to compileing 32 bit and it seems to work on 64 bit excel.

Add automated builds through AppVeyor, and packages published through a MyGet feed, for Excel-DNA and the Registration extension.

I have registered accounts with both in the past, but I still have to figure out how the permissions and accounts should work to allow others to work on this.

There also a tool to help with the NuGet package configurations, but I can’t find it now…

Hi Govert,

We have been using ExcelDNA for a while now and it has been working brilliantly. Microsoft released the Framework update 4.6.1, and now 64bit Excel with ExcelDNA does not work. The sample code returns #num when the function is being executed.

Our code — which is slightly modified crashes excel and the exception is occurring in the CLR (using windbg to trace). Uninstalling the 4.6.1 update does not fix the issue. A complete uninstall of Framework 4.0 and subsequent re-install of 4.5.2 fixes it.

I am certain that ExcelDNA is not the culprit but that Microsoft update is. Any advice on how to pursue to get a fix?

When an unhandled exception occurs in ExcelDnaPack, it lets it bubble up to the caller, and crashes. This causes MSBuild/Visual Studio to show the dialogs below:

We need to catch any unhandled exceptions in Main, and return a Environment.ExitCode >= 1 to signal that it failed — so that MSBuild can fail the build too.

Currently it is not possible to unit test Excel add-ins built with Excel DNA, because pretty much all interactions one does with the Excel DNA framework requires calling methods in static classes, which in turn call Excel APIs/features and because these are static classes, it is not possible to mock these classes.

I’ve made a good process with my ExcelDna.Abstractions project which addresses many of these issues, but it is not ideal and it is harder to maintain as Excel DNA moves and new methods are added.

I’d like all static classes that relies on Excel functionality to be implemented as regular classes that also implement interfaces (so that we can depend on these interfaces instead, and be able to mock) and then mark the static classes Obsolete, to encourage devs to use the new regular classes/interfaces.

This issue is somewhat related to issue #20.

When I install the Excel-DNA NuGet package, it adds the instructions to allow me to debug the add-in by starting Excel and passing the add-in file as a parameter, which is great.

Unfortunately it doesn’t make this change in the project file (e.g. .csproj). Instead, it updates the user’s file related to the project (e.g. .csproj.user) which is individual for each developer, and therefore is not committed to the source control.

Example of a .csproj.user file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/ ...">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <StartAction>Program</StartAction>
    <StartProgram>C:Program FilesMicrosoft OfficeOffice15EXCEL.EXE</StartProgram>
    <StartArguments>"MyExcelAddIn-AddIn.xll"</StartArguments>
  </PropertyGroup>
</Project>

In practice, what happens is that when a developer clones a repository from source control and tries to debug it, it never works…

The workaround so far, is to manually copy/paste the contents of the .csproj.user file into the .csproj file.

Example of a manually changed .csproj file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- ... -->
  <PropertyGroup>
    <!-- ... -->
    <TargetFrameworkVersion>v4.5.1</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <StartAction>Program</StartAction>
    <StartProgram>C:Program FilesMicrosoft OfficeOffice15EXCEL.EXE</StartProgram>
    <StartArguments>"MyExcelAddIn-AddIn.xll"</StartArguments>
  </PropertyGroup>
  <!-- ... -->

What I would like, is for the NuGet package to update the .csproj file with the StartAction, StartProgram and StartArguments, instead of updating the .csproj.user file (and equivalent for other languages).

Do you think there’s any way to pack XLLs on Linux?

When I try, I get the following error:

Using base add-in Blah-AddIn.xll

Unhandled Exception:
System.EntryPointNotFoundException: BeginUpdateResource
  at (wrapper managed-to-native) ResourceHelper:BeginUpdateResource (string,bool)
  at ResourceHelper+ResourceUpdater..ctor (System.String fileName) [0x00000] in <filename unknown>:0 
  at ExcelDnaPack.PackProgram.Main (System.String[] args) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: BeginUpdateResource
  at (wrapper managed-to-native) ResourceHelper:BeginUpdateResource (string,bool)
  at ResourceHelper+ResourceUpdater..ctor (System.String fileName) [0x00000] in <filename unknown>:0 
  at ExcelDnaPack.PackProgram.Main (System.String[] args) [0x00000] in <filename unknown>:0 

Same error wether I download the binaries or build from source.

Hi,
I’m quite new to Excel-DNA but already find it really powerful. I seem to me exception handling mechanism in Excel-DNA is not able to catch an exception thrown in C# within user’s code. For instance, I have a dummy function named «divide» which takes as argument 2 doubles. In practice, the exception thrown by the null division returns #Value, which does not give me much information about what’s happening.

I would expect Excel-DNA to return the actual Exception message and the name of the main method which throws the exception.

I took a look at the source code and a quick fix in the method HandleUnhandledException could do the trick instead of just returning ExcelError.ExcelErrorValue. What do you think ?

Rgds,
Yenyenx

After a long hour running, always crash the Excel with «System.NullReferenceException»

The following are the variable info. Strangely the pOper is 0x0000000c0 for the last string value of the ManagedObj.

With the below config, app will get the NULL exception because of the Debug.print() output in initialization.
All the Debug methods won’t check the TraceFilter. So there is no way to directly use the «LogDisplay» for error message popup.

The NULL exception is caused by the «LogDisplay.RecordLine(message);» That function doesn’t check whether the «LogStrings» is null.

If add the following check, LogDisplay can be used directly.

if (LogStrings == null)
            return;

App.config

<sharedListeners>
  <add name="LogDisplay" type="ExcelDna.Logging.LogDisplayTraceListener,ExcelDna.Integration"/>
</sharedListeners>

<trace autoflush="false" indentsize="4">
  <listeners>
    <remove name="Default"/>
    <add name="LogDisplay"/>
  </listeners>
</trace>

When installing the NuGet package into an F# project in VS 2015, there is an error:

Exception setting "Value": "Object of type 'Microsoft.VisualStudio.FSharp.ProjectSystem.BuildAction' cannot be converted to type 
'VSLangProj.prjBuildAction'."
At C:TempFs2015TestpackagesExcelDna.AddIn.0.33.7-rc1toolsinstall.ps1:56 char:13
+             $newDnaFile.Properties.Item("BuildAction").Value = ([Microsoft.Visua ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], SetValueInvocationException
    + FullyQualifiedErrorId : ExceptionWhenSetting

This is not a serious setting to change, and everything else still seems to work.

Another F#-related problem in the NuGet install script is to configure the Debug executable. F# uses a different project system and this setting is not (easily) accessible.

I have a following function and it does not return in XlCall.Excel and throws an exception,

private static object PrintArray()
{
    object[,] retArray = new object[3, 1];
    for (int i = 0; i < 3; i++)
    {
        retArray[i, 0] = DateTime.Now;
    }
    var returnArray = XlCall.Excel(XlCall.xlUDF, "Resize", retArray);
    return returnArray;
}

Exception:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at ExcelDna.Loader.XlCallImpl.TryExcelImpl12(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Loader.XlCallImpl.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.ExcelIntegration.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.XlCall.TryExcel(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.XlCall.Excel(Int32 xlFunction, Object[] parameters)
   at AsyncFunctions.ArrayResizer.Resize(Object[,] array)
   at Wrapped_f12_Resize(Object[,] )
   at ExcelDna.Loader.XlCallImpl.TryExcelImpl12(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Loader.XlCallImpl.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.ExcelIntegration.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.XlCall.TryExcel(Int32 xlFunction, Object& result, Object[] parameters)
   at ExcelDna.Integration.XlCall.Excel(Int32 xlFunction, Object[] parameters)
   at PlantSiSReport.Functions.PrintArray()

I’d like to be able to setup my IoC container via an entry-point of the add-in (my understanding is that the AutoOpen of a class implementing IExcelAddIn will be the very first thing to run when Excel loads the add-in)

public class AddIn : IExcelAddIn
{
    public void AutoOpen()
    {
        // Setup my IoC container
        myContainer.Register<AwesomeService>.As<IMyService>();
        myContainer.Register<GreatLogger>.As<ILog>();
    }
}

And then be able to have dependency resolution on any of my Ribbons in the add-in, ideally via constructor injection (*).

[ComVisible(true)]
public class ModelingRibbon : ExcelRibbon
{
    public ModelingRibbon(IMyService service, ILog logger)
    {
        // ...
    }
}

(*) Not sure if constructor injection would not be possible… Looks like the Ribbon instance is constructed before the AutoOpen runs, which would invalidate the idea of setting up the container in the AutoOpen.

Anyway, goal is to have an entry point that allows the opportunity to setup an IoC container, and have dependency resolution across the different instances created by the framework.

When packing a large number of assemblies (about 80), the new multi-threaded packing fails with a message

System.NotSupportedException: The number of WaitHandles must be less than or equal to 64.
   at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles, Int32 millisecondsTimeout, Boolean exitContext)
   at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles)
   at ResourceHelper.ResourceUpdater.EndUpdate(Boolean discard)
   at ResourceHelper.ResourceUpdater.EndUpdate()
   at ExcelDnaPack.PackProgram.Pack(String[] args)
   at ExcelDnaPack.PackProgram.Main(String[] args)

There is a limit on the number of events we can wait for, and currently we make an event per assembly that is packed.

@konne If you’re still around, would you perhaps like to look at this?

A workaround is to run the ExcelDnaPack without multi-threading, by adding the /NoMultiThreading switch to the command line.

Initially reported on CodePlex: https://exceldna.codeplex.com/discussions/581717#

RTD server objects derived from the ExcelRtdServer base class are not released by the registration mechanism after ServerTerminate(). As a result, the server instances live as long as the Excel process. This may have to do with the COM server support implemented by Excel-DNA.

A partial workaround to mitigate the memory leak might be to set all references to further managed objects in the ExcelRtdServer-derived class are set to null in the ServerTerminate() implementation.

It is a strange error. It is all right to invoke the RTD in the UDF, which call the UDF in the excel sheet cell . But if call it in the ribbon, the exception will be raised. In the debugger, I can see the request is processed properly by RTD. Just before return, the following exception will be raised.

UDF:

  public static class UserDefinedFunctions
{
    [ExcelFunction(Description = "start the RTD server for order submission & price data")]
    public static object startServer(String IP, int port)
    {
        return XlCall.RTD("ExcelTradeGateway.FIXRTDServer", null, new string[] { "CONFIG", IP, port.ToString()});
    }
}

UI:

 <group id="dtExcelSetttings" label="Settings">
                        <editBox id="rtdPeriod" label="Refresh period" onChange="OnPeriodChange"/>
          <editBox id="rtdServer" label="FIXGateWay" onChange="OnServerChange"/>
                    </group>

Code to call RTD, which will cause the exception

[ComVisible(true)]
public class Ribbon : ExcelRibbon
{

    public void OnServerChange(IRibbonControl control, string text)
    {
        object val = UserDefinedFunctions.startServer(text, 123);
    }
}

Exception detail:

  Exception thrown: 'System.AccessViolationException' in ExcelDna.Loader.dll
    ExcelDna.Integration Error: 5 : The RTD server of type ExcelTradeGateway.FIXRTDServer required by add-in ExcelTradeGateway could not be registered.
    This is an unexpected error.
    Error message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
                                                                RtdRegistration.RTD exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
                                                                                                                                                                             at ExcelDna.Loader.XlCallImpl.TryExcelImpl12(Int32 xlFunction, Object& result, Object[] parameters) in V:GitHubExcelDnaSourceExcelDna.LoaderXlCallImpl.cs:line 154
                                                                                                                                                                             at ExcelDna.Loader.XlCallImpl.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters) in V:GitHubExcelDnaSourceExcelDna.LoaderXlCallImpl.cs:line 80
                                                                                                                                                                             at ExcelDna.Integration.ExcelIntegration.TryExcelImpl(Int32 xlFunction, Object& result, Object[] parameters) in V:GitHubExcelDnaSourceExcelDna.IntegrationExcelIntegration.cs:line 43
                                                                                                                                                                             at ExcelDna.Integration.XlCall.TryExcel(Int32 xlFunction, Object& result, Object[] parameters) in V:GitHubExcelDnaSourceExcelDna.IntegrationXlCall.cs:line 1113
                                                                                                                                                                             at ExcelDna.Integration.Rtd.RtdRegistration.TryCallRTD(Object& result, String progId, String server, String[] topics) in V:GitHubExcelDnaSourceExcelDna.IntegrationExcelRtd.cs:line 176
                                                                                                                                                                             at ExcelDna.Integration.Rtd.RtdRegistration.TryRTD(Object& result, String progId, String server, String[] topics) in V:GitHubExcelDnaSourceExcelDna.IntegrationExcelRtd.cs:line 142

The ExcelDnaDoc package (http://mndrake.github.io/ExcelDnaDoc/index.html and https://github.com/mndrake/ExcelDnaDoc) provide automatic help file generation for Excel-DNA add-ins. It also installs some post-build events (and assumes that these run before the ExcelDna.AddIn build events).

We need to check how it is impacted by the new ExcelDna.AddIn build targets approach, and whether the package needs to be updated to align the build steps from ExcelDnaDoc with ExcelDna.AddIn.

@mndrake might be able to able to help, otherwise it might be suggested as a pull request to the ExcelDnaDoc project.

from https://exceldna.codeplex.com/workitem/9366

Me:

I had to be very careful with the command-line arguments to ExcelDnaPack. My previous comment about packing failing was due to omitting leading ‘. ‘ from the paths and had nothing to do with mixed-mode assemblies (I incorrectly thought it had something to do with this as I had a reference to a mixed mode assembly in the solution but was not referencing it in the anywhere else in the code nor in the .dna)

Govert:

Are you saying that it makes a difference to ExcelDnaPack whether put the arguments as «.XXX.dna» vs. just «XXX.dna»? Do you have any idea why that would be?

Reproduce by omitting the leading .

C:workDummyCTPDummyCTPbinDebug>ExcelDnaPack.exe DummyCTP.dna /O DummyCTP.xll /Y
Output directory could not be created. Error: Path cannot be the empty string or all whitespace.

Exiting ExcelDnaPack.

The problem appears to be with this line:

   string outputDirectory = Path.GetDirectoryName(xllOutputPath);

I found that specifying a leading . on the output argument is sufficient.

C:workDummyCTPDummyCTPbinDebug>ExcelDnaPack.exe DummyCTP.dna /O .DummyCTP.xll /Y
Using base add-in C:toolsExcelDna.xll
  ->  Updating resource: Type: ASSEMBLY_LZMA, Name: EXCELDNA.INTEGRATION, Length: 60651
  ->  Updating resource: Type: CONFIG, Name: __MAIN__, Length: 524
  ~~> ExternalLibrary path DummyCTP.dll resolved to C:workDummyCTPDummyCTPbinDebugDummyCTP.dll.
  ->  Updating resource: Type: ASSEMBLY_LZMA, Name: REINSCTP, Length: 4959
  ~~> Assembly path NLog.dll resolved to C:workDummyCTPDummyCTPbinDebugNLog.dll.
  ->  Updating resource: Type: ASSEMBLY_LZMA, Name: NLOG, Length: 119256
  ->  Updating resource: Type: DNA, Name: __MAIN__, Length: 1035
Completed Packing .DummyCTP.xll.

I will check out a couple of these suggestions for command-line processing (not my favorite topic!) and see if any of them look appropriate
http://stackoverflow.com/questions/491595/best-way-to-parse-command-line-arguments-in-c