Re: [Mono-dev] State of aspnetwebstack on mono
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 mig...@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 monofo...@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 mig...@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 monofo...@my2cents.co.uk wrote: Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@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 monofo...@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
Re: [Mono-dev] State of aspnetwebstack on mono
Hi Miguel, I've also updated the MachineKey.Protect implementation to have the TODO removed now. Please can you merge both https://github.com/mono/mono/pull/1363 (Membership) and https://github.com/mono/mono/pull/1349 (MachineKey) when you're next free. I'll start another thread about the other outstanding stuff. Thanks, Martin On 3 November 2014 21:48, Martin Thwaites monofo...@my2cents.co.uk wrote: 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 mig...@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 monofo...@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 mig...@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 monofo...@my2cents.co.uk wrote: Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@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 monofo...@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,
Re: [Mono-dev] State of aspnetwebstack on mono
Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@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 monofo...@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 mig...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
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 monofo...@my2cents.co.uk wrote: Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@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 monofo...@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 mig...@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,
Re: [Mono-dev] State of aspnetwebstack on mono
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 mig...@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 monofo...@my2cents.co.uk wrote: Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@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 monofo...@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 mig...@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
Re: [Mono-dev] State of aspnetwebstack on mono
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 monofo...@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 mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@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 monofo...@my2cents.co.uk javascript:_e(%7B%7D,'cvml','monofo...@my2cents.co.uk'); wrote: Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, Miguel de Icaza mig...@xamarin.com javascript:_e(%7B%7D,'cvml','mig...@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 monofo...@my2cents.co.uk javascript:_e(%7B%7D,'cvml','monofo...@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 mig...@xamarin.com
Re: [Mono-dev] State of aspnetwebstack on mono
Hi, I've noticed that new functionality is going into the wrappers, while in my opinion that the functionality belongs to HttpRequest and HttpResponse: * HttpRequestBase.ReadEntityBodyMode: returning 0 instead of ReadEntityBodyMode.Classic made more sense * HttpRequestWrapper.ReadEntityBodyMode: wrapper is not supposed to implement functionality, that belongs to HttpRequest * HttpRequestWrapper.Abort: wrapper is not supposed to implement functionality, that belongs to HttpRequest * HttpResponseWrapper.ClientDisconnectedToken: wrapper is not supposed to implement functionality, that belongs to HttpResponse As for the GetBuffer* methods: * Mono already implements HttpRequest.GetBufferlessInputStream, so hard coding ReadEntityBodyMode.Classic limits Mono's compatibility * Implementing GetBufferedInputStream based on the existing GetBufferlessInputStream implementation doesn't seem to be too difficult * HttpWorkerRequest in 4.5 has support for asynchronous operations, but that does not have to be implemented for this to work because the Stream base class implements async operations using the sync methods Thank you. Kornel On 11/2/2014 1:52 AM, Miguel de Icaza 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. 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 monofo...@my2cents.co.uk mailto:monofo...@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 mig...@xamarin.com mailto:mig...@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.
Re: [Mono-dev] State of aspnetwebstack on mono
On 2 November 2014 14:26, Kornel Pal kornel...@gmail.com wrote: Hi, I've noticed that new functionality is going into the wrappers, while in my opinion that the functionality belongs to HttpRequest and HttpResponse: - HttpRequestBase.ReadEntityBodyMode: returning 0 instead of ReadEntityBodyMode.Classic made more sense - HttpRequestWrapper.ReadEntityBodyMode: wrapper is not supposed to implement functionality, that belongs to HttpRequest These are a bit of a fudge granted, at the moment, what we're doing is forcing the client (calling application) to use the Request.InputStream stream instead of using the Buffer methods. This is important until we have a full implementation of the methods required to do all the other logic. - HttpRequestWrapper.Abort: wrapper is not supposed to implement functionality, that belongs to HttpRequest This is a crude implementation, and will need to be properly implemented in HttpRequest at some point. I opted to do it in the Wrapper so it's known that it's not a proper implementation. There is a bug here that I'm not sure whether it causes the BeginGetRequestStream or BeginGetResponse to be called, so it really needs a fair bit of work. - HttpResponseWrapper.ClientDisconnectedToken: wrapper is not supposed to implement functionality, that belongs to HttpResponse This should be an easy fix, to simply do the return CancellationToken.None from the HttpResponse instead. As for the GetBuffer* methods: - Mono already implements HttpRequest.GetBufferlessInputStream, so hard coding ReadEntityBodyMode.Classic limits Mono's compatibility Essentially, I had choose only 1 value as I didn't have time to implement the other options. Choosing Classic meant that we could ensure that new clients revert to functionality we know works. We're not saying that this is the way it will always work, just that this is a starting point for people. Once all the methods have been implemented, this will obviously be changed. - Implementing GetBufferedInputStream based on the existing GetBufferlessInputStream implementation doesn't seem to be too difficult Difficulty is in the eye of the beholder. - HttpWorkerRequest in 4.5 has support for asynchronous operations, but that does not have to be implemented for this to work because the Stream base class implements async operations using the sync methods I've simply not had the time to look into this part yet. I've been thinking of a minimal viable product that allows MVC/WebAPI to work out of the box on mono, not looking at what methods need to be implemented to complete a full implementation of ASP.NET. This whole area is something that is coupled with the ReadEntityBodyMode, it will be great to get them all in, and I will be looking at them, they are just not part of the MVP work. Thank you. Kornel On 11/2/2014 1:52 AM, Miguel de Icaza 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. 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 monofo...@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
Re: [Mono-dev] State of aspnetwebstack on mono
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 monofo...@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 mig...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hey Miguel, you forgot to add the files when you manually merged https://github.com/mono/mono/pull/1365 in b11044a9a64a6b1eff3a0c79c2da2b2ba78808d3. -- Alex From: mig...@xamarin.com Date: Sat, 1 Nov 2014 20:52:27 -0400 To: monofo...@my2cents.co.uk CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] State of aspnetwebstack on mono 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 monofo...@my2cents.co.ukmailto:monofo...@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 mig...@xamarin.commailto:mig...@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@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Added On Sat, Nov 1, 2014 at 9:22 PM, Alexander Köplinger alex.koeplin...@outlook.com wrote: Hey Miguel, you forgot to add the files when you manually merged https://github.com/mono/mono/pull/1365 in b11044a9a64a6b1eff3a0c79c2da2b2ba78808d3. -- Alex From: mig...@xamarin.com Date: Sat, 1 Nov 2014 20:52:27 -0400 To: monofo...@my2cents.co.uk CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] State of aspnetwebstack on mono 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 monofo...@my2cents.co.ukmailto:monofo...@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 mig...@xamarin.commailto:mig...@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@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hi All, Just another quick update. Some potentially amazing news. I've managed to get a fairly large MVC 5.2/WebAPI running on mono! That is out of the box, without any special versions of dll's (other than removing the Microsoft.Web.Infrastructure.dll I think. So, there are a few outstanding PR's that need to reviewed and merged, but the end is in sight! Special thanks go out to Kornel Pal for implementing the HttpTaskAsyncHandler as this was going to be a big uphill struggle for me so you saved me a lot of time. So the list of PR's that need reviewing (not including ones already reviewed and merged) in order to make this work are: PR1163: https://github.com/mono/mono/pull/1163 *This is done by Mike Morano and has recently been re-done without the offending code (now added in my PR1363).* 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.* PR1363: https://github.com/mono/mono/pull/1363 *Another of mine with the MembershipPasswordAttribute* 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* PR1371: https://github.com/mono/mono/pull/1371 *Another small one, implementing the ClientDisconnectedToken* PR1372: https://github.com/mono/mono/pull/1372 *A final small one around the GetBuffer* methods in the httprequest.* 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 monofo...@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 mig...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hi Daniel, I'm referring to all the work coming out of the aspnetwebstack repository on codeplex. I don't think MVC 6 is being developed there yet. Currently that cover MVC and Webapi that I know of, but there could be others. It essentially the codebase used to create the nuget packages. I actually hit a little snag last night in that after stubbing everythingthat shouldn't be relevant, I've got to a point where all typeload exceptions are gone in WebAPI. However, all Webapi requests just result in an endless request to the server. So this may be a fruitless journey. On the plus side, MVC 5.2.2 works out of the box it seems. Thanks, Martin On 20 Oct 2014 02:43, Daniel Lo Nigro li...@dan.cx wrote: By aspnetwebstack do you mean the current ASP.NET stack or do you mean ASP.NET vNext? On Sun, Oct 19, 2014 at 1:37 AM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi all, Just wanted to give a quick update on where I'm at with getting things implemented for the aspnetwebstack to work on mono. As I've said before, my goal is to make it so that the aspnetwebstack solution will compile against mono, without tweaking anything (this is stage 1). It's proving to both a relatively small task, but also very taxing in terms of me having to learn quite a lot. *Note: I'm not looking at the tests in aspnetwebstack at the moment, that will be stage 2, a lot seem to require things we don't have yet.* In summary, it's not that far off, and once it's done, at least we'll be able to see which methods may need bugfixing as the webstack will load at least. The main issue is getting the PRs approved, but my hope is that if we can collate a list of the all, we can ask that they are reviewed together and considering they will make one of the most up and coming web technologies work on mono, I would say there is a good reason to try and prioritise it. Here are the current PR's, I've reviewed the ones that aren't mine and they now look ok, we just need a contributor to review/merge them. PR874 - from Chris Carroll with a few properties implemented around routes PR1163 - from AerisG222 which includes a few changes around Unvalidated parameters and some other bits PR1349 - From me regarding MachineKey.Protect methods PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work, just the interface) PR1354 - From me regarding Request.Abort Outstanding items that I could do with help with: 1. ReadEntityBodyMode needs properly implementing 2. Request.GetBufferedInputStream needs implementing. Request.GetBufferlessInputStream needs implementing (looks like it's already partially implemented). 3. HttpResponseBase.SuppressFormsAuthenticationRedirect needs implementing 4. HttpTaskAsyncHandler needs implementing. 5. HttpResponse.ClientDisconnectedToken needs implementing (can just return CancellationToken.None and it should be fine but a proper implementation would be better). 6. Do something about System.Data.EntityState, it's supposed to live in System.Data.Entity.dll which we don't have but MVC checks against. 7. Do something about System.Web.UI.DataVisualization.Charting, I don't want to have to change the aspnetwebstack code to exclude it, so maybe just stub it all out? I'm planning on doing the HttpTaskAyncHandler next which will probably take me a couple of evenings this week. However, if someone thinks that they could do it without extensive learning (which is what I'm going to need to do), then by all means take that on and I'll do some of the others. I'll let you all know when I get further. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Martin, With vNext, they have moved from codeplex to github. You can find the new repo here: https://github.com/aspnet -Mike On Mon, Oct 20, 2014 at 4:01 AM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi Daniel, I'm referring to all the work coming out of the aspnetwebstack repository on codeplex. I don't think MVC 6 is being developed there yet. Currently that cover MVC and Webapi that I know of, but there could be others. It essentially the codebase used to create the nuget packages. I actually hit a little snag last night in that after stubbing everythingthat shouldn't be relevant, I've got to a point where all typeload exceptions are gone in WebAPI. However, all Webapi requests just result in an endless request to the server. So this may be a fruitless journey. On the plus side, MVC 5.2.2 works out of the box it seems. Thanks, Martin On 20 Oct 2014 02:43, Daniel Lo Nigro li...@dan.cx wrote: By aspnetwebstack do you mean the current ASP.NET stack or do you mean ASP.NET vNext? On Sun, Oct 19, 2014 at 1:37 AM, Martin Thwaites monofo...@my2cents.co.uk wrote: Hi all, Just wanted to give a quick update on where I'm at with getting things implemented for the aspnetwebstack to work on mono. As I've said before, my goal is to make it so that the aspnetwebstack solution will compile against mono, without tweaking anything (this is stage 1). It's proving to both a relatively small task, but also very taxing in terms of me having to learn quite a lot. *Note: I'm not looking at the tests in aspnetwebstack at the moment, that will be stage 2, a lot seem to require things we don't have yet.* In summary, it's not that far off, and once it's done, at least we'll be able to see which methods may need bugfixing as the webstack will load at least. The main issue is getting the PRs approved, but my hope is that if we can collate a list of the all, we can ask that they are reviewed together and considering they will make one of the most up and coming web technologies work on mono, I would say there is a good reason to try and prioritise it. Here are the current PR's, I've reviewed the ones that aren't mine and they now look ok, we just need a contributor to review/merge them. PR874 - from Chris Carroll with a few properties implemented around routes PR1163 - from AerisG222 which includes a few changes around Unvalidated parameters and some other bits PR1349 - From me regarding MachineKey.Protect methods PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work, just the interface) PR1354 - From me regarding Request.Abort Outstanding items that I could do with help with: 1. ReadEntityBodyMode needs properly implementing 2. Request.GetBufferedInputStream needs implementing. Request.GetBufferlessInputStream needs implementing (looks like it's already partially implemented). 3. HttpResponseBase.SuppressFormsAuthenticationRedirect needs implementing 4. HttpTaskAsyncHandler needs implementing. 5. HttpResponse.ClientDisconnectedToken needs implementing (can just return CancellationToken.None and it should be fine but a proper implementation would be better). 6. Do something about System.Data.EntityState, it's supposed to live in System.Data.Entity.dll which we don't have but MVC checks against. 7. Do something about System.Web.UI.DataVisualization.Charting, I don't want to have to change the aspnetwebstack code to exclude it, so maybe just stub it all out? I'm planning on doing the HttpTaskAyncHandler next which will probably take me a couple of evenings this week. However, if someone thinks that they could do it without extensive learning (which is what I'm going to need to do), then by all means take that on and I'll do some of the others. I'll let you all know when I get further. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hello,
PR874 - from Chris Carroll with a few properties implemented around routes
While the properties were added, they are not actually used for anything,
this looks bogus.
The tests basically show that setting a boolean property back and forth is
set, but likely what needs to be tested is the other methods it affects.
The point of these properties is to alter the behavior of the route
collection.
PR1163 - from AerisG222 which includes a few changes around Unvalidated
parameters and some other bits
This patch is poisoned.
There were a couple of elements that looked very suspicious, like this bit
(which also, does not follow the Mono coding guidelines):
int? _minRequiredPasswordLength;
int? _minRequiredNonAlphanumericCharacters;
string _passwordStrengthRegularExpression;
readonly string _minRequiredPasswordLengthError = {0} must
have at
least {1} characters;
readonly string _minNonAlphanumericCharactersError = {0} must
have
at least {1} special characters;
readonly string _passwordStrengthError = {0} is weak;
What are the chances of getting every internal method name to match the one
in .NET I asked myself? Close to zero. So this was clearly decompiled
and submitted.
Rejected. Someone *else* that has not worked on that code will have to
rewrite this, it is unacceptable to have people contribute decompiled code.
PR1349 - From me regarding MachineKey.Protect methods
Added a comment, looks like it could go in, but we need tests for the
Unprotect path.
And I would like those to be tested against Windows as well.
PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work, just
the interface)
Simple, merged.
PR1354 - From me regarding Request.Abort
Simple, merged.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Miguel,
I can not apologize enough for the issue you point out in regards to the
poisoned patch, I had no idea it was sourced from MS. I have been a big
mono fan since 2003, and certainly was not trying to jeopardize mono. As I
identified in my commit message, I found that from another repo on github
when I was trying to see if anyone had already implemented this (similar to
how I found PR874 which was a pre-requisite), though will never do that
again.
Are the files outside of the files listed in the other repo acceptable
(everything except MembershipPasswordAttribute.cs)?
Sorry,
Mike
On Mon, Oct 20, 2014 at 10:06 AM, Miguel de Icaza mig...@xamarin.com
wrote:
Hello,
PR874 - from Chris Carroll with a few properties implemented around routes
While the properties were added, they are not actually used for anything,
this looks bogus.
The tests basically show that setting a boolean property back and forth is
set, but likely what needs to be tested is the other methods it affects.
The point of these properties is to alter the behavior of the route
collection.
PR1163 - from AerisG222 which includes a few changes around Unvalidated
parameters and some other bits
This patch is poisoned.
There were a couple of elements that looked very suspicious, like this bit
(which also, does not follow the Mono coding guidelines):
int? _minRequiredPasswordLength;
int? _minRequiredNonAlphanumericCharacters;
string _passwordStrengthRegularExpression;
readonly string _minRequiredPasswordLengthError = {0} must
have at least {1} characters;
readonly string _minNonAlphanumericCharactersError = {0} must
have at least {1} special characters;
readonly string _passwordStrengthError = {0} is weak;
What are the chances of getting every internal method name to match the
one in .NET I asked myself? Close to zero. So this was clearly
decompiled and submitted.
Rejected. Someone *else* that has not worked on that code will have to
rewrite this, it is unacceptable to have people contribute decompiled code.
PR1349 - From me regarding MachineKey.Protect methods
Added a comment, looks like it could go in, but we need tests for the
Unprotect path.
And I would like those to be tested against Windows as well.
PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work,
just the interface)
Simple, merged.
PR1354 - From me regarding Request.Abort
Simple, merged.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hey Mike,
I would just submit a new pull request purely with code that you wrote,
excluding any third party code.
As for the WebRoute, like I mentioned, while it adds the properties, it
looks broken, the properties *should* do something, currently they dont.
On Mon, Oct 20, 2014 at 12:32 PM, Mike Morano mmor...@mikeandwan.us wrote:
Miguel,
I can not apologize enough for the issue you point out in regards to the
poisoned patch, I had no idea it was sourced from MS. I have been a big
mono fan since 2003, and certainly was not trying to jeopardize mono. As I
identified in my commit message, I found that from another repo on github
when I was trying to see if anyone had already implemented this (similar to
how I found PR874 which was a pre-requisite), though will never do that
again.
Are the files outside of the files listed in the other repo acceptable
(everything except MembershipPasswordAttribute.cs)?
Sorry,
Mike
On Mon, Oct 20, 2014 at 10:06 AM, Miguel de Icaza mig...@xamarin.com
wrote:
Hello,
PR874 - from Chris Carroll with a few properties implemented around routes
While the properties were added, they are not actually used for anything,
this looks bogus.
The tests basically show that setting a boolean property back and forth
is set, but likely what needs to be tested is the other methods it affects.
The point of these properties is to alter the behavior of the route
collection.
PR1163 - from AerisG222 which includes a few changes around Unvalidated
parameters and some other bits
This patch is poisoned.
There were a couple of elements that looked very suspicious, like this
bit (which also, does not follow the Mono coding guidelines):
int? _minRequiredPasswordLength;
int? _minRequiredNonAlphanumericCharacters;
string _passwordStrengthRegularExpression;
readonly string _minRequiredPasswordLengthError = {0} must
have at least {1} characters;
readonly string _minNonAlphanumericCharactersError = {0} must
have at least {1} special characters;
readonly string _passwordStrengthError = {0} is weak;
What are the chances of getting every internal method name to match the
one in .NET I asked myself? Close to zero. So this was clearly
decompiled and submitted.
Rejected. Someone *else* that has not worked on that code will have to
rewrite this, it is unacceptable to have people contribute decompiled code.
PR1349 - From me regarding MachineKey.Protect methods
Added a comment, looks like it could go in, but we need tests for the
Unprotect path.
And I would like those to be tested against Windows as well.
PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work,
just the interface)
Simple, merged.
PR1354 - From me regarding Request.Abort
Simple, merged.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
Hi Miguel,
I did look at the Membership stuff, but it looked to me that the names
made sense, therefore didn't think it was decompiled.
I haven't actually looked at that much so I'll implement it this week.
@Mike, mail me when you're done if you want and I'll review it.
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.
Thanks for looking at these Miguel.
Martin
On 20 Oct 2014 19:20, Miguel de Icaza mig...@xamarin.com wrote:
Hey Mike,
I would just submit a new pull request purely with code that you wrote,
excluding any third party code.
As for the WebRoute, like I mentioned, while it adds the properties, it
looks broken, the properties *should* do something, currently they dont.
On Mon, Oct 20, 2014 at 12:32 PM, Mike Morano mmor...@mikeandwan.us
wrote:
Miguel,
I can not apologize enough for the issue you point out in regards to the
poisoned patch, I had no idea it was sourced from MS. I have been a big
mono fan since 2003, and certainly was not trying to jeopardize mono. As I
identified in my commit message, I found that from another repo on github
when I was trying to see if anyone had already implemented this (similar to
how I found PR874 which was a pre-requisite), though will never do that
again.
Are the files outside of the files listed in the other repo acceptable
(everything except MembershipPasswordAttribute.cs)?
Sorry,
Mike
On Mon, Oct 20, 2014 at 10:06 AM, Miguel de Icaza mig...@xamarin.com
wrote:
Hello,
PR874 - from Chris Carroll with a few properties implemented around
routes
While the properties were added, they are not actually used for
anything, this looks bogus.
The tests basically show that setting a boolean property back and forth
is set, but likely what needs to be tested is the other methods it affects.
The point of these properties is to alter the behavior of the route
collection.
PR1163 - from AerisG222 which includes a few changes around Unvalidated
parameters and some other bits
This patch is poisoned.
There were a couple of elements that looked very suspicious, like this
bit (which also, does not follow the Mono coding guidelines):
int? _minRequiredPasswordLength;
int? _minRequiredNonAlphanumericCharacters;
string _passwordStrengthRegularExpression;
readonly string _minRequiredPasswordLengthError = {0} must
have at least {1} characters;
readonly string _minNonAlphanumericCharactersError = {0} must
have at least {1} special characters;
readonly string _passwordStrengthError = {0} is weak;
What are the chances of getting every internal method name to match the
one in .NET I asked myself? Close to zero. So this was clearly
decompiled and submitted.
Rejected. Someone *else* that has not worked on that code will have to
rewrite this, it is unacceptable to have people contribute decompiled code.
PR1349 - From me regarding MachineKey.Protect methods
Added a comment, looks like it could go in, but we need tests for the
Unprotect path.
And I would like those to be tested against Windows as well.
PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work,
just the interface)
Simple, merged.
PR1354 - From me regarding Request.Abort
Simple, merged.
Miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] State of aspnetwebstack on mono
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 mig...@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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
