problems when porting CollectionEditor

[LukasGelke]

I'm currently in the process of porting our custom editor(s).

The situation is as follows:

• we have custom Types to manage certain Actions that can be done in our applications (that interact with BindingSources, other Forms,...)
• CommandProvider is a Component which will be placed on ViewModel-Classes (Components themself)
• CommandProvider has a Property Commands of Type CommandCollection (Inherits from Collection<IKomsaCommand>)
• CommandCollection has an DesignreAttribute
• There are different Types of Commands
  • several Default-Commands, which take some Bindings/Properties to do pre-defined actions
  • an empty Default-Command, which is intended for simple actions (mainly its public Executing Event Handler)
  • manually defined classes which implement IKomsaCommand - these are not part of the Designer
• each Default-Command is a Component themself, which also live on the ViewModel as fields and should be "editable via designer"
• the CollectionEditor allows for the individual Commands to be editable
• from what I understand after many hours of trying and failing is that the default ComponentCodeDomSerializer should work
  • in the past we did not need a custom serializer

I've tried to inherit relevant classes (as per example: https://github.com/KlausLoeffelmann/NetControlDesigners/tree/main/src/Samples/Previous%20Versions/Sophisticated%20-%20CollectionEditor );
But also tried a "less convoluted" approach with less classes using the TileRepeater_Medium example.

I'm using the CollectionEditorViewModel.CreateInstance()/IDesignerHost.CreateComponent() mechanisms to have the needed Command-Fields in the ViewModel and DestroyInstance()/host.DestryComponent() to remove them again (hoping to leverage DesignerHostTransactions)

Currently I'm exhibiting the following problems:

• the CollectionEditor has no way to edit Events (the same way the PropertyBrowser in VisualStudio can)
  • also ComponentProxy seems to have no way to interact with Events of the object
• Fields of removed Commands are still present in the *.Designer.cs
• Added Commands may be added as a field, and initialized, but are not added to the CommandCollection
• Sophisticated: adding a new Command, also removes the first Command from the Collection (but leaves it in the *.Designer.cs) (new Command also not Added to Collection)
• Sophisticated: just removing a Command in the Editor does not do anything

The entire architecture of the new model (producing and consuming a NuGet Package withing the same solution) makes it hard and slow to iterate and debug. Also I'm now unsure which problems occur in which implementation due to swapping halfway through.
We don't have a single lightweight "controls only" project and due to dependencies cannot extract such.
There is a need to "Rebuild" the "Design.Package" Project and then the consuming project (in this case a UnitTest project).
Debugging only works with as seconds instance of Visual Studio, but having the same solution open causes sometimes problems that the debugger complains about changes the second instance makes. Thus having to unload the Test project in the first, but having to "Reload" it in the second.
Sometimes Breakpoints wont be active because of apparent discrepancies. Implying the need for an additional sln(f), just for this case.

[FreeAndNil]

@KlausLoeffelmann do you have an idea? We have exactly the same problem.

[LukasGelke]

@kirsan31
you seem to also have gad a bunch of issues with CollectionDesigners. Do you have any tips/solutions?

[kirsan31]

@LukasGelke implementing a new designer support sadly is overcomplicated :(
I can't give any exact advises but you can check how I had implement it here.

[KlausLoeffelmann]

I know that particularly Collection Editors are not exactly an easy way to port. I remember, when I had to do "mine" in the Designer...

I talked with Dustin bacj in the day really often about simplifying the process, but we always hit some issues on several attempts, and finally decided to go for this, because we needed something reasonable and stable which we could work with to make sure the WinFOrms "stock" Designer can move forward.

(And to be honest, I will always admire in awe Dustin's speed of having genius ideas and how quickly he knows how to compromise best between stability, usability and getting things done in a time we need, so no one is blocked, just as an FYI.)

And the whole list of pain-points then @LukasGelke listed...yep. I remember all of those all too well... (Lukas, glaub mir, ich hatte keine angenehmen Traeume in dem Bisschen was ich an Schlaf hatte der Zeit... :-S) But the attachtment in a second instance is btw how we rewrote the whole Designer, albeit with a somewhat more automated process: When we Start our solution, it get's a second instance fired-up automatically and get the Server-Process also attached once it is available. That helped the process a lot, but still, booting this whole thing up, yes, takes a while.

The one thing I also remember I did was a few optimization things in building the respective Control-Designer-NuGets to get them more reliably deployed, because my biggest problem which always drove me up the wall was, that I super-often built against a generated fresh NuGet, which did not pick correctly, so I was testing against the same old thing.

We are floating ideas currently, if some special Copilot migration-guidance-techniques I could set up would at least help in getting sound templates started. but that is also something I can't pull out of my magician's hat, and while AI is promising a better or more assisted way in the mid-term future, the same topic also holds me current hostage with some high-high-priority tasks around AI and Copilot, I need to address first in the upcoming weeks.

Let me think of what I can do here on short notice.
I will take some time over the weekend, to at least think about it.

Final question to @LukasGelke: Do you have any visual (like gif) samples of such a collection editor, which you can disclose? You can also ping via my Microsoft email, firstname dot lastname at microsoft . com. My first name is Klaus, my last name is the German translation of spoonman. :-)

(Mit oe naürlich, nicht mit ö!)

[LukasGelke]

@KlausLoeffelmann many thanks for that detailed and (unexpectantly) fast reply. I'm also just on my way to the weekend, so I'll keep it short. But I can share these basic images/snippets publicly no problem, because it's a Test-ViewModel.
I'm not able to provide proper gifs now, but could add them Monday :)

Thats our old designer:

VS Properties Grid, the ... is the simple part

thats the actual designer

... with the Events Page

the Add button is modified, to add the different Default-Commands:
(via protected sealed override CollectionForm CreateCollectionForm())

and for the most part, i could replicate that appearance in the new designer:
(please ignore spacing/padding ofc)

I made a ISite implementation as per example so that the "complex" Editors (eg Image) work. Also Editing existing commands seems to work (through the Proxies directly, which is very awesome)

and the Designer.cs ("old version"):

namespace Komsa.Windows.Forms.Test.TestViewModels
{
  partial class CustomerViewModel
  {
    /// <summary>
    /// Required designer variable.
    /// </summary>
    private System.ComponentModel.IContainer components;

    /// <summary> 
    /// Clean up any resources being used.
    /// </summary>
    /// <param name="disposing">true if managed resources should be disposed; otherwise, false.</param>
    protected override void Dispose(bool disposing)
    {
      if (disposing && (components is not null))
      {
        components.Dispose();
      }
      base.Dispose(disposing);
    }

    #region Component Designer generated code

    /// <summary>
    /// Required method for Designer support - do not modify
    /// the contents of this method with the code editor.
    /// </summary>
    private void InitializeComponent()
    {
      this.components = new System.ComponentModel.Container();
      System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(CustomerViewModel));
      this.commandProvider = new Komsa.Windows.Forms.Commands.CommandProvider(this.components);
      this.cmdContextCommit = new Komsa.Windows.Forms.Commands.DataContextCommitCommand();
      this.cmdContextRollback = new Komsa.Windows.Forms.Commands.DataContextRollbackCommand();
      this.cmdEntityDelete = new Komsa.Windows.Forms.Commands.EntityDeleteCommand();
      this.cmdEntityEdit = new Komsa.Windows.Forms.Commands.EntityEditCommand();
      this.cmdEntityNew = new Komsa.Windows.Forms.Commands.EntityNewCommand();
      this.cmdEntityPrint = new Komsa.Windows.Forms.Commands.EntityPrintCommand();
      this.cmdEntityRefresh = new Komsa.Windows.Forms.Commands.EntityRefreshCommand();
      ((System.ComponentModel.ISupportInitialize)(this.mainBindingSource)).BeginInit();
      ((System.ComponentModel.ISupportInitialize)(this.commandProvider)).BeginInit();
      ((System.ComponentModel.ISupportInitialize)(this)).BeginInit();
      // 
      // mainBindingSource
      // 
      this.mainBindingSource.BusinessEntityType = typeof(Komsa.Windows.Forms.Test.TestBusinessEntities.Customer);
      this.mainBindingSource.DataSource = typeof(Komsa.Windows.Forms.Test.TestBusinessEntities.Customer);
      // 
      // commandProvider
      // 
      this.commandProvider.Commands.Add(this.cmdContextCommit);
      this.commandProvider.Commands.Add(this.cmdContextRollback);
      this.commandProvider.Commands.Add(this.cmdEntityDelete);
      this.commandProvider.Commands.Add(this.cmdEntityEdit);
      this.commandProvider.Commands.Add(this.cmdEntityNew);
      this.commandProvider.Commands.Add(this.cmdEntityPrint);
      this.commandProvider.Commands.Add(this.cmdEntityRefresh);
      this.commandProvider.ViewModel = this;
      // 
      // cmdContextCommit
      // 
      resources.ApplyResources(this.cmdContextCommit, "cmdContextCommit");
      // 
      // cmdContextRollback
      // 
      resources.ApplyResources(this.cmdContextRollback, "cmdContextRollback");
      // 
      // cmdEntityDelete
      // 
      this.cmdEntityDelete.BindingSource = this.mainBindingSource;
      resources.ApplyResources(this.cmdEntityDelete, "cmdEntityDelete");
      // 
      // cmdEntityEdit
      // 
      this.cmdEntityEdit.BindingSource = this.mainBindingSource;
      resources.ApplyResources(this.cmdEntityEdit, "cmdEntityEdit");
      // 
      // cmdEntityNew
      // 
      this.cmdEntityNew.BindingSource = this.mainBindingSource;
      resources.ApplyResources(this.cmdEntityNew, "cmdEntityNew");
      // 
      // cmdEntityPrint
      // 
      this.cmdEntityPrint.BindingSource = this.mainBindingSource;
      resources.ApplyResources(this.cmdEntityPrint, "cmdEntityPrint");
      // 
      // cmdEntityRefresh
      // 
      this.cmdEntityRefresh.BindingSource = this.mainBindingSource;
      resources.ApplyResources(this.cmdEntityRefresh, "cmdEntityRefresh");
      ((System.ComponentModel.ISupportInitialize)(this.mainBindingSource)).EndInit();
      ((System.ComponentModel.ISupportInitialize)(this.commandProvider)).EndInit();
      ((System.ComponentModel.ISupportInitialize)(this)).EndInit();

    }

    #endregion

    private Komsa.Windows.Forms.Commands.CommandProvider commandProvider;
    private Komsa.Windows.Forms.Commands.DataContextCommitCommand cmdContextCommit;
    private Komsa.Windows.Forms.Commands.DataContextRollbackCommand cmdContextRollback;
    private Komsa.Windows.Forms.Commands.EntityDeleteCommand cmdEntityDelete;
    private Komsa.Windows.Forms.Commands.EntityEditCommand cmdEntityEdit;
    private Komsa.Windows.Forms.Commands.EntityNewCommand cmdEntityNew;
    private Komsa.Windows.Forms.Commands.EntityPrintCommand cmdEntityPrint;
    private Komsa.Windows.Forms.Commands.EntityRefreshCommand cmdEntityRefresh;
  }
}

CommandProvider .Commands is public CommandCollection { get; } = new(this); And CommandCollection uses this to attach the Provider to the Commands during add/insert

[LukasGelke]

oh and one additional question: how do i correctly set it up, to have such "startup project" functionality?
I use the "Package Project", add devenv.exe .\MyTestSolution.slnf as StartAction etc.
I have the "Microsoft Child Process Debugging Power Tool" installed and setup, but it won't attach to the DesignToolsServer.exe no matter what Process Filter I use:

when going into VS Toolbar -> Debug -> Attach...
I still see DesignToolsServer.exe as "attachable":

Edit: it seems this must be one of those "nuget mismatch" situations, because sometimes after some changes, I can't get it to "start and debug" with any breakpoint active (not even net4/devenv). And sometimes "it just works" and attaches both processes

[LukasGelke]

@KlausLoeffelmann sorry to bother, but is there any updates on the main issue from you or your team?

[FreeAndNil]

@KlausLoeffelmann could you provide an update on this?

There has been no follow-up since mid-February 2025, and the core problems around CollectionEditor behavior, component lifetime, event editing, and Designer.cs consistency remain unresolved. Given how central CollectionEditors are for non-trivial WinForms scenarios, it is currently unclear whether:

• these issues are known limitations of the out-of-process designer,
• there is an intended or supported migration path,
• or this scenario is effectively unsupported going forward.

Even a clear statement of scope or limitations would help teams decide whether further investment in porting is realistic, or whether alternative approaches are required.

[KlausLoeffelmann]

Hey all,

I pinned an issue to the repo, where I replied to @LukasGelke (as a proxy for all of us, if you will).

The reply to that thread is what I can currently disclose, and where my ambition is to drive this "thing", to make issues better and response times quicker in the future.

I will do my best (always assuming, of course, management is not getting "tired" of me... 😸) to figure things out in terms of how AI/LLMs can support us to go forward here way quicker and, in all honesty, admittingly not as one of my highest priorities, but definitely with it in mind.

And I will follow up more frequently.

In that context:
Should you discover that Copilot works well for you in certain domain-related areas here, and you might have ideas how to integrate approaches base on those ideas more closely (e.g. MCP-Server, Skills or what have you): I am absolute open to listen to ideas, schedule calls to discuss ideas, exchange experiences - you name it.

@mcastro-x FYI.