Has been occurring for a while now from version 12+; currently trying to use v13.2.20132.2098. It just cost me another 4 hours’ work today, so I've come here.
I'll be going along doing my work in VsiualStudio 2012, and things will be fine, but then suddenly this error will crop up when trying to open the designer for a form containing Infragistics controls:
Key already exists Parameter name: Key Instances of this error (1) Call Stack : at Infragistics.Shared.KeyedSubObjectsCollectionBase.ValidateKeyDoesNotExist(String key, IKeyedSubObject ignoreObject)at Infragistics.Shared.KeyedSubObjectsCollectionBase.ValidateKey(String key, IKeyedSubObject ignoreObject)at Infragistics.Shared.KeyedSubObjectsCollectionBase.InternalAdd(IKeyedSubObject obj)at Infragistics.Win.UltraWinGrid.ColumnsCollection.InternalAdd(UltraGridColumn column)at Infragistics.Win.UltraWinGrid.ColumnsCollection.Add(Object obj)at Infragistics.Win.UltraWinGrid.ColumnsCollection.AddRange(Object[] columns)
What I believe is happening is that every time I go to debug the app, the Windows Form Designer code for all the Infragistics controls gets re-generated. I can see differences between two successive iterations of the designer file; appearance instances get renumbered, grid column instances get renumbered, band instances get renumbered, etc. If I happen to have the designer form open when I start the debug, then the odds of this regenerated code getting out of alignment are raised greatly, but it is by no means a sure thing that having the designer closed when debugging will keep the problem from happening. When it gets out of alignment, this error is presented, with nothing to do but hope I made a recent backup before the debug, or wading through 1000's of lines of designer-generated code looking for duplicates.
So, anyone else experiencing this? Is it an aspect of Visual Studio, or Infragistics, that this designer code re-generation even occurs? Anyone have a solution?
Hi,
So I took a look at the files you sent us. The file itself is already corrupt, so it's difficult to tell how that happened from the file contents, but I noticed one thing that is a very strong candidate. I noticed that your form is derived from a base form.
Visual inheritance in DotNet does not work well with collection properties. There are all sorts of problems that occur when you have a control that exposes a collection and then inherit from that form. You can demonstrate these sorts of issues with any control that exposes a collection - for example, the inbox TreeView control. If you were to put a TreeView on a form and add some nodes, then derive from that form and modify the tree nodes collection in any way (modifying, removing, or adding nodes), you would very shortly run into issues where nodes duplicate themselves or disappear.
So I can't be sure, but I strongly suspect that's what's happening here. You probably have a grid on the base form bound to to a data source and it's somehow getting modified and therefore corrupted on the derived form.
The only solution in that case is not to add anything to the collection at design-time. So that would mean binding your grid to the DataSource only at run-time and not int he designer.
OK, have another occurrence of this. I do have some proprietary info in the designer files, though, and would rather not contaminate the evidence by redacting them. I have created a support ticket to upload the files, and referenced this thread. CAS-150742-C3T0P6
Thanks
My apologies, I lost track of the thread and forgot you were getting the exception at design-time. Unless your data source exists on a another thread at design-time and is bound to the grid at design-time, it's probably not a threading issue.
So... once this exception occurs, you said you have to restore from a backup. So presumably the form is corrupt at that point and it will reproduce the same exception every time you try to open it. Is that right?
If so, then it might help us to look at the form designer code before and after. So the next time this happens, maybe you could send us the form.cs and form.designer.cs files from before and after the error so we can compare. We might be able to figure out what happened by comparing the two.
Of course, I understand that getting the "before" version might be tricky - depending on how often you back it up. Also, if there is proprietary information on the form or if it relies on other classes in your project, it might not be possible. But that's the best approach I can think of to determine the cause of the error.
I'd tend to agree, except it's not truly a run-time issue. As indicated in the original post and indicated in my other responses, the error occurs in the designer. I try to open the form in the designer and the error appears. Perhaps VS has the threading issue, where it is restating the contents of the form on one thread and managing the infragistics licenses or resources on another. Since I never experience the problem with plain vanilla form objects, I considered the IG controls as being involved in the cause. I like to use them a lot, though, so was interested in getting a solution to this issue.
At this point I have a workaround (pre-build event that backs up the forms) that limits my lost work, and can't afford any more time to investigate root cause.
I don't see any connection between a run-time exception about duplicate keys and a design-time issue with the form being dirtied. I could be wrong, but those seem like two completely separate issues to me.
If you are using threading in your application, then that would be my absolutely #1 suspect for the cause of the run-time Exception. It is virtually impossible to safely use threading and DataBinding together. When you use threads, you have to be in control of the communication between the threads. And if your thread so much as looks at anything on the UI thread, like the grid's DataSource or the BindingManager, or (of course) the grid itself, then it will cause a problem, because you are not in control of the communication between any of those objects. What you are describing here has all the hallmarks of a threading issue - a seemingly impossible exception related to duplicate keys that occurs seemingly at random an is impossible to debug or duplicate reliably. That practically screams threading problem.