[Mono-dev] State of aspnetwebstack on mono
Miguel de Icaza
miguel at xamarin.com
Sun Nov 2 00:52:27 UTC 2014
> PR1349: https://github.com/mono/mono/pull/1349
> *This is the machine key work, and needs a small tweak before it can be
> merged that I will do this week.*
I believe the TODO can be removed. Can you do that? See comments on pull
> PR1363: https://github.com/mono/mono/pull/1363
> *Another of mine with the MembershipPasswordAttribute*
Do you mind resending this? It can no longer be auto-merged from the UI.
> PR1365: https://github.com/mono/mono/pull/1365
> *This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has said
> he'll take a look at it.*
> PR1370: https://github.com/mono/mono/pull/1370
> *Small one implementing a default of the ReadEntityBodyMode*
Got this one by hand.
> PR1371: https://github.com/mono/mono/pull/1371
> *Another small one, implementing the ClientDisconnectedToken*
And this one automatically.
> PR1372: https://github.com/mono/mono/pull/1372
> *A final small one around the GetBuffer* methods in the httprequest.*
I do not like this one. Is there a reason we can not implement the
required functionality instead?
> There is 1 final small piece that either myself of Chris Carroll will get
> done this week which is around the AppendTrailing slash and lowercaseUrls
> properties in RouteBase class. We just need to put the implementation
> Anyway, after applying all of these, my large WebAPI solution not only
> compiles, but it also runs!
> If you want to checkout what it looks like with all the patches applied,
> that would be great, I'd love to have some more information on whether it
> does work. I'm sure there will still be bugs, but if it works mostly, then
> bug fixing is easy (famous last words).
> Thanks for everyone's help.
> On 20 October 2014 20:42, Martin Thwaites <monoforum at my2cents.co.uk>
>> Hi Miguel,
>> The code that I'm referring to here is that of the aspnetwebstack on
>> codeplex. That is to say that they are not something where you can remove
>> the code and recompile (unless there as a specific mono implementation
>> which is not ideal). The goal is to have the compiled dlls that are
>> available on nuget work, without tweaking to a person's application.
>> I'll have a look and see if I can see where it would be used, but still
>> as you've said on one of my pulls, a half done implementation is better
>> than none.
>> Having the application throw a missing method exception should not be the
>> recommended approach when we can add the property and default it to false.
>> Thanks, and please don't think that things won't getting better with my
>> reviews. I'm learning what you want so I can review better and help reduce
>> the burden on you and your staff.
>> On 20 Oct 2014 20:04, "Miguel de Icaza" <miguel at xamarin.com> wrote:
>>> As for the properties, although they should do something to the
>>>> generated urls, simply adding them should surely be a valid pull? the
>>>> issue at the moment is that without them, you get an exception even if it
>>>> should be false. I actually think that these are used by other classes
>>>> when generating urls, not the route collection itself, but I don't know for
>>>> sure. Considering that adding them is very low risk, can we not just
>>>> accept the pull and ask for further work.
>>> Nope, all they do is allow some code to be compiled, and then get the
>>> wrong result.
>>> You might as well remove the dependency of those properties, and see
>>> what else breaks on whatever piece of code you are trying to build.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list