Tool question, I can't find any after some googling. But are there any tools out there for dotnet that help you find class, method, and property references outside a solution.

Say I have a bunch of solutions and I need to know where a class is referenced to determine whether or not I can deprecate it. Is there anything out there that would scan other solutions for references to that class?

Usually you don't worry about upstream. Keep backwards compatibility and increase your lib version. Mark code paths that are about to be deleted as deprecated.
In 3-6 months feel free to delete the code paths.

If you use a central repository, you can always scan project files for references, and then scan the projects for exact references.

Either way due to how business works, you usually shouldn't need that.

@HitWRight depending on how frequently I update code in our repos, sometimes six months isn't enough unfortunately.

Is that how a majority of businesses work? Mark as deprecated and then wait for compile errors once deleted? Seems like it would be useful to know where methods are called.

Is this for finding things to copy or ...

I usually break out things I know I will reuse to a nuget and use that.

Visual Studio have dome solution to find nugets with a public class. But I must confess that I have never used it for any personal ones, I usually remember where I have any code I need

(yes even after about 30 years in the trade I still have a hum of where things are)

@Voxera Mainly to find classes, methods, or properties to deprecate so I don't have to keep maintaining such a large codebase.

Right now I have stuff moved into nuget packages and wrote a program to find references to each nuget package and each version of that so I can find my references. But I want to granularize it. If I don't have to write the code for finding methods and properties and classes within those projects then it'd be nice. But I unfortunately haven't been able to find any programs that'll find those specific references.

@vomitmachine that's how it works where I had worked/am working.

Never actually had to worry too much about it. Since bumping the version was more than enough by itself. The wait time was more for web services part.

Now that you mentioned it, it would be interesting to look at how the code it self is used more often. Maybe optimize for hot paths...

@HitWRight looking at it for most used paths would be pretty useful. I didn't think of that case

If you mark it as deprecated it will (by default) throw warnings, not errors, so people will still be able to use it, but get a warning that it's going to be removed in the future.
You'd usually mark it deprecated and then after a while mark it as obsolete (which throws errors) or completely remove it.

Of course, most devs ignore warnings, but that's their issue, not yours :)
VS will put squiggly lines under deprecated methods/properties though so it's more likely to be notices than your ordinary warning, but still not a guarantee since if it's not being used in new stuff and no one is opening the stuff where it's used again noone will see it.

Other than that, I don't know of any tools for what you're asking, but that's likely because typically your libraries are either public and you don't have access to all the usages anyway or private and you use them in your own solution or two and you know where they're used/it's easy to do it manually.
I'd deprecate+send a company email.

@Bikonja since I'm working by myself most of the time and not touching code for long periods of time making as deprecated/obsolete may still lead to errors of I work on the code later on.