Make ExplicitExports "true” by default (or at least make it default in the .dna template) about exceldna HOT 5 CLOSED

ExplicitExports should definitely be 'false' by default and should be 'false' in the .dna template by default - this makes the VB situation friendlier, and is compatible with the past.

However, I'm happy to have the template in the NuGet package include both the ExplicitExport='false' tag, and a comment that describes the situation. So anything like this:

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

<!-- ExplicitExport indicates whether exported function and macros need to be explicitly marked with [ExcelFunction(...)] and [ExcelCommand(...)] macros to be exported, or whether all public static methods with compatible signature are registered.
The behavior is as follows: .....

Read more here:....

-->
</DnaLibrary>

from exceldna.

@govert: Could you expand on the "makes the VB situation friendlier" part? Is there a difference between C# and VB with regards to the exports of functions?

Adding the attribute to the .dna template, even if false by default, seems like a step in the right direction to me, so 👍.

I do, however, think would be nice to go a little bit further and - at least - declare it as true for newly created add-ins, and thus still staying compatible with existing add-ins.

from exceldna.

I mean for somebody coming from VBA, it's pretty cool that the basic code can look like this

Public Module MyFunctions
    Function AddThem(v1, v2)
        AddThem = v1 + v2
    End Function
End Module

It's bad enough that you need the Public Module ... around it, but at least you don't need to know about attributes to get started.
I value that enough, together with the backward compatibility, to want to keep the default 'false'.

from exceldna.

Got it.

I see your point re: simplicity, but I honestly question if that is "real code" vs "demo code".

I've never seen a real-world add-in that simple, where every function is self-contained and don't call other utility functions to get some reuse.

As soon as you get into something almost as simple:

Public Module MyFunctions
    Function Calculate(v1, calcType)
        denominator = GetDenominator(calcType)
        Calculate = v1 / denominator
    End Function

    Function GetDenominator(calcType)
        Case calcType = "x"
            GetDenominator = 10
        Case calcType = "y"
            GetDenominator = 20
        Default
            GetDenominator = 1
    End Function
End Module

You're in trouble... As GetDenominator now is exposed to the world and your public API surface is bigger than you wanted it to be - and by the time you notice it, it could be too late and people are already using GetDenominator in their spreadsheets.

Now imagine you have 50 methods that got exposed unintentionally, instead of one... 50 more methods to support / keep backwards compatibility, etc. than you originally planned for.

So in general, I think being explicit on what you make public to the user, leads to a better design.

Anyway, having the attribute in the template is still a good improvement.

from exceldna.

Check-in 37326da adds the ExplicitExports="false" to the .dna file template.

from exceldna.