CODEWITHSUNDEEP
c#reflectionmstest
jleach
jleach

Reputation: 7790

Test that Project Reference doesn't exist

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 (e.g., 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.

Upvotes: 1

Views: 710

Answers (2)

John K
John K

Reputation: 681

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.

Upvotes: 1

Evk
Evk

Reputation: 101593

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);

Upvotes: 1

Related Questions