Test that Project Reference doesn't exist

Question

I have a Visual Studio solution with a number of projects. Most projects are for internal/intranet use, but a small handful are for public facing websites.

For internal projects, I use a ProjectName.Data project with Entity Framework that access the database.

For the public projects, I use a different data access method which is only allowed to hit stored procedures in a certain schema.

As part of my integration/system testing, I want to ensure that these public projects do not have a reference to the ProjectName.Data project (eg, make sure some dev didn't say hey, there we go, I'll add a reference here and boom, easy access to the whole boat ).

As part of my MSTest project for this public facing, I want to be able to do something like this:

[TestMethod]
[TestCategory("Integration")]
public void CheckNoAccessToDataProject() {
    var ref = ProjectUnderTest.GetReference("ProjectName.Data");
    Assert.IsNull(ref);
}

I did find a way to possibly shoehorn this by using Type.GetType("Full.Name.To.EF6.Context") but I would much prefer to check the reference itself.

Answer 1

You can use Roslyn for that. First install nuget package Microsoft.CodeAnalysis.Workspaces.Common, then:

var solutionPath = @"path to your solution .sln file";
var msWorkspace = MSBuildWorkspace.Create();
var solution = msWorkspace.OpenSolutionAsync(solutionPath).Result;
var dataProject = solution.Projects.First(c => c.Name == "ProjectName.Data");
var testProject = solution.Projects.First(c => c.Name == "NameOfProjectYouTest");
var hasReference = testProject.AllProjectReferences.Any(c => c.ProjectId == dataProject.Id);

Answer 2

To address the concern that you've described, you might want to consider one or a combination of other methods which might be better (and possibly easier to implement):

1) You can create a custom Visual Studio extension that prevents such forbidden references from being added in the first place (through the UI, anyway).

2) You can check for such references in pre-commit hooks (script checks XML in .csproj files) so that even if they are added, they never make it into source control . Here are possible starting points for Git and SVN .

3) You can check for them in code and pull-request reviews -- this is a "process" solution rather than a technology one. This way, the references may get checked into a development branch, but they'd never make it into a release branch .

4) You can catch them at build time with a custom MSBuild task /target . The advantage here is that you'd arguably be operating at the ideal level of abstraction -- MSBuild is where project references are read, resolved, and used for compilation.

5) You can catch them later at test execution time , which is what you're trying to do. I wouldn't say it's bad to check for these errors at this stage, but naturally it would be better to catch them earlier , especially if the risk/cost of data exposure is high.

I don't know much about the Visual Studio object model, but here are some SO questions ( #1 , #2 , #3 , and #4 ) and an MSDN article that might help with this approach.