It is most likely a dependency, but Visual Studio should attempt to add them into your setup project, at least those it can detect from the assembly manifest info. VS won't detect COM dependencies because there's nothing that says which Dll you will link to at run time. Also, if you have an assembly being installed into the GAC and your Dll is dependent on it, then this will also cause the failure - assemblies aren't in the GAC until the Commit phase, so a Commit custom action sometimes works.
The other issue is that your assembly is not being loaded in the typical way. It's being instantiated with reflection, and then tries to locate installer classes (hence the message) and this bypasses any redirection and so on.
There might also be an architecture mismatch. If your Dll is AnyCpu and it runs in 64-bit mode then any 32-bit dependent assemblies won't load.
The Fusion Log Viewer can be useful identifying the missing dependency.
If this Dll has forms and controls you're going to show during the install, this is generally not the right thing to do. You'll never be able to do a silent install, the forms/controls often don't work properly (you're not running in the right environment for a Windows UI message loop). Also, Windows security may prevent it showing because your custom action will (probably) run with the system account and show UI, which is the same reason interact-with-desktop services were deprecated. So if you're doing some configuration just do it from a normal user app the first time the app runs.
