Winforms: .NET Core 3.0 daily build includes WinForms reference assemblies instead of runtime assemblies

[0xd4d]

3.0.100-preview-009839 (latest daily build)

The following assemblies are reference assemblies:

• System.Windows.Forms
• System.Windows.Forms.Design
• System.Windows.Forms.Design.Editors

An exception is thrown at runtime if you try to run a WinForms application.

[AdamYoblick]

We did a release into .net core sdk on Friday, so this is mine to investigate. Will look at this first thing today. Thank you.

[AdamYoblick]

@zsd4yr assigning you as well for visibility

[AdamYoblick]

As a workaround, please use a daily build released before last Friday (or the stable build) and that should solve the problem temporarily.

[zsd4yr]

~Alright, what I'm finding by opening with dotpeek is that the assemblies are not reference assemblies but they are flagged as such...~

~Looking into that now~

EDIT:

I am getting different behavior when I open with dotPeek versus Ilspy. Ilspy is showing only references...

[zsd4yr]

This flag is not being set as part of release or debug builds from this repository. I will check out internal flow next

[zsd4yr]

Can confirm this is fixed internally; Let's give the remainder of the day to let the changes trickle to the SDK

Thanks @0xd4d for flagging this 😄

[nguerrera]

@AdamYoblick @zsd4yr The "trickling" process isn't automatic yet. If there's an official new build available to insert into the SDK, I can do that. Just let me know.

[AdamYoblick]

Yeah we know :) Zach will create the PR and we'll ping you when it's ready to go.

But since you brought it up...is there a timeline for getting dependency flow set up at least for inputs into dotnet sdk? We did this work for the DotNet-Trusted branch and it was pretty minimal for inputs. Maybe I can create the PR for this in dotnet-sdk?

[zsd4yr]

@AdamYoblick @zsd4yr The "trickling" process isn't automatic yet. If there's an official new build available to insert into the SDK, I can do that. Just let me know.

Thanks for the heads up. I just wanted to make sure eveyrone on the thread knew that this would not be _instantaneous_. Your clarification is better though 😄

[nguerrera]

Cc @livarcocc.

We are getting close to moving dotnet/core-sdk to arcade, which should make dependency uptake easier.

I don’t have an ETA.

I don’t know what you have in mind with the PR but I would hesitate to make changes to the current build process.

[AdamYoblick]

The PR would be exactly the changes to enable darc in arcade, without building with the arcade sdk. :)

We are just finishing up those changes in the repo that builds the WindowsDesktop shared UI framework, and the work is pretty minimal. I’m going to document all of it and show it to you guys.

I think it would bring some immediate value to both coresdk, as well as consumers of coresdk, without the risk of a full arcade update.

Thoughts? :)

[nguerrera]

We already have a branch building with arcade and will merging it up to master soon. I don't think it's worth duplicating a subset of that unless it's trivial.

[AdamYoblick]

The flow IN is trivial and is identical to the “real” arcade work. This is actually more important to us so our latest bits can flow into coresdk

The flow out is more custom and can probably wait.

[zsd4yr]

This should now be solved. @0xd4d and others looking for a fix here, please see the new Core SDK build.

I have confirmed that this is now fixed in 3.0.100-preview-009844