-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Add support for dependency injection in Excel-DNA #20
Comments
Yes - I don't want to add an IoC dependency into Excel-DNA, but I don't know of any problem in having that inside your add-in. |
Thanks @govert. Indeed, not sure how complicated would be to support injection via the constructor of the Ribbon (I have yet to see how (and who) instantiates it). The issue I normally have with the Ribbon, is that there's not a single point of entry that I can inject all my dependencies, as different methods are called as part of the initialization. e.g.
For this to be possible, Excel DNA would have to - at last - provide me with hooks so that I can plug-in my IoC container (whatever that is). Would you be open to a PR (or set of PRs) that enables something like this? |
I don't understand why you'd need any hooks from Excel-DNA for this scenario. Whether it's in Excel-DNA or in your own add-in library, there must me some global mechanism that holds together the IoC container or dependency injection root. I can't see any reason why this has to involve the ExcelDna.Integration at all. So, to be clear, I would not like to support any IoC infrastructure inside Excel-DNA in the near term. I'm happy with any helpers or examples that should how this might be done inside the add-in library. |
|
The reason is simple: From my add-in, I cannot control the instantiation of my e.g.
I need to have a chance to tell Excel-DNA how to resolve So at the very least, I would need Excel-DNA to give me control on how to instantiate the |
I don't understand. Surely you can have: public class MyAddInImplementation
{
public MyAddInImplementation(IWhatever whatever) {}
}
public ExcelDnaAddIn : IExcelAddIn
{
public void AutoOpen()
{
var whatever = .... // Set up anything you want so that resolving stuff will work
var myAddIn = new MyAddInImplementation(whatever);
}
} This kind of code will either be in |
@govert: Sure, that's pretty much what I have to do today for every single add-in that I support (more than 10, and growing) which is boring and boilerplate code. But this is not the biggest issue, really. The issue is with everything else that happens after the Anyway, this goes hand-in-hand with issue #21, so will close it as well, and hopefully we can revisit it over time. Thanks |
I'm having the same issues and I think your requirement is justified and indeed needed. |
Currently we're forced to use service-locator which is bad and inelegant. I was thinking to fork excel-dna and enable hooking my container in a similar way like in Nancyfx (the web framework) |
Can you explain the problem with setting up your mechanism in the IExcelAddIn.AutoOpen() and then doing the bootstrapping yourself (as in my earlier reply)? Of course you can make a custom build of Excel-DNA with your own dependency resolution mechanism built in, but it seems to me that the mechanism might just as well be set up in your add-in code. |
@augustoproiete Is the real issue that ExcelDNA will create an instance of any It seems for pre-2007 Excel you must manually create an instance of your
The above flow is broken for Excel 2007+ when ExcelDNA takes ownership of creating the If the above is true, would it not be possible to implement our own version of Looking through the code I don't see any other uses of @govert Do you recall the reason for the different handling of Ribbon-based vs non-Ribbon-based Excel ComAddIns? It seems odd to require the developer to only worry about loading the AddIn for pre-2007. -robodude666 |
That is one of the issues, yes. But not the only one. Excel Functions, for example, can use services that ultimately should be resolved by the IoC container. There's no access to any Ribbon instance from
Maybe. It's been a while since I last looked at the internals of ExcelDna, so don't remember much, but based on your comments I think it is def. worth a shot, so at least the Ribbon side could have a better approach to DI. |
Forgot about the Excel Functions, as that's a valid point. Two possible solutions come to mind:
The above allows you to still take use of constructors and test
As for accessing the
I just tried it out and seems to work for both Excel 2002 and Excel 2007. I currently do not have a major use for |
Last time I tried, I remember I was able to do constructor injection if creating a new instance every time (not pretty, lots more work compared to # 2) - could not find a way to do parameter injection, which is what I really wanted.
Yep, this seems to be the least painful... Classic service locator (anti-) pattern.
If you're using MVVM, you'll want to implement Ribbon buttons as Example scenario: A button on the Ribbon can only be enabled if there is at least one Sheet in the workbook (i.e. disable the button after the user closes all Sheets and have an empty workbook). |
@augustoproiete I see from the MVVM point of view you'd want access to the While doing some further research I ran across VSTOContrib which has a very interesting take on VSTO + IoC. I suspect it would be possible to create all of your ExcelFunctions (and other Ribbon elements) as I'll dink around for a bit and see what I come up with 😄. -robodude666 |
It should be very easy to make your own version of ExcelRibbon which is not automatically instantiated. |
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 implementingIExcelAddIn
will be the very first thing to run when Excel loads the add-in)And then be able to have dependency resolution on any of my Ribbons in the add-in, ideally via constructor injection (*).
(*) 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 theAutoOpen
.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.
The text was updated successfully, but these errors were encountered: