Plugin System Suggestion

Feb 19, 2010 at 6:08 PM

Hi guys,

I took a look at your new plugin system and it looks very nice.  It seems very simple and straightforward to create a plugin.

I have ran into one problem.  I'm trying to create a SVN source control based incrementor ( as you know :) ).  In order to get the repository information, I need to know the location of each project file.  The problem is that the BaseIncrementor.Increment() function doesn't provide this information.

My suggestion is to either pass in SolutionItem.Filename to the Increment method as an additional parameter; or, to pass around the SolutionItem instance itself to the method -  the exisiting parameters are taken from SolutionItem already as well.  I think that passing the solution item might be the best way to go as it could provide the most information to any one else who wants to implement another plugin.

I can submit a patch that passes in the FileName string.  I didn't try the "passing the SolutionItem" option because the class is marked as 'internal' and I don't want to mess with your scheme of things.

Please let me know what your thoughts are on this or if you need any help.  Thanks again for creating the plugin system!

Feb 19, 2010 at 6:49 PM

Hi Grimus,

I'm keeping the SolutionItem internal because I've got this feeling that we'll need a massive refactor for VS2010. So for now we'll pass the arguments separately; in this case a string for the filename.

If you can wait till tomorrow then I can fix it for you (got to spend some qualitytime with gf) otherwise that patch would be great :)


Feb 19, 2010 at 7:21 PM

Yeah that makes sense, VS 2010 could very well redo everything on you.

I submitted a patch on the patch page (now that I've found the page ;) )

There's no rush, take your time and have fun.

Mar 10, 2010 at 4:31 PM

Hey thanks!

I just got a chance to test it and it seems to work great.  I'm going to release a codeplex project pretty soon so others can start using.  Hopefully tonight if I have time.

Mar 12, 2010 at 8:23 AM

Hi guys,

another option to consider is to include the plugins here in this project/solution; this way it's easier maintained when we change something in the footprint of the plugin system (and we probably will). Otherwise we're forcing users to make note of the BVI version in combination of the version of the plugin. 

I've added grimus account to the team.

(And sorry for the uncomfortable silence from my side; am snowboarding again and the internet connection is terrible here)


Mar 14, 2010 at 6:52 AM

We will most certainly not.

The reason this addin is relative popular is because we've made it small & easy to maintain; there's no need to over complicate things just because it's cool to implement. If you feel different about this, you're still free to fork it somewhere.

Don't get me wrong; I highly appreciate the bugfixes and the global settings feature you did, but you don't own the project. I always make remarks when I'm using code that I didn't created, but doing things like naming the road map after yourself seems abit like stealing the kudos. And that does not work very well within the open source community.

Besides, I was talking to grimus; he's the one who wrote the code.

Mar 15, 2010 at 3:51 PM

Hi guys, sorry for the slow reply, I've been traveling all weekend.

Thanks for the project add!  I don't think you'll have to worry too much about the plugin system changing... its pretty simple right now and I can't really see it getting too much more complicated.  If it does change it should be pretty easy to adapt quicky, unless for some strange reason there's 50 new methods to implement but I'm not sure why that would happen.  It should be easy enough to mark plug-in releases for the appropriate version of BVI if a breaking change occurs.

I'm glad to see you found the project, is it.  I hope the name isn't too goofy, but I like it.