Search code examples
visual-studio-2010mefmsbuild-tasksolution

Copy DLL-s on building multi-solution MEF application

I use visual studio 2010 to develop and build on .net framework 4.0. I also use the Managed Extensibility Framework for a basic plugin system.

I have 2 solutions:

The main solution with 6 projects, One is executable the other 5 are class libraries. They reference each other and they are built into a solution level bin folder (the bin folder is next to the project folders). This way all the built bin files are in the same folder, and MEF can collect all the DLL-s in a simple DirectoryCatalog.

This works fine (except for 1 thing, that starting the application does not rebuild all the other projects, since they are not dependencies, but this is not what this question is about).

The other (extension) solution has 2 projects, they are both class libraries and should be somehow added to the directory MEF uses to build it's catalog.

There is a few ways of doing this, I'm just unable to find the cleanest one.

So the issues to solve are:

  1. The extension solution's projects reference projects from the first solution, so I navigated to the main solution's bin folder on the add reference screen and added all the required references. Will the references update on building the main solution, or do will I need to somehow copy the DLL-s manually?

    • The intellisense should recognise the change, so after changing and building the main solution should be recognised and intellisense should update while editing the extension solution.
    • The main solution is buildable on it's own and does not know anything about the extension solution. Let's keep it that way. I wouldn't write a build task to the main solution that copies the dll's to the other solution's folder.
    • The solutions are hosted on an SVN server. It would be a great plus if getting the solutions with ankhsvn on a new computer and building both solutions would require no further configuration.

  2. On building the projects of the extension solution the DLL-s should be copied to the directory that MEF uses for it's catalog (the bin directory of the main solution). It would be good if it also worked upon getting it fresh from svn. This can be done by a build task, but which is the best way to reference an other solution's folder?

    • I think that it wouldn't be a great compromise if the solutions directories must be next to each other (and have the default name) to work (this way I could just use an other level of ../ to reference it). Is it a decent solution? Is there any drawbacks I'm not aware of?
Solution

  • There is another approach to deal with issue 1:

    • Add the necessary projects from Main.sln to the Extension.sln. Υou can do this by selecting "Add Existing Project" from the solution's context menu.
    • Update the references of the extension projects to the added projects and not to their output dlls. Visual Studio will be responsible for locating the output dlls and for deciding when your projects need to be built.
    • You can even add a solution folder named "Dependencies" or something like that and move there all the projects from Main.sln. This way you can tell which are the projects that are "guests".

    This will solve all of the bullets of issue 1, but you will need to be careful because from the Extension.sln you can modify the dependent projects. A plus is that you will also be able to debug your code in a more straighforwad way that will work in a new development machine without any extra work.

    That said, I would go for a single solution with all 8 projects which is straight-forward. Only if the solution was getting huge (~100 projects) I would go for this.

    Regarding you comment about different repositories:

    Also if I commit this to SVN will the "existing projects" also be commited to the new repository?

    I don't think so. If you keep them in the same SVN repository (which I can't see any reason not to), it will be Ok. You can add a lot of solutions to the same repository. As long as they are relevant it is the right thing to do.

    Another valuable test is to take a fresh copy from the repository and try to build it. This can be done daily on a build server and will help you locate problems early on. The less steps it takes to do so the better.