I am thinking about going into .net framework client profile, but currently I am depending on System.Design.dll, which is not inside the profile.
I can, of course, manually distribute them in my application folder directory, but is there a better strategy?
I don't think you are legally permitted to distribute individual .NET Framework DLLs. If you depend on a DLL that's not part of the client profile, either get rid of the dependency somehow or don't target the client profile; consider requiring the full .NET Framework.
You have two options:
See also this blog post and comment:
The problem with manually distributting your local System.Design.dll is that if that dll gets patched in the framework later on, your app will keep using an older version of the dll. Of course you can put code in your program to load dynamically the local DLL only if the full framework is not present.. but that becomes more involved.
What about making two versions of the app.. one not dependent on System.Design.dll (and only requiring the client profile) and one dependent on System.Design.dll that requires the full framework.. and let the user choose the trade off?
Lets start with the fact that you cannot legally redistribute a single .Net DLL with your application.
Next lets make sure you understand the purpose of the Client Profile; and it is to provide a smaller footprint for distribution and/or a faster deployment experience for you users. It does this by providing a streamlined subset of Windows Presentation Foundation (WPF), Windows Forms, Windows Communication Foundation (WCF), and ClickOnce features.
Based on this you need to decided if the Client Profile meets your goals for your application.
If it does, you will need to refactor your project to not be dependent on any libraries that are not part of that profile.
If it does not then you really shouldn't be using the Client Profile.
As I see it you only have those two options.