1. 10Tec Forum
  2. iGrid.NET
  3. WinForms Grid Polls
  4. Support of .NET Framework client profiles in iGrid.NET
  Poll Question : Do we need to support .NET Framework client profiles in the future builds of iGrid.NET?  (Poll is closed)

Total: 9

The poll has expired.
Igor/10Tec
2014-03-14T14:13:30Z
As you may know, Microsoft provided .NET Framework 3.5 and 4.0 with so called client profiles optimized for client applications. With the release of iGrid.NET 3.0 we split its only DLL into two DLLs (the core functionality and the design-time functionality) to enable the usage of iGrid with the .NET client profiles.

However, starting with the .NET Framework 4.5 the .NET Framework client profiles have been discontinued. So the question is whether we need to support these outdated client profiles in the future builds of iGrid.NET?

Note that the two-assembly iGrid implementation causes extra problems for the developers when installing/deploying the component (see this forum topic  for more details). Putting all the functionality back into one DLL would also help all of us to avoid these deployment problems.
Martin Sutherland
2014-03-18T14:15:36Z
The split between client and full framework was to satisfy the security concerns of big corporates. Framework 4 client profile is almost always already installed on users PCs and thus easier to target this. Corporates may not allow installation of newer framework!
BlackForestIT
2014-03-25T16:55:11Z
Perhaps this are two questions.
1. Continue support of the client profile.

As long as you target .NET 4.0 I would prefer the support of the client profile.

2. Using different assemblies for design and runtime.

One big point why we are using iGrid is it's small runtime footprint.
Similar Topics
Users browsing this topic
    1. 10Tec Forum
    2. iGrid.NET
    3. WinForms Grid Polls
    4. Support of .NET Framework client profiles in iGrid.NET