Designer SDK Blog post #6

KlausLoeffelmann · 2022-04-22T20:07:40Z

Work on this repo's ReadMe, which will ultimately become the .NET Blog Post for the Designer SDK.
We will also add this sample project to the .NET Samples repo.

kirsan31 · 2022-11-12T06:56:53Z

@KlausLoeffelmann
Wow just noticed this PR. It sheds more light on the problem but questions still remain...

And yes, that’s a change from the previous .NET Framework-only Control Designers, and it involves indeed some refactoring of the design time code, but only if there is an actual UI which needs to be shown on top of the UI that is presented in the context of your actual control.

Very confusing sentence - this is not the only case when you will need much work to do :(

If you have type editors which are derived from existing type editors (like ColorEditor or FileNameEditor) for editing certain types of values for existing controls in .NET Framework, then you also need the client/server approach. That said, your control designer solution most probably doesn't need to have extra communication code to exchange data between the server and the client process. As long as you do not change the type the original editor is handling, the Designer should be able to handle the necessary communication behind the covers. But: That communication is still required to happen, and the modified (inherited) editor types still need to be run in the context of Visual Studio - which at this time is either the 32-Bit Framework process (VS 2019) or the 64-bit Framework process (VS 2022).

What will be the solution structure in this case? I mean it in terms of #9 - we need other more light template for this?

About editors...
Main problem - I think 99% of editors have some classes reference from our control. And how we can use them in .net472 project (our control is .Net6+)? And this is not single property value that's we transferring with help of Protocol project. This is
lots of references to control's classes...

ColorEditor and FileNameEditor are from System.Windows.Forms.Design namespace that simple unavailable when using Microsoft.WinForms.Designer.SDK. Ok got it - we need to put them in .net framework. What about System.Drawing.Design.UITypeEditor (it's available)? The same technique?

What about System.ComponentModel.Design.CollectionEditor? The same procedure or we need to replace it with Microsoft.DotNet.DesignTools.Editors.CollectionEditor (even though I know it won't work)? Or something different?

We defiantly need an examples for these cases too.

KlausLoeffelmann · 2022-11-12T18:10:48Z

I think 99% of editors have some classes reference from our control. And how we can use them in .net472 project (our control is .Net6+)? And this is not single property value that's we transferring with help of Protocol project. This is
lots of references to control's classes...

That's exactly the problem the SDK solves. It's what the whole effort is all about!

You have to - simplified - remote control the 4.7.2 UI from the .NET process.

If you take a look at the template demo, it also isn't able to access the property directly which the Type Editor for. That's why we 're sending requests to change the value to server, which then does it.

KlausLoeffelmann · 2022-11-12T18:14:22Z

The same procedure or we need to replace it with Microsoft.DotNet.DesignTools.Editors.CollectionEditor (even though I know it won't work)? Or something different?

We need to make it work. We did it with every single collection editor in the WinForms runtime. Those are all part of the Out-Of-Proc Designer now. And yes, that's an additional effort, since you would need to define endpoints in the server for Add, Remove, Edit, and OK.

That will be part of an additional Blog Post next year. But there is a sample for that as well already. It's named Sophisticated Demo in the repo.

kirsan31 · 2022-11-12T18:23:33Z

So, If I understand you correctly, then this statement is not true:

If you have type editors which are derived from existing type editors (like ColorEditor or FileNameEditor) for editing certain types of values for existing controls in .NET Framework, then you also need the client/server approach. That said, your control designer solution most probably doesn't need to have extra communication code to exchange data between the server and the client process. As long as you do not change the type the original editor is handling, the Designer should be able to handle the necessary communication behind the covers. But: That communication is still required to happen, and the modified (inherited) editor types still need to be run in the context of Visual Studio - which at this time is either the 32-Bit Framework process (VS 2019) or the 64-bit Framework process (VS 2022).

and in this scenario, if we have any reference to original control, we still need to do client/server communication manually?
P.s. I want to make at least one editor to work, and then will look towards CollectionEditor...
......
Still can't understand it :(
This is the simplest editor:

All error types are from Chart control. I somehow need totally rewrite it to obtain image by rpc (through json) in onpaint???
😱😱😱

KlausLoeffelmann · 2022-11-12T18:59:25Z

So, If I understand you correctly, then this statement is not true. [...]

It is true the way I meant and think I have written it:

You use stock-collection-editors, you don't need to use client-server separation.
You use your own Type Editor for a certain type, and that will be part of a collection (and an editor), you are already having a Client/Server separation (for the certain type), but then a simple collection editor would pick that type automatically up.
If you need however need to change the behavior for collection editors, you have to implement that yourself and most likely need more additional endpoints.

I somehow need totally rewrite it to obtain image by rpc (through json) in onpaint???
Well, the client-side does not know about the chart-control. The chart control is .NET, right? So, if the client-side needs to paint something, it can only paint what it knows. A picture sent back - yes, that would be one approach that would work.

For the collection editors: Let's not get ahead of ourselves, though. We're about to finish the first part (everything BUT modified collection editors) which is covering 80% of the scenarios. And then let's take on the next step.

kirsan31 · 2022-11-12T19:06:55Z

For the collection editors: Let's not get ahead of ourselves, though. We're about to finish the first part (everything BUT modified collection editors) which is covering 80% of the scenarios. And then let's take on the next step.

Totally agree. And whole my previous post is about single value property editor - not collection editor:

P.s. I want to make at least one editor to work, and then will look towards CollectionEditor...

----------------UPD-----------------

Oh your answer fell under the comment - did not notice it :(

Well, the client-side does not know about the chart-control. The chart control is .NET, right? So, if the client-side needs to paint something, it can only paint what it knows. A picture sent back - yes, that would be one approach that would work.

The further I dive into this, the more obvious it becomes that all this is not worth such effort :(
I am very meticulous, but I give up. I'm afraid that with this approach to writing a designer, we will lose most of the complex user controls (which have already been written and which have not yet been written) 😭

----------------UPD2-----------------

I spent over two hours trying to get this editor to work in chart:

internal class ImageValueEditor : FileNameEditor
{
    public override bool GetPaintValueSupported(ITypeDescriptorContext context)
    {
        return false;
    }
}

If you have type editors which are derived from existing type editors (like ColorEditor or FileNameEditor) for editing certain types of values for existing controls in .NET Framework, then you also need the client/server approach. That said, your control designer solution most probably doesn't need to have extra communication code to exchange data between the server and the client process. As long as you do not change the type the original editor is handling, the Designer should be able to handle the necessary communication behind the covers.

VS

Now, here is a first exciting challenge that the modern designer faces: When the custom control lives only in the server process, and the actual type editor lives only in the client, how does the WinForms Designer finds the type editor on the client side? This is where an important component in the client designer project comes into play: the TypeRoutingProvider. It holds a table of TypeRoutingDefinition objects and assigns the names of the editors to the actual types.

And even with TypeRoutingProvider I have no luck 🤪🤪🤪

Do namespaces and assembly names matter? ~~Or may be setting Editor to class property (not the class itself) need some more tricks?~~

----------------UPD3-----------------

I was able to get it work in your demo project Medium - TypeEditor. I found a very nasty designer bug that cost me a couple hours of madness ))) If you write a new editor, or change something in the client side of the editor - no changes will be visible until the studio is restarted!!! Neither rebuilds nor closing / opening of the project doesn't help - only restart.
In chart project this editor still not working - investigating...

----------------UPD4-----------------

Still no luck with chart control :(((( I don't know what to do - everything works in the test project, and doesn't work here - @KlausLoeffelmann need your help 🙏

Resulting installed nuget structure:

.nupkg.metadata
datavisualization.package.1.2211.132105.nupkg
datavisualization.package.nuspec
datavisualization.package.1.2211.132105.nupkg.sha512

lib\net6.0\System.Windows.Forms.DataVisualization.dll
lib\net6.0\System.Windows.Forms.DataVisualization.pdb

lib\net6.0\Design\WinForms\DataVisualization.Client.dll

DataVisualization.Client:

namespace Charting.Designer.Client
{
    internal class ImageValueEditor : FileNameEditor
    {
        public override bool GetPaintValueSupported(ITypeDescriptorContext context)
        {
            return true;
        }
    }

    [ExportTypeRoutingDefinitionProvider]
    internal class TypeRoutingProvider : TypeRoutingDefinitionProvider
    {
        public override IEnumerable<TypeRoutingDefinition> GetDefinitions()
        {
            return new[]
            {
                new TypeRoutingDefinition(
                    TypeRoutingKinds.Editor, 
                    nameof(ImageValueEditor), 
                    typeof(ImageValueEditor)),
            };
        }
    }
}

And string properties in chart decorated like:

[Editor("ImageValueEditor", typeof(UITypeEditor))]

kirsan31 · 2022-11-15T19:54:46Z

/cc @KlausLoeffelmann
Please take a look at my previous post when you have time. I have a few ideas with some kind of proxy project (for example on netstandard2.0) for a less time-consuming port of the designer. But for now I'm stuck at a trivial step 😰

KlausLoeffelmann · 2022-11-15T21:16:50Z

I am completely swamped this week to get the blog posts out.
And next week I am physically out-of-office.
Let me try again find some time over the weekend, but I can't promise anything. (Maybe Friday morning, let me try to schedule sometime.)

In the meantime - can you send me the link to the branch you're working in? Is it still the same branch we had before?

KlausLoeffelmann · 2022-11-15T21:17:42Z

I scheduled some time for Friday morning.

kirsan31 · 2022-11-15T21:19:34Z

In the meantime - can you send me the link to the branch you're working in? Is it still the same branch we had before?

Thank you @KlausLoeffelmann
I will push my local branch where all done (in my opinion) and post link here. With some explanations.

kirsan31 · 2022-11-16T22:14:31Z

@KlausLoeffelmann

Side note first (I think it's important): 17.5p1 designer work well with chart control referenced by nuget! So, in 17.5p1 we have:

reference by dll - Upgrade to VS Version 17.4.0 Preview 2.0 and I can't drop Chart on form kirsan31/winforms-datavisualization#4
reference by project - Designer not work when control referenced by project kirsan31/winforms-datavisualization#5
reference by nuget - all are ok.

Branch to pull: https://github.com/kirsan31/winforms-datavisualization/tree/DesignerTest
Trivial editor project (as I showed above): /src/System.Windows.Forms.DataVisualization.Client
Nuget package project: /src/System.Windows.Forms.DataVisualization.Package

Pull, build, open Form1 from DesignerTest project in designer, drag chart control to it.

The easiest property to test our ImageValueEditor is (must be a FileNameEditor in designer):

https://github.com/kirsan31/winforms-datavisualization/blob/10e3e110f0d01404afd216ec3aa6763e74b399a1/src/System.Windows.Forms.DataVisualization/ChartWinControl.cs#L1432-L1440

KlausLoeffelmann · 2022-11-16T23:40:28Z

Hmm. Just as a very quick idea, because I ran into that before: Can you try to also set the UITypeEditor base class not as a type but as string when you pass it?

I'll try to take a closer look on Friday morning.

kirsan31 · 2022-11-17T07:37:18Z

Hmm. Just as a very quick idea, because I ran into that before: Can you try to also set the UITypeEditor base class not as a type but as string when you pass it?

I have tried these three variants with no result:

Editor("ImageValueEditor", typeof(UITypeEditor))
Editor("ImageValueEditor", "UITypeEditor")
Editor("ImageValueEditor", "FileNameEditor")

KlausLoeffelmann · 2022-11-17T16:29:04Z

Can you include the namespaces to fully qualify the types?
Does that change anything?
Take a look at the template for guidance.

If that doesn't work, start with a Type Editor that doesn't inherit from an existing one (take the templates). And then modify how you need it until it breaks, so we know where to start.

kirsan31 · 2022-11-17T20:07:41Z

Can you include the namespaces to fully qualify the types? Does that change anything? Take a look at the template for guidance.

If that doesn't work, start with a Type Editor that doesn't inherit from an existing one (take the templates). And then modify how you need it until it breaks, so we know where to start.

I've already tried everything I can :(

ImageValueEditor : UITypeEditor

doesn't work too :(

The funny thing is that in the test project - Medium - TypeEditor it works, no matter how I try to spoil it - with types and strings and with any namespaces...

Everything is complicated by the fact that you constantly have to restart the studio because of this bug:

I found a very nasty designer bug that cost me a couple hours of madness ))) If you write a new editor, or change something in the client side of the editor - no changes will be visible until the studio is restarted!!! Neither rebuilds nor closing / opening of the project doesn't help - only restart.

KlausLoeffelmann · 2022-11-17T20:43:14Z

it works, no matter how I try to spoil it - with types and strings and with any namespaces...

It definitely shouldn't. Using strings as type references is really important here.

So, I think the problem is around the NuGet package pick-up. Please delete ALL the NuGet packages that get or got created in both repos, and see, if the compiler explains at one point. Make also sure, that in your test app, you only reference that NuGet and nothing else, so we can make sure, that the reference doesn't come from any other spot.

kirsan31 · 2022-11-17T21:09:45Z

Projects (note I changed the names of the projects on purpose to change the names of the resulting dlls):

Sources (namespace changed):

Only one nuget package:

1.2211.132026\.nupkg.metadata
1.2211.132026\tilerepeater.package.nuspec
1.2211.132026\tilerepeater.package.1.2211.132026.nupkg
1.2211.132026\tilerepeater.package.1.2211.132026.nupkg.sha512
1.2211.132026\lib\net6.0\TileRepeater.Cntr.dll
1.2211.132026\lib\net6.0\TileRepeater.Cntr.pdb
1.2211.132026\lib\net6.0\Design\WinForms\Tile.CL.dll

Result:

KlausLoeffelmann · 2022-11-20T18:37:00Z

OK, I took a look, and experimented a bit myself:

I noticed, the server-part of the NuGet package is missing. I am not sure at this point, if we can have the/a control-lib and designer-server-part merged in one lib, but one way or the other: I would not recommend it, anyway. Folks might later want to ship a version without any SDK dependencies or design-time functionality, so I'd separate this in any case. To try to get this fixed: Could you approach the migration the other way around: Take a generated Solution from the Type Editor template, and copy anything relevant from the chart control in there.
I also messed a bit with the type names. While in the routing-definition and the editor attribute the types need to be stated as strings, the namespaces are indeed not relevant (and - I missed that - that's also not what's done in the template). It might be a different story for potential CodeDom Serializer, but that's not the issue at hand, and we come to that later.
In addition: When I pulled your branch, the NuGet in the test app pointed to the wrong directory, and I had to fix that (just one folder level up, so I changed "." into ".."). Can you double check, if you have set-up the whole package based on the template, that the NuGet package get pulled from the correct folder?
I also checked: When the NuGet is set-up correctly, there is no need to restart VS. What I need to do though, and (@merriemcgaw FYI) that also needs to go in the blog post: I explicitly deleted any build dependencies from the test-app to the Control Designer Library project, so I can decide, when a new NuGet version gets in. Also, we should add a paragraph which would explain, that during development, you should get the latest version ("*") from the just built NuGet package rather than a particular version. It is indeed correct, that the NuGet package does not get replaced, when there is a reference to a fixed version, even if that version gets updated. It's important to tell the test app, to always get the latest version during development. Take a look at the sample app (TileRepeater, dotnet version), which I will update so it reflects the latest changes we did based on recent feedback.

Please note, I'll be OOF this week (I am only here today to get this done, because I promised you! 😸). So let's take a break this week and continue Tuesday in a week (Nov. 29th).

kirsan31 · 2022-11-20T20:16:26Z

Thank you for your time @KlausLoeffelmann

I noticed, the server-part of the NuGet package is missing. I am not sure at this point, if we can have the/a control-lib and designer-server-part merged in one lib, but one way or the other: I would not recommend it, anyway. Folks might later want to ship a version without any SDK dependencies or design-time functionality, so I'd separate this in any case.

I totally agree with your here and that's why I did exacly like this:

To try to get this fixed: Could you approach the migration the other way around: Take a generated Solution from the Type Editor template, and copy anything relevant from the chart control in there.

BUT I ran into a huge number of problems because the design part is strongly related to the control itself and it will be very difficult to separate them. Perhaps this can be done through a certain proxy project...
And in order to understand whether this will work, I decided to try the simplest thing first. Especially since your test project works fine without server-part! See screenshots in my previous post. Also if you look at DataVisualization.Package.csproj there is a commented line (I also tried this option - it didn't help):

<_File Include="$(SolutionDir)\src\System.Windows.Forms.DataVisualization\bin\$(Configuration)\$(TargetFrameworkServer)-windows\System.Windows.Forms.DataVisualization.dll" TargetDir="Design/WinForms/Server" />

In addition: When I pulled your branch, the NuGet in the test app pointed to the wrong directory, and I had to fix that (just one folder level up, so I changed "." into ".."). Can you double check, if you have set-up the whole package based on the template, that the NuGet package get pulled from the correct folder?

In my opinion, everything is in order, one point is the current directory 🤷‍♂️

In your projects, everything is exactly the same.

I also checked: When the NuGet is set-up correctly, there is no need to restart VS.

What you mean by correctly? In my tests, I rebuilt the projects, then the nuget package, then updated the package in the test app, then rebuilt that as well (test form is closed of course). I opened the form and saw no changes.. After that, I closed the solution and opened it again - it did not help, and only restart helped.

What I need to do though, and (@merriemcgaw FYI) that also needs to go in the blog post: I explicitly deleted any build dependencies from the test-app to the Control Designer Library project, so I can decide, when a new NuGet version gets in. Also, we should add a paragraph which would explain, that during development, you should get the latest version ("*") from the just built NuGet package rather than a particular version. It is indeed correct, that the NuGet package does not get replaced, when there is a reference to a fixed version, even if that version gets updated. It's important to tell the test app, to always get the latest version during development. Take a look at the sample app (TileRepeater, dotnet version), which I will update so it reflects the latest changes we did based on recent feedback.

I came to the same thoughts :) The only thing is that * reference also does not give 100% result, I had to call nuget.exe restore after building the package...

Currently it's:

<Target Name="CopyPackageD" AfterTargets="Pack" Condition="'$(Configuration)'=='Debug'">
<Copy SourceFiles="$(OutputPath)..\$(PackageId).$(PackageVersion).nupkg"
			DestinationFolder="$(SolutionDir)NuGet\BuildOut\"/>
<Exec Command="nuget.exe restore &quot;$(SolutionDir)DesignerTest\DesignerTest.csproj&quot; -ConfigFile &quot;$(SolutionDir)NuGet.config&quot;" />
</Target>

And package reference is:

<ItemGroup>
  <PackageReference Include="WinForms.DataVisualization.Debug" Version="$(MajorVer).*" />
</ItemGroup>

KlausLoeffelmann · 2022-11-20T23:13:35Z

BUT I ran into a huge number of problems because the design part is strongly related to the control itself and it will be very difficult to separate them. Perhaps this can be done through a certain proxy project...

You can reference the control projectfrom the Designer-sever project, so that shouldn't break anything in a too complicated way. If you have control dependencies to the Client (Framework) right now, that's not gonne work anyway.

kirsan31 · 2022-11-21T05:51:33Z

My bad, by the evening everything was mixed up in my head 😔
Of course, these problems are with the client side.
On the server side:

How can a serializer and a designer in a separate library affect the behavior of the editor? I would understand if they didn't work, but they just work...
In your test project, everything works fine from a single file.
I tried adding the original dll as a server part - it didn't help.
I completely separated the server part from the control and the designer did not work. With such errors:

Could not resolve type for System.Windows.Forms.Design.DataVisualization.Charting.ChartWinDesigner.
Could not resolve type for System.Windows.Forms.Design.DataVisualization.Charting.ChartWinDesignerSerializer.

If you set the name of the editor as a full qualified name then the errors will be:

Failed to load assembly: System.IO.FileNotFoundException: Could not load file or assembly

I think all of this due to assembly name bug - see my next post.
--UPD--
Yes, I checked - this is the problem.

kirsan31 · 2022-11-24T21:17:15Z

Stunned, but at some point it worked!!!
Not working: https://github.com/kirsan31/winforms-datavisualization/tree/DesignerNotWork
Working: https://github.com/kirsan31/winforms-datavisualization/tree/0c357fca784c62703918d2bb6e9484a3b72cd817

The only change is rename of main assembly from System.Windows.Forms.DataVisualization to WinForms.DataVisualization.

After this change we have side affect (two chart controls on the toolbox):

But with System.Windows.Forms.DataVisualization assembly name we had only one control on the toolbox:

As I understand this one from project (not from nuget). This is exactly why designer not working!!!
And this is clearly a bug / flaw in the designer :(
I've also checked kirsan31/winforms-datavisualization#4 and kirsan31/winforms-datavisualization#5 are not related to this. With WinForms.DataVisualization assembly name both bugs still exists :(

Also... I already found some bugs and blocking problems - we are defiantly need repo where to post them...
And I think these problems need to be solved before the release of the SDK, otherwise their solution will be a breaking change...

kirsan31 · 2022-12-04T16:38:05Z

@KlausLoeffelmann are you back? :) I've spend some time (lots :)))) on porting editors and I think now I can give a more concrete feedback.
I want to note that my task was to transfer the editors to the client library and get the maximum out of them without using cross-processor interaction and all this ViewModel staff.

Designer bugs.

We have serious bug with NuGet package pick-up due to assembly name (I think when this name crossing with .net framework) - see my two (mostly second) previous posts with explanations.
Some times ToolBox not populated with Nuget control version (the control from project is always here).
- Even when we have not see control from nuget, when we drug project control version - all client/server staff are working, so it's only ToolBox problem.
- Need to restart studio (sometimes many times) until it shows up.
Not a bug but very annoying. The client side of the control designer is loading and caсhing on first opening of the test project form in the designer. After that if you have modified client side, you need to restart VS to see this changes. I have test project with * reference to package and more of it with nuget restore before build - this not help. Designer populate and cache ToolBox only on first load (even close and reopen solution not helps). May be add some way to reload / repopulate ToolBox manually? It's also helps with previous bug :)

SDK questions / suggestions.

We have two (may be more?) internal classes: Microsoft.DotNet.DesignTools.Client.Proxies.ProxyPropertyDescriptor and Microsoft.DotNet.DesignTools.Protocol.PropertyData. It would very useful to make them public, I will explain with a concrete example from chart control (I think it's all clear from comments and code). The code from protected override void ShowHelp(). GetPropValue is my extension method to get property value with reflection:

GridItem item = grid.SelectedGridItem;
// Original code:
//_helpTopic = item.PropertyDescriptor.ComponentType.ToString() + "." + item.PropertyDescriptor.Name;

// We have a proxy object (Microsoft.DotNet.DesignTools.Client.Proxies.ProxyPropertyDescriptor) here as PropertyDescriptor.
// So to get real type we need get PropertyData (Microsoft.DotNet.DesignTools.Protocol.PropertyData) from PropertyDescriptor and then ComponentType from it.
// Because Microsoft.DotNet.DesignTools.Client.Proxies.ProxyPropertyDescriptor and Microsoft.DotNet.DesignTools.Protocol.PropertyData are internal we need to use reflection...
if (item.PropertyDescriptor.GetPropValue("PropertyData")?.GetPropValue("ComponentType") is Microsoft.DotNet.DesignTools.Protocol.Types.TypeIdentity typeIdentity)
    _helpTopic = typeIdentity.TypeName + "." + item.PropertyDescriptor.Name;

In Microsoft.DotNet.DesignTools.Client.Editors.CollectionEditor we have two private classes: DefaultCollectionForm and DefaultViewModel. I think it would helpful to make them public with ability to extend. This should make minor modifications to the default behavior easier. I find it very costly due to minimal modification to make your own dialog like in your BaseUI\DesignableCollectionEditor example.
Microsoft.DotNet.DesignTools.Client.Proxies.EnumProxy class have property Value with type of uint 🙄 Why uint? The default for enum is int🤷‍♂️ But the most important is what to do with enums that derived from long / ulong?

Questions.

With single editors +- all clear.
With simple collections editors +- same with hope on point 2. in previous section.
The main problem now is collection editor with many different classes in it. For this purpose in old CollectionEditor we have:

protected virtual Type[] CreateNewItemTypes ();

If we override it, we will have NewItemTypes return our types and UI changed like this:

In new CollectionEditor we have no CreateNewItemTypes () at all, but we have NewItemTypes 🤔
How to achieve this functionality with new designer? And this again crossing with point 2. from previous section...
For the chart control this is main question for now. AnnotationCollectionEditor is the only one editor of such type and it simple can't add elements because base (editing) type is abstract...

P.s. Can you some how ping some one from VS team? I have very specific bug with VS on my laptop: https://developercommunity.visualstudio.com/t/Net-local-variables-not-captured-by-deb/10216016 - local variables not captured by debugger at any projects any more :( I tried everything I could find on the Internet and came up with it myself - nothing helps. I really don't know what to do 😭😭😭

Thanks.

KlausLoeffelmann · 2022-12-07T02:02:35Z

@KlausLoeffelmann are you back?

I am and then I am not. I'll be physically here until end of the week, and then I will be OOF until early January.

I most certainly won't get to it until end of the week (maybe for the questions, I'll certainly try!). I will try to take some time in between the holidays (between Dec. 27th and January 3rd) but cannot promise anything.

I have one ask, though:
Please file an issue with what you pointed out here (or better 2 or 3 separate issues) in the new extensibility-repo or - for the ToolBox maybe even better in the WinForms repo - at add an area: Designer-label to it. Ping me, if you have problems accessing it.

I will then take this repo private, but don't worry: You, of course, will still be able to access it, so we can go back to look up discussions we've had in the past.

This way, we will be working on issues on the right place.

kirsan31 · 2022-12-10T16:27:21Z

@KlausLoeffelmann
Done:
dotnet/winforms#8348
dotnet/winforms#8360

microsoft/winforms-designer-extensibility#4
microsoft/winforms-designer-extensibility#5
microsoft/winforms-designer-extensibility#6

KlausLoeffelmann added 3 commits April 22, 2022 13:02

Add specific info for server-only and client-server approach.

1e1b18f

Correct typo.

4a83903

Add content for server-only project setup

38b474f

This was referenced Dec 7, 2022

Designer can't resolve client/server nuget library in some cases depend on assembly name dotnet/winforms#8348

Open

Some times ToolBox not populated with user control from Nuget dotnet/winforms#8360

Open

UFuz mentioned this pull request Jan 2, 2023

Designer column model broken on .NET6 schoetbi/XPTable#49

Closed

KlausLoeffelmann closed this Apr 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Designer SDK Blog post #6

Designer SDK Blog post #6

KlausLoeffelmann commented Apr 22, 2022

kirsan31 commented Nov 12, 2022 •

edited

Loading

KlausLoeffelmann commented Nov 12, 2022

KlausLoeffelmann commented Nov 12, 2022

kirsan31 commented Nov 12, 2022 •

edited

Loading

KlausLoeffelmann commented Nov 12, 2022 •

edited

Loading

kirsan31 commented Nov 12, 2022 •

edited

Loading

kirsan31 commented Nov 15, 2022

KlausLoeffelmann commented Nov 15, 2022

KlausLoeffelmann commented Nov 15, 2022

kirsan31 commented Nov 15, 2022 •

edited

Loading

kirsan31 commented Nov 16, 2022

KlausLoeffelmann commented Nov 16, 2022

kirsan31 commented Nov 17, 2022

KlausLoeffelmann commented Nov 17, 2022

kirsan31 commented Nov 17, 2022

KlausLoeffelmann commented Nov 17, 2022 •

edited

Loading

kirsan31 commented Nov 17, 2022 •

edited

Loading

KlausLoeffelmann commented Nov 20, 2022

kirsan31 commented Nov 20, 2022

KlausLoeffelmann commented Nov 20, 2022

kirsan31 commented Nov 21, 2022 •

edited

Loading

kirsan31 commented Nov 24, 2022 •

edited

Loading

kirsan31 commented Dec 4, 2022

KlausLoeffelmann commented Dec 7, 2022

kirsan31 commented Dec 10, 2022

Designer SDK Blog post #6

Designer SDK Blog post #6

Conversation

KlausLoeffelmann commented Apr 22, 2022

kirsan31 commented Nov 12, 2022 • edited Loading

KlausLoeffelmann commented Nov 12, 2022

KlausLoeffelmann commented Nov 12, 2022

kirsan31 commented Nov 12, 2022 • edited Loading

KlausLoeffelmann commented Nov 12, 2022 • edited Loading

kirsan31 commented Nov 12, 2022 • edited Loading

kirsan31 commented Nov 15, 2022

KlausLoeffelmann commented Nov 15, 2022

KlausLoeffelmann commented Nov 15, 2022

kirsan31 commented Nov 15, 2022 • edited Loading

kirsan31 commented Nov 16, 2022

KlausLoeffelmann commented Nov 16, 2022

kirsan31 commented Nov 17, 2022

KlausLoeffelmann commented Nov 17, 2022

kirsan31 commented Nov 17, 2022

KlausLoeffelmann commented Nov 17, 2022 • edited Loading

kirsan31 commented Nov 17, 2022 • edited Loading

KlausLoeffelmann commented Nov 20, 2022

kirsan31 commented Nov 20, 2022

KlausLoeffelmann commented Nov 20, 2022

kirsan31 commented Nov 21, 2022 • edited Loading

kirsan31 commented Nov 24, 2022 • edited Loading

kirsan31 commented Dec 4, 2022

Designer bugs.

SDK questions / suggestions.

Questions.

KlausLoeffelmann commented Dec 7, 2022

kirsan31 commented Dec 10, 2022

kirsan31 commented Nov 12, 2022 •

edited

Loading

kirsan31 commented Nov 12, 2022 •

edited

Loading

KlausLoeffelmann commented Nov 12, 2022 •

edited

Loading

kirsan31 commented Nov 12, 2022 •

edited

Loading

kirsan31 commented Nov 15, 2022 •

edited

Loading

KlausLoeffelmann commented Nov 17, 2022 •

edited

Loading

kirsan31 commented Nov 17, 2022 •

edited

Loading

kirsan31 commented Nov 21, 2022 •

edited

Loading

kirsan31 commented Nov 24, 2022 •

edited

Loading