In my work I stumbled on a problem when it comes to the path that isprobed for private assemblies. Normally for developed applicationsthere is not much need to have a deeper directory structure forassemblies. However, this solution has certain assemblies in a plug-instructure. And instead of a flat long list of assemblies that are closeto impossible to handle, a sub structure is preferred. The followingapproaches was what I went trough.The first approach is to make sure that the namespace in the assemblymatches the directory structure. This will work but this solution isnot flexible enough. It will probably break the first time someonerenames a namespace and forgets to update the deployment directory.Second approach is to edit the app.config file, sure is quite easy to do. The only thing needed to add is the following snippet:  <runtime><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><probing privatePath="fwk"/><probing privatePath="tools"/></assemblyBinding></runtime>But this approach does not give more flexibility than the previous.What's worse is that if incorrect information is entered in app.configit may break it for other plug-ins as well.The third solution solved my problem. In this solution the path isadded dynamically to the AppDomain at runtime. By using theAppendPrivatPath method:System.AppDomain.CurrentDomain.AppendPrivatePath("fwk")System.AppDomain.CurrentDomain.AppendPrivatePath("tools")Or if you like:System.AppDomain.CurrentDomain.AppendPrivatePath("fwk;tools")