setup in vb.net dll and exe are in seprate folder

If the reason for using separate directories for deployed product is having multiple DLLs, this is not very productive approach. Having it all in the same directory is usually the optimal approach.

However, there can be more advanced scheme. Imagine that you deploy some products optionally. You may want different products to go to different directories, but those products use the same common framework, which is also your product you supply with the application that the user installs first.

In this case, I can see two different approaches.

First of all, you can put all your libraries used by different products to the GAC. All your assemblies should be strongly named, but I would advise you a simple rule: always sign everything you ever deploy. Please see:

http://en.wikipedia.org/wiki/Global_Assembly_Cache[^],
http://en.wikipedia.org/wiki/Strong_key[^],

http://msdn.microsoft.com/en-us/library/yf1d93sz.aspx[^],
http://msdn.microsoft.com/en-us/library/ex0ss12c%28v=vs.100%29.aspx[^]
http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx[^].

These CodeProject articles could also be useful:
Building Security Awareness in .NET Assemblies : Part 3 - Learn to break Strong Name .NET Assemblies[^],
Strong Names Explained[^].

Now, about the alternative approach:

If by some reason you don't want to mess with GAC (but again, give your assemblies string names anyway, signing is too easy to doubt), you can use alternative technique based on application configuration files.

If your main executable module of your entry assembly is named, say, "My.Application.exe", the configuration file name would be "My.Application.exe.config". It might look like this:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="..\My.Libraries\Assemblies"/>
        </assemblyBinding>
    </runtime>
</configuration>

This way, you can indicate the common relative path (relative to the location of the main executable module of each entry assembly) different for different applications but pointing to the same commonly used path used for location of your framework library assemblies. You could also use absolute path, but I usually recommend relative paths for better flexibility and the ease of transfer between different systems.

—SA