-
-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make ExplicitExports "true” by default (or at least make it default in the .dna template) #29
Comments
However, I'm happy to have the template in the NuGet package include both the <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> |
@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 I do, however, think would be nice to go a little bit further and - at least - declare it as |
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 |
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 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. |
Check-in 37326da adds the ExplicitExports="false" to the .dna file template. |
I think
ExplicitExports
should betrue
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 declareExplicitExports="true”
there so that anyone creating a new add-in will get the expected behavior (and also makes this attribute more discoverable).The text was updated successfully, but these errors were encountered: