Because winforms is a product dependency, and NetCoreApp is a toolset dependency, this will 'hoist' NetCore.App to be a product dependency. Wpf feeds into core-setup as a product dependency, and thus this creates a cycle.

winforms, and netcore.app, should indeed be product-dependencies, i think. i don't have strong feelings about what we call netcore.app.

i realize that this creates a problem. the lack of the dependency leaves another problem dangling.

do you have suggestions on how to solve the build failure?

/cc @ericstj

Because winforms is a product dependency, and NetCoreApp is a toolset dependency, this will 'hoist' NetCore.App to be a product dependency. Wpf feeds into core-setup as a product dependency, and thus this creates a cycle.

winforms, and netcore.app, should indeed be product-dependencies, i think. i don't have strong feelings about what we call netcore.app.

i realize that this creates a problem. the lack of the dependency leaves another problem dangling.

do you have suggestions on how to solve the build failure?

/cc @ericstj

Remove the dependency edge from wpf/winforms/wpf-int -> core-setup? :)

Remove the dependency edge from wpf/winforms/wpf-int -> core-setup? :)

I remember asking about exactly that when we started the work to build WindowsDesktop.App in core-setup (by moving it out of dotnet-trusted), to see whether it made more sense to host it in dotnet/wpf (or dotnet-wpf-int). I don't think we had intentionally considered a separate repo (dotnet/windowsdesktop?), but I think the response I heard at that time might have applied to variations on the idea - that the core-setup infrastructure that would have to be re-purposed hadn't yet been refactored and ready for reuse... (or something approximating that bottom-line).

Now we still have the current coherency problem between M.P.Winforms and Microsoft.NETCore.Platforms....

What are the downsides of declaring Winforms as a toolset dependency, and adding a dependency to NetCore.App anyway? It would be a lie, but I don't think I understand its practical effects fully.. In practice, I see DARC updates coming in at par for product and toolset dependencies...

I remember asking about exactly that when we started the work to build WindowsDesktop.App in core-setup (by moving it out of dotnet-trusted), to see whether it made more sense to host it in dotnet/wpf (or dotnet-wpf-int). I don't think we had intentionally considered a separate repo (dotnet/windowsdesktop?), but I think the response I heard at that time might have applied to variations on the idea - that the core-setup infrastructure that would have to be re-purposed hadn't yet been refactored and ready for reuse... (or something approximating that bottom-line).

Yeah, I believe the repurposing was the primary issue. @ericstj may be able to comment on this.

What are the downsides of declaring Winforms as a toolset dependency, and adding a dependency to NetCore.App anyway? It would be a lie, but I don't think I understand its practical effects fully.. In practice, I see DARC updates coming in at par for product and toolset dependencies...

Toolset dependencies are viewed differently from the aspect of coherency than product dependencies. Product dependencies say: "each product dependency within the graph must match". Toolset dependencies do not say such things. They can vary. For example, corefx has a toolset dependency on coreclr for the purposes of testing. Because corefx takes a product dependency on coreclr, there is no way to resolve that cycle.

I guess there may be another possibility:

wpf/wpf-int/winforms take direct dependencies on corefx but do not tie them to microsoft.netcore.app, and use CoherentParentDependency to align those across your stack.

But, I'm not sure what the implications of that actually are. It's pretty risky to change this late.

The bottom line is that there cannot be a product dependency cycle, and we probably shouldn't lie about what is a product dependency cycle. The question is why has this showed up just now.

@AdamYoblick Do you think this failure in wpf was triggered by the RuntimeFrameworkVersion fix in winforms yesterday somehow?

/cc @wtgodbe @leecow

Definitely possible, as wpf has a dependency on winforms. We took an update from core-setup and we had to move it up in order for our integration tests to run properly. I'm certainly open to a different solution, but that's what dnceng advised me to do :)

Actually, @vatsan-madhavan, maybe the right thing to do here is to have wpf depend on the same version of M.N.A. pulled into winforms? This PR has this relationship inverted, causing the issues, but perhaps you just meant the opposite?

That's kind of unfortunate though, that means wpf has to update every time winforms takes a netcore.app update from maestro

This can't be added. Because you're modifying a product dependency

That's kind of unfortunate though, that means wpf has to update every time winforms takes a netcore.app update from maestro

That dependency edge really already exists today, becuase a new netcore.app in winforms will produce a new build, which will end up in here.

wpf has to produce a new build when winforms does, but in the past they haven't had to update their versions in lockstep with winforms I don't think. I could be wrong though?

@AdamYoblick Right :/

@vatsan-madhavan This is superceded by the change I made in #1001

@mmitche - thanks for puzzling this out!

Your change #1001 definitely looks better.

Closing.