List All Visual Studio Solution References with PowerShell

I recently needed to find which references in a rather large solution referenced specific projects and dlls in other areas of our codebase. The Gist below is a PowerShell script that will output a list of PowerShellCustomObjects with the following properties:

Output Object Properties:

  • ProjectPath (The location of the project file with the dependency)
  • ReferenceType (Either DLL or Project)
  • Name (The name of the dependency)


.\Get-VSSolutionReferences.ps1 [path\to\your\VSSolutionfile.sln]

Chances are, you’ll want to do some kind of aggregation on the output, below is an example of what you can do:

Important Note:

It is important to note that you’ll likely see duplicate dependencies because you’re seeing each dependency on each project of your solution. You can easily slim down the list by using PowerShell’s grouping and filtering.

The Gist:

Validating Castle Windsor Installers

The Problem

If you’ve ever used Castle Windsor, chances are you’ve run into the lovely problem of having misconfigured or missing dependencies. The worst part is that we don’t see these issues until runtime. Even worse is that it’s possible to entirely miss one of these errors and have them potentially make it out to clients!

Chances are you’ve also wondered if there is a way to programmatically validate your dependencies either in your tests, when your application starts up, or perhaps even at compile time. Ponder no longer!

The Solution

While it’s not a silver bullet (yet), below is a method that you can add to tests or your application to make sure that all of your registered classes can be resolved.

Note: I originally was trying to solve this problem and found this solution on StackOverflow. I’ve modified the code a bit to now handle some error cases.

Where can I use this?

Ideally, this would happen at compile time and I believe that that’s possible with Roslyn where we are able to add compiler extensions. Until then, the best places are going to be two locations:

  • Your app start up. Most likely, that’s going to be your AppStart.cs, however, it’s going to be wherever you create your IWindsorContainer.
  • Your unit tests! We may not be able to create build errors (yet), but what we can do is fail our unit tests if the dependencies don’t resolve. Most unit tests have their own WindsorInstaller file separate from the installer file in the actual application. You would have to actually create an instance of the WindsorInstaller from your application to verify that the application, not your tests, is configured properly.

Important Notes

  • This will not tell you when topmost level classes are not registered. This will only work when you have classes registered with an installer / container and then check the dependencies. For example, if you register no classes, then Castle Windsor will have no dependencies to check for, thus, the method I have provided will return successfully.
  • The first time you start using this test, you may notice configuration errors when you expected none. Chances are, those errors are because you have some classes that have dependencies that you manually resolve or don’t have Castle Windsor resolve. There are a few ways to fix this.
    • Use TypedFactories for your factories
    • Make sure that all of your classes can be automatically resolved, meaning that all dependencies can be resolved without having to be constructed manually. Tricky parameters such as those that must be provided at run time  should either be re-architected or you may optionally use inline / dynamic dependencies in Castle Windsor.
    • If you have the case where some code is never automatically resolved with Castle Windsor, then you can also use SubResolvers to tell Castle Windsor that an interface is resolvable and that you’ll handle it manually.
      • Take this following code as an example

In the Install method, we’re telling Castle Windsor that the IBar and IBuzz interfaces are indeed resolvable. Then, in the Resolve method, we’re doing nothing. Wut? This is because typically you would expect to set up how to resolve those interfaces in the Resolve method, but here in our case, we’re not because we know for certain that Castle Windsor will never automatically resolve these interfaces; rather, we manually instantiate these classes via our own factory classes. While this does work, I am still investigating on whether or not there is a better way to do this.

IEnumerable VS. IList with LINQ

If you’ve stumbled across this post, chances are, you’ve become pretty familiar with IEnumerable and how often it can be / is passed as a parameter. What you may not know is that using this high level interface, while powerful, can have severe performance implications when used with LINQ.

Why do we use IEnumerable?

We use IEnumerable because essentially it is one of highest (most generic) interfaces for dealing with lists. It’s simple, many list types can be created from it, and having it in a method declaration pretty much states that you’re passing in a list that is to be enumerated.

What can go wrong using IEnumerable?

Yo dude, you said severe performance implications get to the point! Yea I know, cool your jets; I meant it. While IEnumerable is great, there is a small detail that can mean big problems for your code: IEnumerable’s GetEnumerator enumerates your list every time you call an action on that list.

Here’s an Example

I’ve gone ahead and posted an example on dotnetfiddle so that you can see and run the code yourself. Or take a peek at the code below:

Let’s have a super simple DoWork function with an IEnumerable parameter:

Now, let’s use that function with both an IEnumerable and IList parameter:

The output you would expect would be as follows:

IEnumerable Hit Count : 5
IList Hit Count : 5

Here is the actual output:

IEnumerable Hit Count : 10
IList Hit Count : 5

What wizardry is this!? Clearly you are a magician well beyond the capabilities of modern day science and logic!

Not quite, and here’s why:

Here’s what’s going on

The fact that we’re using IEnumerable and IList actually has little to do with the problem we’re seeing. The actual problem stems from LINQ’s implementation behind each interface.

LINQ’s implementation of IEnumerable is lazy and will only evaluate the query once you use the output of that query. However, while the implementation is lazy, it also runs your query every time you use the output of the query.

LINQ’s implementation of IList enumerates through the entire list once (when you call ToList()) and then stores that output and will not enumerate the list again.

In the example that I have listed, The reason we are seeing the IEnumerable example increment the count 5 more times is because we are enumerating through the list:

  • Once when we call .Count() (.Count iterates through the results hence why the incrementin function is called 5 times) (also, as a side note, never use .Count() to check if a list has any objects in it…I merely did it to further illustrate my point).
  • Once more when we access the filteredList in the foreach loop

Here is when LINQ enumerates through the list when we call the IList example:

  • Once when we call .ToList(). The results are then saved and we do not re-run the query when for either the .Count or foreach loop.

Sooo IEnumerable is evil and I shouldn’t use it right?
There is a time and place to use IEnumerable. Taking advantage of it’s laziness can work to your benefit and when you know for sure that your list will not be enumerated more than once, it’s a pretty solid option.

On the flip side, not knowing the implementation of IEnumerable could prove dangerous to anyone using it. Let’s say for example that you used a Where and Select where the Select statement actually takes a considerably long time or uses a lot of resources. Depending on your usage, you could very easily double (or worse) the time it takes for your operations to complete since the IEnumerable implementation is re-running that LINQ query.

What should I do when my method takes in an IEnumerable parameter?

If you know for a fact that you are only going to iterate through the list once, then using the IEnumerable as-is is perfectly fine. When you should be concerned is when you are going to be accessing the list multiple times or passing it into other functions where you are not sure what actions will be made. creating an IList or array using .ToList() on your IEnumerable will guarantee that your list will only be enumerated at most once.