Question: I'm refactoring a class and adding a new dependency to it. The class is currently taking its existing dependencies in the constructor. So for consistency, I add the parameter to the constructor.  

Of course, there are a few subclasses plus even more for unit tests, so now I am playing the game of going around altering all the constructors to match, and it's taking ages.  

It makes me think that using properties with setters is a better way of getting dependencies. I don't think injected dependencies should be part of the interface to constructing an instance of a class. You add a dependency and now all your users (subclasses and anyone instantiating you directly) suddenly know about it. That feels like a break of encapsulation.

This doesn't seem to be the pattern with the existing code here, so I am looking to find out what the general consensus is, pros and cons of constructors versus properties. Is using property setters better?

Answer: 
If you have large number of optional dependencies (which is already a smell) then probably setter injection is the way to go. Constructor injection better reveals your dependencies though.
I perfer constructor injection, because this seems most logical. Its like saying my class **requires** these dependencies to do its job. If its an optional dependency then properties seem reasonable.

I also use property injection for setting things that the container does not have a references to such as an ASP.NET View on a presenter created using the container.

I dont think it breaks encapsulation. The inner workings should remain internal and the dependencies deal with a different concern.