Remove dependency on Owin.dll and merge in IAppBuilder

[damianh]

Hi Chris,

Good to see this project moved to github :)

As we know Owin.dll had its controversy... As a major release allows breaking changes, I suggest merging in IAppBuilder into Microsoft.Owin.dll. The namespace Owin. could be retained within the lib to minimise changes to libraries that depend on Microsoft.Owin.

Cheers

[Tratcher]

Unfortunately that breaking change would break every dependent library and prevent you from using any 3.x middleware with 4.x. There's a limit to the degree of breaking changes we're willing to inflict.

[damianh]

Worth a try :)

…

On 29 Mar 2017 11:02 p.m., "Chris R" ***@***.***> wrote: Unfortunately that breaking change would break every dependent library and prevent you from using any 3.x middleware with 4.x. There's a limit to the degree of breaking changes we're willing to inflict. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgXBP_aphazXQ1hrBZhmo_LXq1owYxks5rqsbfgaJpZM4ML-Bh> .

[MaximRouiller]

Ahhh @damianh. Always willing to blow things up. 😉

[muratg]

This would be a too breaking change which we don't plan to do.

[damianh]

The irony is that the owin community at the time opposed owin.dll for this precise reason.

Now there will not likely be a netstandard version of owin.dll thus freezing the entire chain of code that depends on it.

Sad.

[Tratcher]

Actually, updating the Owin.nupkg would be easier and far less breaking. However, you'd have to invoke the ghost of @lodejard as I think he was the one with the signing keys.

[davidfowl]

Owin.dll is community owned IIRC. I would ping @panesofglass owin/owin.dll#25

[damianh]

Ok, I think an owin 1.0.1 package with a netstandard bin would be acceptable.

@Tratcher @lodejard, do either of you know who owns this profile https://www.nuget.org/profiles/owincontrib ? I contacted @panesofglass, @skoon and @serialseb and none of them know.

[serialseb]

Any reason not to do a type redirect to an MS assembly and update the package with an empty one for legacy applications?

[Tratcher]

@serialseb interesting idea, but it would be hard to avoid a circular dependency in the process. You'd have to reverse the relationship between Owin and Microsoft.Owin, or introduce a 3rd package Microsoft.Owin.Abstractions.

@damianh I think Louis and I are part of https://www.nuget.org/profiles/owincontrib, as we originally uploaded the package.

[panesofglass]

I'm tempted to create a netstandard owin.dll just to unblock this. I just wish I understood why moving the interfaces into Microsoft.Owin is a no-go. I've never understood the argument, especially with a major version change. Also, if we brought it back, I think we should insist that the IAppBuilder interface expose actual types to help contributors know what's allowed and what's not. I think that would be its own breaking change. (Not sure how I missed all these messages in the past.)

[serialseb]

I can imagine that it would be doable to do the type redirect, but it may not be needed. If you make owin a meta package for Microsoft.Owin, and move the Owin.dll in that Microsoft package, I fail to see how that would be introducing any problem if a new version comes out, you jsut remove the Owin package from the package dependency and it'll eventually die of, and anything that was binding to the owin.dll in the owin package could now bind to owin.dll in Microsoft.Owin? It may prevent this from ever happening again or having to ever resuscitate the dead again? 🧟‍♀️🧟‍♂️

[serialseb]

Also may want to @Tratcher as i don't think anyone gets notifications on closed stuff at MS

[davidfowl]

We have no plans to port katana to be netstandard. Owin.dll though, I actually have no idea what the deal is there... What's the end goal here?

[serialseb]

I think owin/owin.dll#26

[panesofglass]

@davidfowl some of us still have web infrastructure written in OWIN we don't necessarily want to rewrite that depends on Katana, and we would like to update it to run on netstandard/netcore. Does that sum it up, @damianh and @serialseb?

[serialseb]

only dep i have on IAppBuilder is for the katana integration package, so moving the dependency from one package to another or leaving the metapackage as is wouldn't bother me much, I never cared for that interface as you know.

[damianh]

That indeed sums it up @panesofglass

[davidfowl]

But we're not going to support Katana on netstandard, we just don't have the man power to support it.