AutoGenerateBindingRedirects doesn't work properly

[lanfeust69]

When an addin's csproj has both the AutoGenerateBindingRedirects and GenerateBindingRedirectsOutputType properties defined to true, the App.config file is (potentially) enriched with needed bindingRedirects when it is copied as MyAddIn.dll.config.

However, within the CreateExcelAddIn task, the handling of App.config uses the original App.config, and therefore misses the bindingRedirects.

As a workaround, one can add to the csproj a target along the lines of :

  <!-- The CreateExcelAddIn task called in ExcelDnaBuild uses directly the App.config file, so it misses auto-generated bindingRedirect -->
  <Target Name="CopyAppConfig" AfterTargets="ExcelDnaBuild">
    <Message Importance="High" Text="Copy $(TargetPath).config to $(TargetDir)EudaPlugin-AddIn[64][-packed].xll.config" />
    <Copy SourceFiles="$(TargetPath).config" DestinationFiles="$(TargetDir)MyAddIn-AddIn.xll.config" />
    <Copy SourceFiles="$(TargetPath).config" DestinationFiles="$(TargetDir)MyAddIn-AddIn-packed.xll.config" />
    <Copy SourceFiles="$(TargetPath).config" DestinationFiles="$(TargetDir)MyAddIn-AddIn64.xll.config" />
    <Copy SourceFiles="$(TargetPath).config" DestinationFiles="$(TargetDir)MyAddIn-AddIn64-packed.xll.config" />
  </Target>

But it would probably be better to try to use the processed MyAddIn.dll.config file in the task.

[augustoproiete]

Thanks for reporting this one @lanfeust69.

I've been meaning to do some work on this for a while, ever since I tried to use slow-cheetah with Excel-DNA add-ins, which also makes changes to the final App.config file, that are not picked-up by the CreateExcelAddIn.

The workaround you have probably works for 95% of the use-cases, but I'm afraid a fix wouldn't be as simple as baking in what your workaround does, because:

1. A class library can have more than one .dna file, and an .xll w/ a .config gets created for each one
2. The relationship between the assembly and the add-in is described inside each .dna file via ExternalLibrary so to get the "correct" enriched .config for each .dna. We'd have to know which assembly to use first - and that might mean parsing each .dna file during the build process :unamused: ... That also brings the question of what to do when a .dna file has more than one ExternalLibrary element (supported).

Any chance you're interested in sending a PR to improve this story?

[lanfeust69]

@augustoproiete : thanks for the additional insights.

I didn't have the time to dig things deeper and come up with a PR, and that's why I opened the issue in the first place, to keep track 🙂.

I don't expect to be able to investigate further in the coming weeks, but hopefully I can find a bit of time later on...