[Mono-dev] State of aspnetwebstack on mono

[Miguel de Icaza]

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


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

Manually aded


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

Miguel

> 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
> together.
>
> 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).
>
> https://github.com/martinjt/mono/tree/mvc_allfixes
>
> Thanks for everyone's help.
>
> Martin
>
> On 20 October 2014 20:42, Martin Thwaites <monoforum at my2cents.co.uk>
> wrote:
>
>> 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.
>>
>> Martin
>> 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.
>>>
>>> Miguel
>>>
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141101/efd90eb6/attachment.html>