Remove dependency on Owin.dll and merge in IAppBuilder about aspnetkatana HOT 19 CLOSED

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.

from aspnetkatana.

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

from aspnetkatana.

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.

from aspnetkatana.

from aspnetkatana.

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

from aspnetkatana.

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

from aspnetkatana.

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.

from aspnetkatana.

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

from aspnetkatana.

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.

from aspnetkatana.

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

from aspnetkatana.

@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.

from aspnetkatana.

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.)

from aspnetkatana.

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? 🧟‍♀️🧟‍♂️

from aspnetkatana.

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

from aspnetkatana.

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?

from aspnetkatana.

I think owin/owin.dll#26

from aspnetkatana.

@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?

from aspnetkatana.

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.

from aspnetkatana.

That indeed sums it up @panesofglass

from aspnetkatana.