Subversion permissions and Visual Studio projects

Question

I have a quite specific question regarding Subversion structure, different permission levels and Visual Studio projects and solutions: We develop a framework with external partners with functionality the partner is not allowed to see.

Consider following structure of a VS solution:

example.sln
|_ /unit1/unit1.csproj (incl. cs files)
|_ /unit2/unit2.csproj (incl. cs files)
|_ /unit3/unit3.csproj (incl. cs files)

unit1 and unit2 belongs to the framework, unit3 is specific (secret) functionality. Framework is functionally without unit3 (which will be shipped as dll).

My question now is: How can this project be structured if the two parties should have a functional development environment, example.sln references unit3, but our external partner won't have this part because of the SVN permission. We, of course, have full access to the repository.

I hope my request has become clear... Am I one a wrong track with my question?

EDIT: Thanks to this answer I see clearer. Last question: How to implement different solutions for different groups so that each group can only check out their solution:

• two sln files in one directory with different permissions
• two directory trees for each solution with links to the shared projects?

Answer 1

You have to create a separate solution which will reference only the projects your partners have access to.

If public projects use secret projects, those secret projects won't be included in the solution, and will be simply referenced in their binary form (like you reference an assembly from .NET Framework or any library within a DLL that you download locally). NuGet can also be used, if appropriate.

Note that this also creates a few issues with the dependencies. For example, if the secret unit3 relies on the public unit1 and your partner modifies the interface of unit1, the change won't be reflected in unit3, which will in fine break the build. Make sure your partners understand that, and agree on some guidelines relative to the changes which affect public interfaces.