[Mono-dev] State of aspnetwebstack on mono

Mon Nov 3 21:48:20 UTC 2014

Hi Miguel,

I've rebased, and also added the reordering of the compilation.  Please can
you review that before you merge? I've tested it on a fresh clone and it
works, but I can understand that this would be a delicate process, so would
prefer it at least gets a glance over.

Thanks again for all you're doing.

https://github.com/mono/mono/pull/1363

Martin

On 2 November 2014 13:51, Miguel de Icaza <miguel at xamarin.com> wrote:

> I don't really have a strong opinion.   Can you teens me the email you
> want me to look at?
>
>
> On Sunday, November 2, 2014, Martin Thwaites <monoforum at my2cents.co.uk>
> wrote:
>
>> Thanks Miguel,
>>
>> I'll remove that and rebase then.  As the test does both protect an
>> unprotect, should there really be a separate test?
>>
>> Martin
>>
>> On 2 November 2014 13:09, Miguel de Icaza <miguel at xamarin.com> wrote:
>>
>>> Hello Martin,
>>>
>>> The TODO should be used to flag to the consumer that something is not
>>> implemented or half implemented.
>>>
>>> But we do not do this for missing items that could be configured out of
>>> band.  For those, if they matter, we file bug reports.
>>>
>>> Miguel
>>>
>>> On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites <
>>> monoforum at my2cents.co.uk> wrote:
>>>
>>>> Amazing, thanks Miguel, comments inline.
>>>>
>>>> On 2 Nov 2014 00:52, "Miguel de Icaza" <miguel at xamarin.com> wrote:
>>>> >>
>>>> >>
>>>> >> 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.
>>>>
>>>> I don't believe the TODO can be removed as the Encrypt Decrypt methods
>>>> don't allow you use custom decryptors (from what I could tell) it's 4.5
>>>> specific functionality and controlled via the Web.config.
>>>>
>>>> Do you want me to expand on the TODO to make it clearer?
>>>> >
>>>> >>
>>>> >> 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.
>>>>
>>>> Before I send this, I need to change the build order in the mcs/class
>>>> makefile, and wanted to run that past you first as it strikes me as
>>>> something via fragile.  I sent a message to the list a few days about it,
>>>> could you respond on that and I'll resend?
>>>> >
>>>> >>
>>>> >> 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?
>>>> It's not actually required as the default on ReadEntityBodyMode means
>>>> that all clients of the code should go directly to input stream.  The code
>>>> here is enough to ensure that calling code works.
>>>>
>>>> Looking at various posts about how to used the
>>>> GetBufferlessInputStream,  it looks like it needs Async reads as well as
>>>> Synchronous, so it's a little more involved.
>>>>
>>>> The only thing that we could potentially do is change the exception to
>>>> one you get when you try to read it buffered when classic is set.
>>>> >
>>>> > 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/20141103/2d004a86/attachment-0001.html>