Question

I have a plugin architecture and I want to code against it, but I want each plugin to have its own solution in its own folder space. Rather than build the framework assembly and toss it into each plugin directory, I thought it might be a good idea to fake the framework assembly (I'm coding against a couple of interfaces and some exception classes) and store that in source control; as long as I did not change the interfaces I was coding against, all should be good. I think.

Is this a bad idea? I have many developers creating plugins, and they are storing them on their local machines in different places with relation to the framework project; it makes source control management annoying. I don't want to commit a .dll to source control though, as it is actively being developed against (not this plugin interface though).

It seemed this would be a good way to use Fakes, but I can't find any examples of how to do it, so maybe I'm creating more problems than I'm solving?

Was it helpful?

Solution

I dont see any approach that can avoid a checkin of atleast one dll into source control, with or without fakes.

To be cleaner I would suggest you split your dll into two. One with the interface with its prerequisites that can be shared with the plugin developers and the second containing whats being actively developed. Since this dll will not have much churn it will not need to be updated that regularly.

Moreover you do not really seem to be needing any particular functionality of the fakes framework to be creating a fakes dll.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top