Targeting .Net Client Profile

Jan 12, 2012 at 3:27 PM

We're considering modifying the codebase so that we can target the .Net Client Profile.

There are several reasons that we want to do this such as

  • Providing a better experience for developers (the default project type targets the .Net Client Profile)
  • Allowing a non-admin installation (as the .Net Client Profile is already installed on most Windows systems)

Presently we target the full .Net Framework so that we can use design attributes etc. (I'm investigating what, but haven't come across anything that can't be overcome.)

Are there any thoughts on

  1. How to remove our dependency on System.Design without losing functionality. (Know of a replacement for FileNameEditor Class?)
  2. Whether we should support extensions that target the Full profile, and how me might do this.
Jan 12, 2012 at 3:40 PM

1. Note that I would like to avoid using preprocessor directives.

2. As an example see DotSpatial.Plugins.ScriptRunner.CSharpCodeCompletion which references ICSharpCode.SharpDevelop.Dom which references System.Web in the Full profile. 

Jan 13, 2012 at 8:10 AM

I'm working on a new version of WebControls that works without System.Windows.Form.

I was finding the library System.WEB is available olnly in .NET Framework, but library compiled with Client Profile can be used in .NET Framework.

May be the better way is keep a prject DotSpatialWeb in wich all project are targeting Client Profile except DotSpatial.WebControls that target on .Net Framework ?

Jan 13, 2012 at 6:10 PM

Thanks for your input. I think we will target the .Net Client Profile for all of the core classes. We'll expect that the full .Net Framework is installed on servers and developer machines.

A drawback is that (see 2) an extension that requires the Full profile will probably seem buggy on the Client profile. I'd expect errors along the line of "couldn't find assembly System.Web ..." 

Jan 13, 2012 at 9:59 PM

First time I was reading too fast so I did not read at all the point 2.