I am planning to refactor the code in the future. As a temporary solution I am planning to convert all the classes into a single class library. Is this a bad idea and if so, is there an alternative? as I don't have time to refactor at the moment.
It's definitely a good idea. Actually, this is already a type of refactoring that you're doing, it just happens to be a pretty easy one to do (copy files over / change namespaces). You mention that you want to share some of the functionality with another app - if the other app is not an ASP.Net app, I would be more careful about this; it's possible that the classes assume that they're being run in that environment (use Request / Session, etc).
I realise it would be better to only share the classes which contain code to be shared but because of the dependencies this is proving to be very difficult...
Of all the problems that you have, worrying about sharing too many classes is one of the smallest. In the comments, you alluded to worrying about the DLL getting too big - I don't know what your project's size is (and what your performance requirements are), but this is generally not a major issue. It requires a fair bit of code to produce a large DLL, so if we're talking about anything under 100 KLOC, you shouldn't worry.
When your DLL is loaded by IIS, it will not take up significantly more memory than it's original size; most of the DLL consists of machine instructions. When your code creates an instance of a class, the data (fields, etc) in that class take up new memory, but the code (methods, etc) are not copied for each class. Having lots of methods in your classes will therefore only increase the memory footprint once globally, not once for each object you create. This is why I say that the DLL won't cause a big issue - if you manage to create a 10MB DLL (which is pretty big), it will take up about the same amount of RAM when it's loaded. This is typically not worth worrying about - your bottlenecks are with the data created with each object.
I mentioned JIT / app startup specifically because this is one area where having large DLLs will affect performance. If you've deployed the app correctly (release mode, etc), re-JIT-ing is not typically supposed to happen, however. Depending on your performance requirements, this may or may not be acceptable. Again, however, this is typically not a huge issue, compared to other areas where performance issues typically lie.
To wrap up, I've added the above for your info, specifically because you asked for it; as I mentioned in the comments, the size of the DLL is really not a huge worry unless we're talking about a project in the millions of lines of code range. Refactoring an old code base with many god objects is enough of a challenge without worrying about this.