One of the key aspects of our development policy is to minimize the size of our components, and this also concerns the number of files a component’s functionality is implemented in. iGrid.NET of the versions 1.x-2.x was compiled into a single DLL, TenTec.Windows.iGridLib.iGrid.dll, but the situation changed after the release of .NET Framework 4.0. Microsoft started to use so called client profiles widely in this release of .NET, and to conform to this ideology, we needed to dissect the only iGrid.NET DLL and implement all the design-time functionality in a separate DLL. As a result, now iGrid is implemented in two DLLs. For instance, for the version 4.0 these are TenTec.Windows.iGridLib.iGrid.v4.0.dll and TenTec.Windows.iGridLib.iGrid.Design.v4.0.dll (version numbers in the DLL names is completely another question).

This means that now it is not enough just to copy the core iGrid.NET DLL to another pc if you need to use the control for development in the VS IDE - you also need to copy the design-time DLL. But there are two important things you should take into account to make it work. If you miss them, you will see the iGrid.NET icon in the designer’s area at the bottom like on the attached screenshot - as if it were a non-visual component like Timer, though there should be no icon for iGrid in that area at all. In addition, all the deign-time features (control verbs, visual column editor, etc.) will be inaccessible. Some customers also reported this issue when the designer does not "remember" iGrid.NET's property changes after compiling the project or reopening the form. If you encounter strange things like the listed above, check the following points.

First, iGrid.NET's design-time DLL should be placed into a separate folder - not in the same folder where the core DLL is placed. We do not know why, but our experience shows that VS has some glitches if both DLLs are in the same folder. Generally our demo installer places TenTec.Windows.iGridLib.iGrid.Design.vN.M.dll into the DesignTime subfolder in the folder all core DLLs are placed in.

Second, to "help" the WindowsForms Designer to find the design-time DLL, we also need a special key in the Windows registry that contains the path to the folder with the iGrid.NET design-time DLL. Below is an example of a .reg file you can use to create the corresponding registry key.

For 32-bit versions of Windows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\10Tec iGrid 3.0 Design DLL]
@="C:\\Program Files (x86)\\10Tec\\Windows Forms .NET\\iGrid.NET 3.0\\Bin\\DesignTime\\"

For 64-bit versions of Windows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\10Tec iGrid 3.0 Design DLL]
@="C:\\Program Files (x86)\\10Tec\\Windows Forms .NET\\iGrid.NET 3.0\\Bin\\DesignTime\\"

You can create such a file in any text editor like Notepad and then double-click it to import the contents into the registry automatically. Two notes about the file contents:

1) Correct the path after the "@" character depending on your folder structure. Use double back slashes as folder separators.

2) The green italic text is the name of the child key under the AssemblyFoldersEx registry key, but it can be anything you like. For instance, you can use the iGrid version number in it to indicate the iGrid version this key belongs to. The only requirement is to use different key names for different versions of iGrid.

When you deploy iGrid.NET using the demo installation, this registration is performed automatically. If you redistribute the control by yourself, you need to do that manually. And remember that this concerns only the visual form development in the IDE - end-user app executables need only the main DLL (TenTec.Windows.iGridLib.iGrid.vN.M.dll).

Another way to enable all design-time features of iGrid without any registry tricks is to copy the iGrid design-time DLL (TenTec.Windows.iGridLib.iGrid.Design.vX.XX.dll) into the PrivateAssemblies folder of the Visual Studio IDE.

This folder is mainly used to store assemblies that should run only inside the IDE. The location of the PrivateAssemblies folder depends on the version of VS and whether the OS is 32- or 64-bit. Below you will find typical locations for the PrivateAssemblies folder for the latest releases of VS.

32-bit Windows:

VS 2010: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\
VS 2012: C:\Program Files\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\
VS 2013: C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies\
VS 2015: C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\
VS 2017: C:\Program Files\Microsoft Visual Studio\2017\<edition>\Common7\IDE\PrivateAssemblies\
VS 2019: C:\Program Files\Microsoft Visual Studio\2019\<edition>\Common7\IDE\PrivateAssemblies\

64-bit Windows:

VS 2010: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\
VS 2012: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\
VS 2013: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PrivateAssemblies\
VS 2015: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies\
VS 2017: C:\Program Files (x86)\Microsoft Visual Studio\2017\<edition>\Common7\IDE\PrivateAssemblies\
VS 2019: C:\Program Files (x86)\Microsoft Visual Studio\2019\<edition>\Common7\IDE\PrivateAssemblies\
VS 2022: C:\Program Files\Microsoft Visual Studio\2022\<edition>\Common7\IDE\PrivateAssemblies\

<edition> for VS 2017/2019/2022: Community, Professional or Enterprise.

Pay also attention to the fact that VS 2022 is available as a 64-bit executable only.

Dear Igor, I have a similar problem now that I created a second VS project.
With the first project everything is fine, but on the second, even if I add the reference of the Igrid , it shows icon in tools but i cannot select it and if I import a form from the other project with grids in form, the grids get canceled.

The solution based on the PrivateAssemblies folder works only for the projects targeting .NET Framework (2.0-4.8). Unfortunately, Microsoft has not implemented yet full support for third-party controls in WinForms projects for .NET Core 3.x, .NET 5 and .NET 6 in VS 2017-2022. At least, at the time of writing of this post.