Hi Marek, I guess the misunderstanding is coming in the word "trivial". If it was truly trivial I would just do it. But what may seem trivial to you, seems like climbing a mountain to me. In ASP.NET from Microsoft there is a lot native invoke calls that are made to get the transfer request working with the underlying server. And I don't know what these are for XPS and mod_mono, or even how to switch between the different servers or if even I have to specify each server individually. My reluctance to jump in head first is that I don't know what I would be getting myself in to.
Also you probably haven't heard much about these API's because they are closer to the iron than most ASP.NET developers get. The only reason I use them is because I have to be as close to the server as possible to get my rewriter to work like mod_rewrite. And the reason I want to get them implemented is because I have been getting many requests from developers who use XPS to do development and mod_mono for production, and the XPS users want to also have my rewriter mimic the mod_rewrite stuff for they see in the production environment. If you give me a couple steps of what you think trivial would mean, I am willing to take a whack at it. But I really have no idea where to start, because my understanding of the inner workings of Mono ASP.NET is not very deep. I hope you understand, that I am willing to put the work in, I just have no idea where to start. And I have a feeling that my knowledge of Microsoft ASP.NET is clouding my understanding of Mom ASP.NET. Thanks, Nick On Thu, Sep 24, 2009 at 4:20 PM, Marek Habersack <gren...@twistedcode.net>wrote: > Nick Berardi wrote: > >> Hi Marek, >> > Hey Nick, > > >> It is ultimately up to the team to apply or not apply the patch. So I >> support whatever they choose is best for the Mono project. >> > Well... I'm part of the team... and in charge of ASP.NET... :) > > However I see no reason to wait to add these stub method in place. >> Because currently any application that relies on either of these API's, get >> ugly exceptions like this: >> >> Stack Trace: System.MissingMethodException: Method not found: >> 'System.Web.HttpServerUtility.Trans >> ferRequest'. >> at System.Web.HttpApplication+<>c__CompilerGenerated1.MoveNext () >> [0x00000] >> at System.Web.HttpApplication+<>c__CompilerGenerated2.MoveNext () >> [0x00000] >> at System.Web.HttpApplication.Tick () [0x00000] >> >> So there is not even a way to gracefully handle the exception from with in >> the application. >> > I realize that, but I would really prefer to accept a patch which does > implement the API correctly. > > And there are many ASP.NET <http://ASP.NET> applications, mine is one of >> them, out there now that check to see if they are running on the Integrated >> Pipeline or not. And handle things differently based on this flag. >> > Your report is actually the first one we got regarding the issue, so I'm > not sure if it's that common (at least among apps running on Mono) > > But by leaving out these stub API's the Mono project is essentially >> forbidding any application that references these API's from running on their >> software, even if the application fully supports .NET 2.0 pre and post SP2. >> (which is when they were introduced) At the very least these API's should >> be marked with MonoTODOAttribute and committed so that applications that >> want to work around API's not currently implemented in Mono can do so. >> > Frankly, I don't understand your resistance to implementing the transfer > API - what are the technical reasons for not doing it? From MSDN docs it > seems it should be pretty simple to implement, why not just do it (I can't > do it right now as I'm busy with other things atm) and commit the full > support? > > All that I am really asking for is a graceful way to handle support for >> Mono with in my application. Currently I can't even support Mono because I >> get a ton of runtime errors about Missing Methods. At least if the stubs >> where in place, I could work around them, but setting a flag in the >> Web.config or searching for something Mono specific in the runtime. >> > I understand the issue, but it's not very hard to patch your copy of Mono, > recompile and copy just the System.Web.dll assembly to your server. > Alternatively you can just introduce an #if in your code to skip that part > when compiling for Mono. Adding stubbed APIs just before 2.6 is to be > branched is not acceptable IMO and should be the very last resort. > > best regards, > > marek > > Nick >> >> On Thu, Sep 24, 2009 at 2:32 PM, Marek Habersack >> <gren...@twistedcode.net<mailto: >> gren...@twistedcode.net>> wrote: >> >> Nick Berardi wrote: >> >> Hi Marek, >> >> Hello, >> >> I am a little hesitant to to implement this for Mono for the >> following reasons. >> /Number 1/ is the description Microsoft provides for it >> "Gets a value that indicates whether the current application is >> running *in the integrated-pipeline mode of IIS 7.0*." >> >> You can ignore this particular part of the description. As I wrote >> in the previous mail, Mono effectively implements what was >> introduced in IIS 7 and termed "integrated-pipeline mode". Therefore >> it's perfectly fine to implement that in Mono. >> >> /Number 2/ is that the key feature of the integrated-pipeline is >> that outside processes still run through the .NET framework >> first, such as, you can use IHttpModules to process >> request/response data from for example PHP code, I don't know >> enough about Mono/XPS to get something like this working. >> >> XSP doesn't implement that and it doesn't have to, it's just a >> development server. Apache, otoh, provides a full filter/pipelining >> infrastructure with which Mono should work just fine (i.e. you can >> define a module to act as a filter and pass its output to another >> module, etc etc) - I have never tried it, but I mod_mono is no >> different to other modules and it should work just fine. It will NOT >> use IHttpModules, of course, because Apache (being IIS counterpart) >> doesn't have that notion, but functionality is exactly the same. We >> might (just might) approach it at some point and extend mod_mono (or >> create an auxiliary module) in the way which will expose >> IHttpModules etc to Apache, but it's definitely not a priority. >> Mono/mod_mono/XSP is much more flexible than .NET + IIS combo, so >> the elements are more losely coupled but they can be arranged to >> work in the same way as IIS. >> >> >> Many developers use the UsingIntegratedPipeline flag to indicate >> if they are running in IIS 7.0 integrated mode or the older >> "classic mode." I really feel that getting both the "classic >> mode" and integrated mode working under Mono would be a huge >> undertaking, especially in regards to some of the built in >> support for their Rewriter Module that they have >> >> We don't have to aim for 1:1 compatibility in this regard - Apache >> has rewriter modules which can easily replace their IIS counterpart, >> and we do not aim to make Mono a replacement for .NET under IIS. >> Therefore, if a developer deploys an ASP.NET <http://ASP.NET> >> >> application to Mono/Apache/mod_mono they should be aware of >> architectural differences. But, again, that doesn't stop us from >> supporting the APIs (and other "integrated pipeline" ones) for the >> benefit of applications and developers. >> >> added in to the .NET 2.0 SP2 framework. Also because a number >> of sub-routines change in ASP.NET <http://ASP.NET> >> <http://ASP.NET> depending on this one flag. >> >> Nothing prevents us from defaulting to false for >> UsingIntegratedPipeline and providing a mechanism to turn it on (by >> e.g. providing a MonoServerEnableIntegratedPipeline AppSettings >> entry - we already have a number of them, documented in the xsp and >> mod_mono manpages) >> >> >> I would like to commit the patch as is for now, to complete some >> of the missing parts of the API, and I will look in to what it >> will take to really get this supported in the Mono framework. >> >> What the patch generally does is provide stub implementations of the >> API (with, perhaps, the exception of the property) which we don't >> generally like to do, especially if the functionality is relatively >> easy to implement as in this case. I'd rather vote on not commiting >> the patch in this state, but rather wait till you (or somebody else, >> perhaps even me) provides full support for the APIs together with >> tests etc. >> >> best regards, >> >> marek >> >> >> Thanks, >> Nick >> >> P.S. I know of a dozen places where having integrated mode >> turned on will allow you to do things that you weren't allowed >> to before. For example when integrated mode is enabled you can >> directly add headers using /HttpRequest.Headers.Add/, instead of >> getting an exception thrown. >> >> You can do it just fine with Mono as well. As said before, we treat >> Mono as working in the integrated pipeline mode. There's nothing >> wrong in not having full support for all of its features right away, >> we can implement it step by step. >> >> >> >> On Thu, Sep 24, 2009 at 4:56 AM, Marek Habersack >> <gren...@twistedcode.net <mailto:gren...@twistedcode.net> >> <mailto:gren...@twistedcode.net >> >> <mailto:gren...@twistedcode.net>>> wrote: >> >> Nick Berardi wrote: >> >> Hello group, >> >> Hello, >> >> >> This is my first time submitting a patch. So if anything >> I have >> done is out of the norm, please let me know so that I can >> correct it. There are two API's related to IIS >> 7.0 that were added as part >> of the .NET 2.0 SP2 release that I need supported for an >> Open >> Source project that I work on >> (http://urlrewriter.codeplex.com). >> ( >> http://urlrewriter.codeplex.com/WorkItem/View.aspx?WorkItemId=7187) >> >> The patch that I am submitting is for the following APIs: >> >> * HttpRuntime.UsingIntegratedPipeline { get; } >> * >> >> HttpServerUtility.TransferRequest(string,[bool],[string],[NameValueCollection]) >> >> Since both of these API's are IIS 7.0+ specific and that >> they >> require the Integrated Pipeline to function. I have the >> first >> property UsingIntegratedPipeline always returning false, >> since >> it is currently impossible to put Mono in to the core of IIS >> 7.0, so Integrated Pipeline >> >> Technically Mono has always been using what IIS 7 calls >> "integrated >> pipeline" - there are no plans to make Mono run in the IIS >> core, so >> we should try to implement whatever functionality makes sense in >> Mono context without looking whether or not it works in this >> or that >> IIS mode. I'd say UsingIntegratedPipeline could return 'true' >> without harm. >> >> >> can't currently be supported. So I hoped to achieve the 2nd >> best option of API completeness. The second method >> TransferRequest relies on the Integrated Pipeline so again >> it >> will not be supported. So I have the method just >> throwing the >> publically available exceptions shows on MSDN. This second >> method will always throw PlatformNotSupported, for API >> completeness with the .NET 2.0 SP2 framework. >> >> This method, as well, can be implemented to perform its >> function on >> Mono just fine. If you feel like giving it a try, I'd welcome >> a new >> patch which implements it. If not, I will accept the patch as >> it is >> now and implement the API fully at some point. >> >> >> Please let me know what the next steps are or if there is >> anything that I need to change in order to get this patch >> moved >> into production. >> >> Thanks, >> Nick >> >> >> best regards, >> >> marek >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> <mailto: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