Hmm seems someone has had the same issue with the same package, but received no replies: System.IO.FileLoadException While loading ProrubimGridsRenumbering
I would first look to see if you have two versions of Dynamo installed based on the solution of this thread here: How to fix Dynamo Notifications about System.IO.FileLoadException? - #2 by Kulkul
If the potential solution I provided doesn’t solve the System.IO.FileLoadException errors, and you really want to keep the DynoBrowser package, maybe you could utilize this code from @Andreas_Dieckmann to find out which nodes within DynoBrowser are dependent on Prorubim Nodes: Package dependency - #2 by Andreas_Dieckmann and from there you could either edit the .dyfs to replace the Prorubim nodes with a different workflow that achieves the same thing, or delete those .dyfs from the DynoBrowser package folder itself.
Maybe someone has a more direct solution than these 
As for this comment, I only have found this a cause for slight irritation when a package has a dependency for something i already have installed, and then have to go through uninstalling the package, restarting Revit, then installing the package first, then reinstalling the dependent package 
I haven’t found it problematic or cause for issue in any case. It just means that within the custom nodes, there are custom nodes from other packages within them. This shouldn’t be a cause of distress - it just means the package creater felt they didn’t need to reproduce a workflow that already existed efficiently (just my opinion).