I recently started to see some very strange behavior when I try to add an UltraGrid control to an existing UserControl derived class.
Whenever I drag the UltraGrid from the toolbox and drop it on the control, VS will grind away for several seconds and then display it at the bottom of the designer window. It is not rendered on top of the UserControl. The UltraGrid did not end up a child of the UserControl class. When I tried to drag the UltraGrid control in the Document Outline window to make it a child, VS would crash.
So I asked a coworker to add the UltraGrid for me, which he was able to do without any problem. When I open it in the VS designer, the UltraGrid is a child of the UserControl, but it is still shown a the bottom of the window. I cannot launch the custom property editor for the UltraGrid.
I can add UltraGrids to a trivial test project.
We recently upgraded our projects from NetAdvantage 8.1 to 8.2. I uninstalled 8.1 shortly before this problem started. Since then, I reinstalled 8.1 but that did not help. The UltraCombo also shows this same problem.
I am using VS 2008.
Any ideas?
Larry
The design-time assembly is located in the GAC, as well as the installation directory of the toolset. It's name replaces ".dll" with ".Design.dll"; so for the file named "Infragistics2.Win.UltraWinGrid.v8.2.dll", the corresponding file for the design-time assembly is "Infragistics2.Win.UltraWinGrid.v8.2.Design.dll".
So long as you don't have a CopyLocal true reference to the runtime assembly, you'd never need to think about where the design-time assembly is located, nor would you need to add a reference to it.
If you're still seeing the WinGrid in the component tray even after setting the CopyLocal property of the reference to false and removing it from your output directory, then I'm not certain what's exactly happening. I'm just as puzzled as to why other developers can view the same project just fine.
One scenario that comes to mind is if your solution has multiple projects, and perhaps another project (one that's a prerequisite project for the one containing your Form) contains a CopyLocal true reference to the same assembly. This will, if I remember correctly, end up copying the assembly to the bin of your project again, even though the project containing your Form uses a CopyLocal false reference to the assembly. However, I would expect this to affect other developers as well, not just you.
Do you still have the installation file for Visual Studio? If so, you might want to re-run it to repair your installation. At best, it will fix the problem; at worst, it'll rule out a possible cause.
Vince,
Thanks for the suggestion.
I looked and we do have Copy Local set to true. It has been true for months and across multiple versions of NetAdvantage.
After I set it to false and removed the UltraWinGrid assembly from my output directory I still get the WinGrid in the component tray. That is true even after a rebuild and a restart of VS.
I am confused by your mention of a design-time assembly. I only see one version of the UltraWinGrid assembly. There are 2 instances of it. One where the Reference copies it from and one where it copies it to. Where does the UltraWinGrid design-time assembly come from?
Also, other developers on my team can see the custom designer using the same project with Copy Local set to true.
Is there anything else I can check.
Thanks.
Check the reference to the Infragistics.Win.UltraWinGrid.v8.2 assembly (or the corresponding assembly in another version). If the CopyLocal property of this reference is set to true, set it to false.
If this is the cause of your problem, then what's happening is that Visual Studio can't find the design-time assembly for WinGrid. This is because you have a copy of the runtime assembly in the bin of your application (thanks to the CopyLocal = true setting), and the design-time assembly isn't there with it. This confuses Visual Studio, and you end up with your WinGrid in the component tray, and it loses much of its design-time functionality (or, as you've seen, can sometimes crash).
There may be other things that would cause the WinGrid assembly to be in the bin of your project, which will cause the same problem. I can't advise how to address those situations withiout knowing more, but regardless of why it's in the bin directory, you'll need to get it out.