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
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.
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.
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.
I've just found out that some of the information I've provided on design assemblies is a bit dated. We removed some (though not all) of these separate design-time assemblies some time ago. For WinGrid in particular, its separate design-time assembly was removed back in 2007 Volume 1.
So, while what I've written would still be applicable to the general scenario when there's a design-time assembly invvolved, that's probably not the cause of your particular situation.
Hi,
If it helps, I've just gone through some pain with this:
I had this same issue in VS 2010. Checked all the suggestions here with no joy.
'Repaired' VS2010. No joy (half a day gone)
Installed VS 2012 . (another half day). Still no joy.
Noticed that in the last response, there was mention of putting the *Design dlls into the same folder as the main folder. In my installation (Infragistics35 v10.3) I saw that there was a subdirectory "Design". ( C:\Program Files (x86)\Infragistics\NetAdvantage 2010.3\ASP.NET\CLR3.5\Bin\Design).
I copied all these dlls to the parent
It all worked.
Can't say I'm too happy with Infragistics with regard to what appears to be a fundamental referencing error... something in the registry???
Thanks for the forum support.
regards,Duncan.
Had the same problem with NetAdvantage 11.2 and VS 2010.
None of the above sugestions helped at all.
So from another Development computer; I copied the Infragistics2.Win.v11.2.Design.dll and Infragistics2.Win.v11.2.Design.xml files into the C:\Program Files\Infragistics\NetAdvantage 2011.2\Windows Forms\CLR2.0\Bin folder on the computer that was exhibiting the problem.
And that solved the problem.
Thanks for posting what you've found, as this may help someone else encountering a similar situation in the future.
OK, I found it.
I forgot to install the Infragistics patch we are building with. My installed assemblies were not the same version as what was in the third party folder. So that accounts for the 2 conflicting versions.
I turned off CopyLocal and also removed the Infragistics assemblies from the build's output folder. But I still see the same behavior. So perhaps it is more than bad luck tripping me up.
We do have a folder under our source tree for third party libraries. There are copies of the Infragistics assemblies in that folder. When we add a reference to an Infragistics assembly, we use the version in the third party folder. The Infragistics designer assemblies are not in that folder.
When I used ProcMon, a process monitor tool from SysInternals, I found that adding an UltraGrid causes a large number of accesses to both the Infragistics install folder and to our third party folder.
Is that the double loading you are talking about?