[Mono-dev] Building XSP/mod_mono from Git
Can anyone tell me if the mod_mono on github is supposed to working with Apache? To be a bit clearer, I've always run mono with the packages for ubuntu, but wanted to try out 3.0 so I've set about building from source. the current sources all build perfectly fine, however, there appears to be some problems running it. The mono installation works fine, but the issue is that mod-mono-server is failing to start when triggered from apache. I've done a little debugging and it seems that the following commandline is not working at all. /usr/bin/mod-mono-server4 --filename="/tmp/mod_mono_server_test" --applications="/test:/var/www/test/" Looking at the apache logs, this looks like the commandline that is being passed in, so I ran it in terminal, with the same user and got the following error. mod-mono-server4 Handling exception type ArgumentException Message is Should be something like [[hostname:]port:]VPath:realpath IsTerminating is set to True System.ArgumentException: Should be something like [[hostname:]port:]VPath:realpath at Mono.WebServer.ApplicationServer.AddApplicationsFromCommandLine (System.String applications) [0x0] in :0 at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer:AddApplicationsFromCommandLine (string) at Mono.WebServer.Apache.Server.Rea I did a little delving into the code to add some debugging, and in the Mono.WebServer.ApplicationServer.AddApplicationsFromCommandLine method, the string that's passed in just contains "applications", not the string passed in on the commandline. I'm thinking that this could be the issue, but I'm not sure. Can anyone a bit more knowledge on the XSP package shed some light on this? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building Mod_mono from Git
Can anyone tell me if the mod_mono on github is supposed to working with Apache? To be a bit clearer, I've always run mono with the packages for ubuntu, but wanted to try out 3.0 so I've set about building from source. the current sources all build perfectly fine, however, there appears to be some problems running it. The mono installation works fine, but the issue is that mod-mono-server is failing to start when triggered from apache. I've done a little debugging and it seems that the following commandline is not working at all. /usr/bin/mod-mono-server4 --filename="/tmp/mod_mono_server_test" --applications="/test:/var/www/test/" Looking at the apache logs, this looks like the commandline that is being passed in, so I ran it in terminal, with the same user and got the following error. mod-mono-server4 Handling exception type ArgumentException Message is Should be something like [[hostname:]port:]VPath:realpath IsTerminating is set to True System.ArgumentException: Should be something like [[hostname:]port:]VPath:realpath at Mono.WebServer.ApplicationServer.AddApplicationsFromCommandLine (System.String applications) [0x0] in :0 at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer:AddApplicationsFromCommandLine (string) at Mono.WebServer.Apache.Server.Rea I did a little delving into the code to add some debugging, and in the Mono.WebServer.ApplicationServer.AddApplicationsFromCommandLine method, the string that's passed in just contains "applications", not the string passed in on the commandline. I'm thinking that this could be the issue, but I'm not sure. Can anyone a bit more knowledge on the XSP package shed some light on this? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] New Property on System.Web.Hosting.HostingEnvironment
I'm not sure of the best place to raise this, it's not a bug really, but a property that seems to be new to the framework. System.Web.Hosting.HostingEnvironment has the property "InClientBuildManager" and it looks like it was added in 3.5. The reason I think it's an important thing to get added soon is the fact that WebActivatorEx uses it, and it's part of just about every NuGet package for MVC. So if people want to move over to mono, this could be a major issue. On the plus side, WebActivatorEx handles it well, so you just get an exception on first run. http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager(v=vs.100).aspx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] New Property on System.Web.Hosting.HostingEnvironment
I didn't just plan on waiting, I've worked around it. The reason for the mail was to highlight it so that if anyone was working on that section they were aware that it could do with being added. It's something pretty fundamental to the building MVC sites, so if promoting mono to the wider MVC audience is important, it's needed. Although I have no idea how I would go about implementing the property, I will give it a go. I have never contributed code to n open source, and given the size of the mono code base, it's quite a daunting prospect. To be clear I'm not under the illusion that I can ask and it will be done. On Aug 7, 2013 12:02 PM, "Atsushi Eno" wrote: > From your message I assume you think you can wait for someone to implement > it, but there is no one working on ASP.NET stack. So you are the most > likely one who understand what it is and who is most able to implement it. > > Atsushi Eno > > Martin Thwaites wrote: > >> I'm not sure of the best place to raise this, it's not a bug really, but >> a property that seems to be new to the framework. >> >> System.Web.Hosting.**HostingEnvironment has the property >> "InClientBuildManager" and it looks like it was added in 3.5. >> >> The reason I think it's an important thing to get added soon is the fact >> that WebActivatorEx uses it, and it's part of just about every NuGet >> package for MVC. So if people want to move over to mono, this could be a >> major issue. >> >> On the plus side, WebActivatorEx handles it well, so you just get an >> exception on first run. >> >> http://msdn.microsoft.com/en-**us/library/system.web.hosting.** >> hostingenvironment.**inclientbuildmanager(v=vs.100)**.aspx<http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager(v=vs.100).aspx>< >> http://msdn.microsoft.com/en-**us/library/system.web.hosting.** >> hostingenvironment.**inclientbuildmanager%28v=vs.**100%29.aspx<http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager%28v=vs.100%29.aspx> >> > >> >> >> __**_ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.**com >> http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<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-dev] adding property to mono
I'm looking for bit of advice on adding something to mono. Specifically, it's a property in the hosting class called InClientBuildManager, there are a few more too, but this is the one I think should be implemented first. My question is, adding the property isn't a problem, but where would I set such a thing? I'm thinking that it would be in xsp modules etc. I'm guessing that I shouldn't just leave it at it's default? Maybe someone who's working on the XSP codebase could give me some advice? my point me to some classes to look at? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Request for status of Entity framework on Mono
I'm starting a new project from scratch soon, and I'm selecting some components. I do everything in mono.. you'll be pleased to hear ;) For ORM, I'm looking to utilise EntityFramework, so I'm wondering where the development is at, is anyone working on it, etc. I don't think I'll be using any advanced features, just the basics. So, are the basics in enough of a usable state to put into a production application? I'm not seeing any stabilisation branches/tags in the repository, so can I assume that it's still in flux and should be avoided for the timebeing? I'll obviously give it a go and see, but just wondering if anyone has any experiences? Thanks in advance. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Request for status of Entity framework on Mono
Thanks Daniel. I'll have a look at those, but Ideally I wanted to look at Entity due to some work projects that are currently using it (pure windows .NET and VS). The plan was to get the basics down in some hobby apps. I'm currently using NHibernate, and it works well, entity does look like fun to play with... I'm a very "ooo shiny" kinda guy. I did see a big merge happen in the last few days by Marek, so I was hoping that might be the start of something... Thanks, Martin On 18 August 2013 23:45, Daniel Lo Nigro wrote: > There's no official release of Entity Framework 6 yet, the latest release > is the first beta release. Additionally, I don't think all the supporting > architecture is fully working in Mono yet. You could try it and see, > although I'd use Entity Framework from NuGet as the one bundled with Mono > is out of date. > > If you only need basic features, I'd suggest looking at a micro ORM like > ServiceStack ORMLite, Dapper, or Massive. These are all very basic facades > over raw ADO.NET, usually providing only basic ORM. I use ORMLite with > Mono and it works quite well. > > > On Mon, Aug 19, 2013 at 7:16 AM, Martin Thwaites > wrote: > >> I'm starting a new project from scratch soon, and I'm selecting some >> components. I do everything in mono.. you'll be pleased to hear ;) >> >> For ORM, I'm looking to utilise EntityFramework, so I'm wondering where >> the development is at, is anyone working on it, etc. >> >> I don't think I'll be using any advanced features, just the basics. So, >> are the basics in enough of a usable state to put into a production >> application? >> >> I'm not seeing any stabilisation branches/tags in the repository, so can >> I assume that it's still in flux and should be avoided for the timebeing? >> >> I'll obviously give it a go and see, but just wondering if anyone has any >> experiences? >> >> Thanks in advance. >> 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] Request for status of Entity framework on Mono
That's great news, but I can't purchase the licence. It's promising news that it works with that, as it's a sign that I may be able to get it working with Npgsql. On 20 August 2013 21:33, jonat...@mugginsoft.com wrote: > Hi > > I have done some experimenting with the latest MS Entity 6 beta and the > Devart SQLite data provider. > I was able to query quite a substantial pre-existing data set when running > on Mono. > So it is doable. > > Jonathan > > On 19 Aug 2013, at 00:17, Martin Thwaites > wrote: > > Thanks Daniel. > > I'll have a look at those, but Ideally I wanted to look at Entity due to > some work projects that are currently using it (pure windows .NET and VS). > The plan was to get the basics down in some hobby apps. > > I'm currently using NHibernate, and it works well, entity does look like > fun to play with... I'm a very "ooo shiny" kinda guy. > > I did see a big merge happen in the last few days by Marek, so I was > hoping that might be the start of something... > > Thanks, > Martin > > On 18 August 2013 23:45, Daniel Lo Nigro wrote: > >> There's no official release of Entity Framework 6 yet, the latest release >> is the first beta release. Additionally, I don't think all the supporting >> architecture is fully working in Mono yet. You could try it and see, >> although I'd use Entity Framework from NuGet as the one bundled with Mono >> is out of date. >> >> If you only need basic features, I'd suggest looking at a micro ORM like >> ServiceStack ORMLite, Dapper, or Massive. These are all very basic facades >> over raw ADO.NET <http://ado.net/>, usually providing only basic ORM. I >> use ORMLite with Mono and it works quite well. >> >> >> On Mon, Aug 19, 2013 at 7:16 AM, Martin Thwaites < >> monofo...@my2cents.co.uk> wrote: >> >>> I'm starting a new project from scratch soon, and I'm selecting some >>> components. I do everything in mono.. you'll be pleased to hear ;) >>> >>> For ORM, I'm looking to utilise EntityFramework, so I'm wondering where >>> the development is at, is anyone working on it, etc. >>> >>> I don't think I'll be using any advanced features, just the basics. So, >>> are the basics in enough of a usable state to put into a production >>> application? >>> >>> I'm not seeing any stabilisation branches/tags in the repository, so can >>> I assume that it's still in flux and should be avoided for the timebeing? >>> >>> I'll obviously give it a go and see, but just wondering if anyone has >>> any experiences? >>> >>> Thanks in advance. >>> 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 > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Working out the stable branch/tag
Is there a logic to how I would work out what the latest "Stable" branch is? What I mean by this is the branch that is considered to be "bug fix" only? Basically, I'm trying to workout what is the best source to compile for a production machine as I'm running ubuntu and don't want to stick with the built in packages. Thanks in advance. Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ms .net source updated and license modified
I'll caveat this with "I'm not a legal expert"... Doing a bit of research, according to Wikipedia, it's the most restrictive of the Microsoft Shared Source licences. It seems that it can be used for "Reference use". I'd read this to mean that you cannot reproduce the identical code in mono, but, you could use to work out how it's doing what it does. Is this maybe something that has fallen out of the partnership between Xamarin and Microsoft? something that would allow the Xamarin to better develop their Android/iOS platform? I'd love to hear from Xamarin as I'm sure that their legal department either has an opinion, or helped instigate the change. Anyway, just my 2 cents. Martin On 25 February 2014 18:17, Stephen Shaw wrote: > I'm curious. What does this actually mean for the mono project? > > Cheers, > Stephen > > > On Tue, Feb 25, 2014 at 11:16 AM, Chris Ball wrote: > >> Related, I believe: >> >> >> http://www.hanselman.com/blog/AnnouncingTheNewRoslynpoweredNETFrameworkReferenceSource.aspx >> >> Sent from my iPhone >> >> > On 25.02.2014, at 18:50, "\"Andrés G. Aragoneses\"" >> wrote: >> > >> >> On 25/02/14 18:11, theUser BL wrote: >> >> »Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat >> Microsoft >> >> auch die Lizenzbestimmungen klarer gefasst. Denn bisher mussten >> >> beispielsweise die Entwickler von Open Source-Klonen aufpassen, dass >> sie >> >> nur Erkenntnisse aus dem Reverse Engineering verwenden und nicht aus >> >> dem Studium des originalen Quellcodes. Denn in vielen Fällen würde dann >> >> die Gefahr drohen, dass man sich verschiedener Rechteverletzungen >> >> schuldig macht. Die Microsoft Reference Source License wurde daher nun >> >> so angepasst, dass beispielsweise die Entwickler des Mono-Teams >> >> problemlos die .Net-Sourcen anschauen und das Framework dann unter >> Linux >> >> klonen können. « >> > >> > GoogleTranslate output is: >> > >> > "To make the work with the source code even easier, Microsoft has >> > also the license terms clarified. Because so far had >> > For example, the developers of open source clones careful that they >> > only use insights from the reverse engineering and not from >> > the study of the original source code. Because in many cases would then >> > the danger threatening that one different in rights violations >> > guilty. The Microsoft Reference Source License was therefore now >> > adapted so that for example, the developer of the mono-teams >> > easily see the. Net sources and the framework then in Linux >> > can clone. " >> > >> > If this translation is (kind of) correct, it still is very confusing >> > because that license (MS-RSL [1]) is not opensource. >> > >> > [1] >> > >> http://en.wikipedia.org/wiki/Shared_source#Microsoft_Reference_Source_License_.28Ms-RSL.29 >> > >> > ___ >> > 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 > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] crn.com: »Sources: Microsoft In Talks To Acquire Mobile App Development Startup Xamarin«
I was actually thinking of posting a question to the list when I saw that article but had the same reservations about the validity. Although it makes sense from a Microsoft perspective (imho) to back Xamarin (through purchase or through funding), I can only wonder whether they would eventually (not initially) focus Xamarin (more than they are now) away for mono functionality that doesn't relate to the mobile. I see this as a problem for the community in terms of generally running things on Mono. For me, I only use Mono for hosting websites, so there is really zero incentive for Microsoft to put money behind that as it would eat into the there server software sales. I think there will always be a benefit to the community from whatever happens with Xamarin. By the fact that making .net compiled code work on Android, will have knock on affects to making it work on linux in general, so I have confident that those things will make it into the community. That said, as someone else has said, I trust in Miguel's integrity. From his past actions, he has shown that he is behind mono, and open source in general. In short, I think it could be a good thing, and I trust that when something is agreed, Miguel will communicate with the community as he has always done. Only time will tell. Martin On 20 March 2014 13:59, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > > boun...@lists.ximian.com] On Behalf Of Ian Norton > > > > whaat!? > > article looks far from clear though. does this mean monodevelop is going > to > > quietly die? or a license change? :/ > > LOL, no. :-) > > Here's what it comes down to: Microsoft cannot deny the fact that they've > been getting thoroughly spanked in the mobile device market. They want to > be industry leaders and not following the lead of Apple and Google. They > have moved past the denial phase of several years ago, denying the > existence or relevance of linux or apple, and now they're motivated to > adapt to the times and roll with it. Which means they want everybody > fricking using .NET and not java or objective C. They recognize that > embracing and supporting mono is a good business move. > ___ > 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-dev] DynamicModuleHelper and HttpApplication RegisterModule methods
First, I'm not asking for something to be implemented, I'm asking for help implementing it as I think there will be more and I'm endeavoring to implement them all if possible. I'm having a play with trying to get the MVC5 boilerplate working on mono and one of the libraries (Microsoft.Owin) uses the new HttpApplication.RegisterModule method, which is not yet present in the current master branch. Looking at the descriptions on MSDN, there is very little information on what it's supposed to do, but it looks like it just does the same as the method DynamicModuleHelper.RegisterModule... in that it just registers a module at runtime, in memory. So, in light of the above, I have a few questions. 1. Would a pull be accepted if it just copies the implementation from the Microsoft.Web.Infrastructure class in the current mono codebase? Given that the new method is in the HttpApplication class, I would say that it's a valid assumption that it's only Web modules that can be added. 2. If I'm just copying the implementation into System.Web, would it be advisable to edit the Microsoft.Web.Infrastructure class to just forward through to System.Web? 3. What, if any, tests should be created (I'm used to working in an environment with interfaces that could be mocked with Moq). I could do with some information on how to do this, in terms of possibly some examples that are considered good, and locations in the current codebase. 4. Given that this is only available in .NET 4.5, is there some way I should stop it from being accessible on .NET 4.0 (if so, how)? I'm not sure there is an issue with leaving it available on .NET 4.0 other than the mono version has more methods than .NET... References: http://msdn.microsoft.com/en-us/library/microsoft.web.infrastructure.dynamicmodulehelper.dynamicmoduleutility.registermodule%28v=vs.111%29.aspx http://msdn.microsoft.com/en-us/library/system.web.httpapplication.registermodule%28v=vs.110%29.aspx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DynamicModuleHelper and HttpApplication RegisterModule methods
I've just found that Matthid on Github has done a far better implementation in pull 888 so I won't bother... Who needs to look at it before it's merged? On 23 April 2014 19:56, Martin Thwaites wrote: > First, I'm not asking for something to be implemented, I'm asking for help > implementing it as I think there will be more and I'm endeavoring to > implement them all if possible. > > I'm having a play with trying to get the MVC5 boilerplate working on mono > and one of the libraries (Microsoft.Owin) uses the new > HttpApplication.RegisterModule method, which is not yet present in the > current master branch. > > Looking at the descriptions on MSDN, there is very little information on > what it's supposed to do, but it looks like it just does the same as the > method DynamicModuleHelper.RegisterModule... in that it just registers a > module at runtime, in memory. > > So, in light of the above, I have a few questions. > 1. Would a pull be accepted if it just copies the implementation from the > Microsoft.Web.Infrastructure class in the current mono codebase? Given > that the new method is in the HttpApplication class, I would say that it's > a valid assumption that it's only Web modules that can be added. > 2. If I'm just copying the implementation into System.Web, would it be > advisable to edit the Microsoft.Web.Infrastructure class to just forward > through to System.Web? > 3. What, if any, tests should be created (I'm used to working in an > environment with interfaces that could be mocked with Moq). I could do > with some information on how to do this, in terms of possibly some examples > that are considered good, and locations in the current codebase. > 4. Given that this is only available in .NET 4.5, is there some way I > should stop it from being accessible on .NET 4.0 (if so, how)? I'm not sure > there is an issue with leaving it available on .NET 4.0 other than the mono > version has more methods than .NET... > > References: > > > http://msdn.microsoft.com/en-us/library/microsoft.web.infrastructure.dynamicmodulehelper.dynamicmoduleutility.registermodule%28v=vs.111%29.aspx > > http://msdn.microsoft.com/en-us/library/system.web.httpapplication.registermodule%28v=vs.110%29.aspx > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compiling mono on windows for developing (not running)
I want to start making some changes to mono, but I want to do so on Windows, using Visual Studio (no offense meant to Xamarin Studio or MonoDevelop, I just like Resharper... I've been going over the documentation on building mono with visual studio, and it seems old and does seem to work for me. It also seems focused on getting a mono install that you can use, whereas what I'm looking for is to be able to contribute. So there are a couple of questions, should I be able to contribute to mono using Visual Studio? is the mono_4_5.sln supposed to work? So, can anyone help me out with getting a solution in VS that I can build, and run the tests for? As a side question, what is the tool that the rest of you use to develop mono? do you develop on windows or on Linux? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling mono on windows for developing (not running)
Thanks Edward, I'll have to wait until someone puts a guide together about developing on windows as I am seriously out of my depth. I've spent about 2 evenings so far trying to get mono to build in cygwin, but coming up with various errors that googling isn't solving. It's disappointing that it appears there is little appetite for getting extra people to help with mono who don't own a mac (the whole reason I host on mono is because I'm skint so no chance of me affording a decent mac, even if I wasn't an apple hater). I'm actually starting to think that it may be worth looking at alternatives due to the fact there isn't really any interest in getting Asp.Net side of things up and running. Not saying Asp.Net is dead as < MVC4 is working fine, but it does appear to be being put to pasture after the creation of Xamarin. Lots of pulls either taking a long time to merge, or just being ignored. Anyway, rant over, thanks for the response. Thanks Martin On 26 Apr 2014 02:05, "Edward Ned Harvey (mono)" < edward.harvey.m...@clevertrove.com> wrote: > > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > > boun...@lists.ximian.com] On Behalf Of Martin Thwaites > > > > As a side question, what is the tool that the rest of you use to develop > > mono? do you develop on windows or on Linux? > > I spent some time on this not long ago, and it's rather frequent that we > hear questions from people who want to develop mono sources, having trouble > getting it to build, or attaching debugger to it, etc. You *might* not be > far off, getting it to build in VS, but for a while now, there's been a > steady stream of people (including myself) who started by asking the same > question, and before too long, found it easier to adapt to the system > instead of the other way around. I know I didn't try too hard, and I don't > know if anyone else has. So it *might* be easy-ish, or it might be an > insurmountable obstacle. > > There has been some talk about improving the build process, making it > easier to adopt new developers, and it seems that Miguel is diving into it, > but more for the purpose of untangling some mess and making the process > more reliable, less for the sake of making it easier for new devs. Lots of > times, improvements come out of efforts like those, as a positive side > effect, but it's yet to be seen. > > I will say: Getting monodevelop (xamarin studio) to work on windows is > trivial. But in order to do some good debugging, you'll want to build the > sources too. And as you're discovering, that's a little tougher on windows. > > Getting XS on mac is trivial. Installing mono MDK on mac is trivial. > Building mono for the first time required a little bit of prep (XCode, > command line tools, homebrew, autoconf, automake, libtool). But after > that, building on the mac and developing in XS is quite nice. (Sorry, no > resharper... XS isn't as good as VS, but XS is quite good nonetheless.) > > If you don't have a mac, I'll encourage at least a *little* bit of effort > getting windows to build - via cygwin, not the sln. > > But unfortunately, you're going to have to lower your expectations. I > find, even when I have everything working, there are lots of shortcomings > in debugging. Like... I create some class or call some method. I step > into. And the debugger goes to outerspace. Or I step into, and when I get > there, all the code is grayed out and I cannot inspect any variables, but > if I'm lucky, I can at least continue stepping. Sometimes can't. And > various little weird behaviors like that. And every time you make a > change, you have to "make" again. There goes 5min to 30min, depending on > what you changed. > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling mono on windows for developing (not running)
I actually run Ubuntu desktop on my main laptop and the server edition on all my servers, and have done for years, I only develop my applications in VS as (at least from an ASP.NET standpoint) it's far superior to XS and MD (granted I haven't tried XS/MD for a year or so). I completely agree your comments about the 2.10.8 version that's distributed with ubuntu (don't know about other distros), that's a tad old. All the sites are run are using 3.x compiled from source. I've been trying to get mono to compile in MD (4.3.3) on ubuntu 14.04 and not having much luck with that either. If you know of a tutorial for getting that up and running I would grateful as that's a compromise. I want to actually contribute rather than just use it. Specifically, I want to try and help get MVC5 running smoothly on mono so i don't need to look at different hosting options, or, god forbid, change to java. I also want to give back rather than just taking! I think that a lot more people would be willing to make minor enhancements to the framework if it learning curve wasn't so large. For minor stuff, it is quite a bit of a task to make a change and test it. That would benefit both Xamarin and the wider mono community. I'd love to help out with that side of it, but I'm completely out of my depth at that side. What I want to help with is the Class Libraries side, and getting them fully functional for ASP.NET. On 26 April 2014 14:03, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: mar...@my2cents.co.uk [mailto:mar...@my2cents.co.uk] On Behalf > > Of Martin Thwaites > > > > I'll have to wait until someone puts a guide together about developing on > > windows as I am seriously out of my depth. I've spent about 2 evenings > so > > far trying to get mono to build in cygwin, but coming up with various > errors > > that googling isn't solving. > > It's disappointing that it appears there is little appetite for getting > extra > > people to help with mono who don't own a mac > > There's nothing special about mac, except that it happens to be the most > popular platform - You definitely don't need one. Of course windows is the > #1 most popular desktop, but people developing on windows usually use VS. > Mac is #2, and XS works well. So, you know... > > Also, if you just want to develop .NET code, and run on mono, you don't > need to build mono. The only reason you need to build it is if (a) you > need a version later than what's available for your OS, or (b) you want to > contribute to (or debug or just step through) the actual mono source. > > If you want to develop the actual mono source, and don't have a mac, then > until somebody puts in the effort to update the windows build instructions, > you should be able to do it in linux. If all you have is windows, you can > certainly build a linux VM. (Using Virtualbox or VMWare Player). I would > recommend ubuntu desktop. > > The one comment I'll make is this: In my experience, the mono that > distributes with the various OSes is archaic. It is best, after building > the linux machine, to build your own mono runtime, and build your own > monodevelop. In my experience, this is usually pretty easy, so don't be > scared. (Unlike lots of other projects, that often have difficulty > building from source, I hardly ever see any build problems with mono, and > even then, there's usually a workaround.) > > I have no knowledge or comments on the ASP.NET side of things. > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DynamicModuleHelper and HttpApplication RegisterModule methods
Thanks Miguel. I'll see if the tests are something I can help out with, but I'm not sure what use I'll be... Thanks, Martin On 2 May 2014 21:39, "Miguel de Icaza" wrote: > I just did a quick review, and added a series of comments. > > Among other things, it is missing tests :-) > > > On Thu, Apr 24, 2014 at 9:51 AM, Martin Thwaites > wrote: > >> I've just found that Matthid on Github has done a far better >> implementation in pull 888 so I won't bother... >> >> Who needs to look at it before it's merged? >> >> >> On 23 April 2014 19:56, Martin Thwaites wrote: >> >>> First, I'm not asking for something to be implemented, I'm asking for >>> help implementing it as I think there will be more and I'm endeavoring to >>> implement them all if possible. >>> >>> I'm having a play with trying to get the MVC5 boilerplate working on >>> mono and one of the libraries (Microsoft.Owin) uses the new >>> HttpApplication.RegisterModule method, which is not yet present in the >>> current master branch. >>> >>> Looking at the descriptions on MSDN, there is very little information on >>> what it's supposed to do, but it looks like it just does the same as the >>> method DynamicModuleHelper.RegisterModule... in that it just registers a >>> module at runtime, in memory. >>> >>> So, in light of the above, I have a few questions. >>> 1. Would a pull be accepted if it just copies the implementation from >>> the Microsoft.Web.Infrastructure class in the current mono codebase? Given >>> that the new method is in the HttpApplication class, I would say that it's >>> a valid assumption that it's only Web modules that can be added. >>> 2. If I'm just copying the implementation into System.Web, would it be >>> advisable to edit the Microsoft.Web.Infrastructure class to just forward >>> through to System.Web? >>> 3. What, if any, tests should be created (I'm used to working in an >>> environment with interfaces that could be mocked with Moq). I could do >>> with some information on how to do this, in terms of possibly some examples >>> that are considered good, and locations in the current codebase. >>> 4. Given that this is only available in .NET 4.5, is there some way I >>> should stop it from being accessible on .NET 4.0 (if so, how)? I'm not sure >>> there is an issue with leaving it available on .NET 4.0 other than the mono >>> version has more methods than .NET... >>> >>> References: >>> >>> >>> http://msdn.microsoft.com/en-us/library/microsoft.web.infrastructure.dynamicmodulehelper.dynamicmoduleutility.registermodule%28v=vs.111%29.aspx >>> >>> http://msdn.microsoft.com/en-us/library/system.web.httpapplication.registermodule%28v=vs.110%29.aspx >>> >> >> >> ___ >> 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] Compiling mono on windows for developing (not running)
Hi Alex, I've been giving your tutorial ago, and I have some things that may be good to add... firstly, I'm building from git, and I checked it out using the visual studio clone. I think this lead to a line endings error, so you need to run the script in a way that uses them properly. I found that if you run it with "bash -x -o igncr autogen.sh --prefix="c:\monoinstall" --with-preview=yes" it seems to do the trick. I've now come across another error that you may be able to help with: === configuring in eglib (/cygdrive/c/Users/Martin/Source/Repos/mono/eglib) configure: WARNING: no configuration information is in eglib === configuring in libgc (/cygdrive/c/Users/Martin/Source/Repos/mono/libgc) configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local' '--host=i686-pc-mingw32' 'host_alias=i686-pc-mingw32' 'CPPFLAGS_FOR_EGLIB=' 'CFLAGS_FOR_EGLIB=' '--disable-embed-check' '--with-libgc-threads=win32' '--enable-win32-dllmain=yes' '--enable-parallel-mark' 'CPPFLAGS_FOR_LIBGC=-DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS -DFD_SETSIZE=1024' 'CFLAGS_FOR_LIBGC= -g -mno-tls-direct-seg-refs -DGC_BUILD -DGC_NOT_DLL' --cache-file=/dev/null --srcdir=. /bin/sh: ./configure: No such file or directory configure: error: ./configure failed for libgc I'm now at a loss. As I've stated before, what I'm looking to do is be able to develop mono (not develop with) in Visual Studio. Maybe the stuff the Miguel is doing will help, but I just had a bit of time so thought I'd give your stuff ago. Thanks, Martin On 5 May 2014 03:52, Alex J Lennon wrote: > > On 05/05/2014 03:44, Konaju Games (Dev) wrote: > > > With Cygwin, there is one change to make to etc/fstab before starting > > a build. You need to add noacl to the cygdrive mount. Without this > > change, any files created by a Win32 process outside of Cygwin will > > result in Cygwin having no permissions to do anything with the files. > > > http://georgik.sinusgear.com/2012/07/14/how-to-fix-incorrect-cygwin-permission-inwindows-7/ > > > > Thanks, I'll have a look and see if that addresses the issue I was > seeing with having /usr/local mounting during the build. > > Regards, Alex > > ___ > 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-dev] Developing Mono
So I've given in, and I'm now looking at using linux (ubuntu 14.04) to try and add some things to mono. I have the same issues with loading the net_4_5.sln file in MD as I do in VS, in that it won't compile. I'm assuming that the solution itself is just broken. The main issue though is I've not found anything that could show me some simple steps to how I should go about building and running tests. I try to read through the pull requests that go on so I see if there is anything of interest to me. I've seen from the comments in these that what I need to do is create a test that passes on .NET, and fails on mono, then fix the code to make the test pass. This seems like a simple concept, however, what steps should I take to do that. What I thought was that I could create a dummy project in visual studio and paste the test in, see if it works, then run it on MD in linux. This doesn't seem like the best approach to me. So my question, what is the generally accepted way to create tests for mono? Thanks in advance Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Developing Mono
Hi Miguel, As always, I'm sure we're all thankful for your work. I'm watching your repeat build thread which I'm assuming is the one you're referring to. Please don't hesitate to ask me if there is anything at all I can do to help move things along. I can do a fair bit with C#, but beyond that, my skills are limited. Thanks again, I'll be giving the other suggestions in this thread ago later (in my copious amount of spare time ;-)) Martin On 14 May 2014 04:36, "Miguel de Icaza" wrote: > Hello Martin, > > The solution files that we have on the tree have not really been tested. > > I am currently working on fixing a few fundamental bugs in our build > system and once I do that, I should be able to get solution files that work > with MonoDevelop or Visual Studio to work. > > Sadly, I have very little time, but I will try to finish it this week. > > Miguel > > > On Tue, May 13, 2014 at 6:55 PM, Martin Thwaites > wrote: > >> So I've given in, and I'm now looking at using linux (ubuntu 14.04) to >> try and add some things to mono. >> >> I have the same issues with loading the net_4_5.sln file in MD as I do in >> VS, in that it won't compile. I'm assuming that the solution itself is >> just broken. >> >> The main issue though is I've not found anything that could show me some >> simple steps to how I should go about building and running tests. >> >> I try to read through the pull requests that go on so I see if there is >> anything of interest to me. I've seen from the comments in these that what >> I need to do is create a test that passes on .NET, and fails on mono, then >> fix the code to make the test pass. This seems like a simple concept, >> however, what steps should I take to do that. >> >> What I thought was that I could create a dummy project in visual studio >> and paste the test in, see if it works, then run it on MD in linux. This >> doesn't seem like the best approach to me. >> >> So my question, what is the generally accepted way to create tests for >> mono? >> >> Thanks in advance >> 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] Killing .NET 2.0 support?
I don't know whether it's relevant, however we recently upgraded an ASP.NETWebForms application from 2.0 to 4.0 and there were numerous little gotchas on the. NET runtime. Granted a lot of these were with third party libraries, but I would be concerned that this could simply cause some applications to just not work. Therefore causing people to need to setup parallel mom installations. That said, I don't know anything about the approach you're suggesting as to whether the same issues could occur. My2cents would be that compatibility issues would need to be fast tracked if you did that. Personally, I only use 4.0 and above now, so for me, do as you will. Anything to give people time to focus on the important, useful things in the framework (like making MVC5 and OWIN security work) Thanks Martin On 14 May 2014 19:47, "Rafael Teixeira" wrote: > I think it is a good move. But all tests for NET_20 profile (as compiled > in that profile) must be run and succeed in the NET_45 profile, before > killing it. > > My 2 cents, > > Rafael Teixeira > O..:.) > > > On Wed, May 14, 2014 at 3:32 PM, Miguel de Icaza wrote: > >> Hey guys, >> >> Maintaining the .NET API has become a pain and we feel that everything >> that could run with 2.0 could run with 4.5. >> >> So we are wondering if we should just kill this and get on with our lives. >> >> It would let us use Async internally in our class libraries (among other >> things) >> >> I wonder if we could just patch the Mono C runtime to redirect all >> references to the 2.0 assemblies at runtime to the 4.0 gac? >> >> 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 > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Update on Build System
Hi Miguel, As always, thanks for your work on this. I'm looking forward to contributing once it's completed. I have a small question/suggestion around the solution... If we added the test projects to it, could we build and run the tests using the VS/MD/XS. This way you get debugging built in... Also, do you think that building using xbuild should be added to the automated build process? so that it's always upto date? Basically, should a commit/pull be disallowed if it breaks building using xbuild? I've managed to compile master using make, and it seems to be faster... I'll await a further update and try the xbuild process. Thanks again for your efforts... Martin On 24 May 2014 11:20, Bryan Crotaz wrote: > Can't wait for this to be complete so I can contribute. > > Bryan Crotaz > Silver Curve > > > On 24 May 2014, at 08:33, David Schmitt wrote: > > > >> On 2014-05-24 04:58, Miguel de Icaza wrote: > >> Hey guys, > >> > >> #1 Makefile Build System Update > >> > >> So the clean staged setup has been added to mono/master and in practice > >> most of you will never notice an improvement. > >> > >> Those working on libraries that had cross dependencies will enjoy > >> reliable and working builds. If you make a change in say System, and > >> you type "make" in mcs/class/System, it will make sure that all the > >> dependencies are properly compiled and the result will be stable. > > > > Awesome news :-) improving the libraries is THE easiest way for us mere > mortals to start contributing, and any improvement in the build system is > very welcome. > > > > Please make sure that the appropriate docs are also updated. > > > > > > > > Thank you for your time and work! > > > > > > Regards, David > > > > > > ___ > > 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
[Mono-dev] ASP.NET vNext libraries and mono
So I've been playing with vNext and mono, and I was wondering around the library support. Microsoft have said that they will be adding mono to their test matrix. However, they haven't (from what I can tell) gone as far as saying what exactly they will be testing i.e. is it just the kre/kpm/etc, or are they doing it for the packages too? It seems that all the examples are using different versions of the libraries than the standard .NET 4.x versions. So the question is, are packages on nuget from microsoft going to have mono versions? I know this is a question direct for this list, I'm just wondering if anyone has seen any information on it? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoTizen contractor found - Crosstwine Labs (Damien Diederen)!
Good luck... this does sound very interesting... On 13 June 2014 22:10, Bob Summerwill wrote: > > I am delighted to announce that Crosstwine Labs (Damien Diederen) will be > contracting for Kitsilano Software to bring Tizen support to Mono up to > spec. > > http://crosstwine.com/ > https://twitter.com/ztzg > https://www.linkedin.com/pub/damien-diederen/0/5a9/473 > > It sounds like the Mono runtime very nearly "just works" on Tizen already, > so much of the work is likely to be ensuring that all the samples and > unit-tests are in a good state, and then setting up automated builds and > tests for everything, to ensure that things stay in a healthy state forever! > > Thanks to the other individuals who also contacted me. Best wishes ... > > > Cheers, > Bob Summerwill > Kitsilano Software > > https://twitter.com/monotizen > http://kitsilanosoftware.wordpress.com/about/ > http://bobsummerwill.wordpress.com/contact-bob/ > > > -- > b...@summerwill.net > > > ___ > 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] Mono, TDS and SQL Server 2012
Couple of things that will help.
Mono version, platform and whether it was compiled from source or installed
by soke other means
Sample app (not your entire codename, just a basic console app that
replicates the issue).
In the first instance I would look at replicating this using basic stuff,
I.e. Just a basic datareader on the table in a bear console app.
I believe it does work against 2012 though. So I could be a specific data
type or possibly specific data that's causing it.
I can possibly try to replicate on Sunday if you don't get any further
response, but I think it's highly likely it's data or configuration
specific not sql version.
Martin
On 1 Aug 2014 19:02, "Chris Tacke" wrote:
> I’m trying to add SQL Server support to the Mono (on Linux, not Android if
> it matters) version of one of our products.
>
>
>
> I have a codebase that works fine on Windows, but under Mono, it’s not
> behaving. We’re using SQL Authentication, not NT.
>
>
>
> I am able to get back a list of table names, so I know it’s “talking” to
> the database, but when I attempt to query rows from a table I get this:
>
>
>
> [ERROR] FATAL UNHANDLED EXCEPTION: System.Exception: Unknown packet type
> 129
>
> at Mono.Data.Tds.Protocol.TdsComm.GetPhysicalPacketHeader () [0x0]
> in :0
>
> at Mono.Data.Tds.Protocol.TdsComm.GetPhysicalPacket () [0x0] in
> :0
>
> at Mono.Data.Tds.Protocol.TdsComm.Peek () [0x0] in unknown>:0
>
> at Mono.Data.Tds.Protocol.Tds.NextResult () [0x0] in unknown>:0
>
> at System.Data.SqlClient.SqlCommand.ExecuteScalar () [0x0] in
> :0
>
> at
> OpenNETCF.ORM.SQLStoreBase`1[OpenNETCF.ORM.SqlEntityInfo].ExecuteScalar
> (System.String sql) [0x0] in :0
>
> at OpenNETCF.ORM.SqlServerDataStore.get_ServerVersion () [0x0] in
> :0
>
> at OpenNETCF.ORM.SqlServerDataStore.Fetch (System.String entityName,
> Int32 fetchCount, Int32 firstRowOffset, System.String sortField,
> FieldSearchOrder sortOrder, OpenNETCF.ORM.FilterCondition filter, Boolean
> fillReferences) [0x0] in :0
>
> at SolutionFamily.Storage.DataEntityProvider.GetEntityInstances
> (System.String entityName, Int32 skipNumber, Int32 retrieveNumber)
> [0x0] in :0
>
> {more call stack omitted}
>
>
>
> So it looks like the TDS version in Mono is old, maybe? Packet type 129
> looks like it’s a “result” packet:
>
>
>
> http://www.freetds.org/tds.html#t129
>
>
>
> And it’s been in use since SQL Server 7, which itself is pretty far from
> “recent”.
>
>
>
> So my questions, I guess, Are:
>
> - Is connecting to a SQL Server 2012 database from a Mono app a
> supported scenario?
>
> - Is there a newer version of TDS on the System.Data.* stuff
> available that adds support?
>
> - Has anyone had any luck connecting to a “modern” version of
> SQL Server?
>
> - Any thoughts on how to proceed (other than debugging and
> attempting to implement this stuff myself)?
>
>
>
> -Chris
>
> ___
> 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] How to run full mono test suites
Does a simple "make test" not run all the tests? Or are you looking for something else? On 2 Sep 2014 22:59, "Liwei Peng" wrote: > Hi Mono, > > > > I am evaluating mono on a Linux machine (Ubuntu). I’d like to run the full > test suites published on this website: > https://wrench.mono-project.com/Wrench/ > > > > While this link > http://www.mono-project.com/community/contributing/test-suite/ has some > general description on the test framework, my question is: is there > existing script or document that I can use to run the full test suites? So > that I don’t need to spend time to check each class library or runtime > tests individually? > > > > Thanks, > > > > Liwei > > > > ___ > 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] System.Json string handling
I would have to both agree and disagree with Edward on that... Yes you need things to be updated and made to work so you get people wanting to use the platform. However, without making sure that the patches meet standards and are considering all the options, you risk the opposite the code gets worse, there are knock on affects. I'm as frustrated with the current process as most as I've been waiting for the MVC5 stuff to be fixed and merged for a while. What I would say is though, I'd prefer for MVC4 to continue working as is, than some MVC5 stuff work and MVC4 become unstable. You have to appreciate the position Miguel and the mono team are in. They have a commercial product to maintain, that without that, they wouldn't be able to eat (or put on what I've been told are awesome parties). At the end of the day, having mono is better than not. Also, it's better maintained than some other open source projects. That said, I think that there isn't enough time, currently, dedicated to code that isn't useful to Xamarin. They have taken stewardship of a platform that goes beyond mobile platforms, and are controlling the elements that are not part of their core business, however, they are acting as a bottleneck for those. In short, there is a lot room for improvement, but where we are is by no means a bad position. Just my two (or possibly four) cents. Martin On 21 September 2014 02:29, 何子杰Hzj_jie wrote: > And how to define practices and skills? If you guys do not have time to > review the changes from contributors out of mono group, then how to find > out new people to join the group? And, I continually see an incorrect > design pattern in mono source code, which may cause unexpected behavior in > multithreading environment. This kind of issue may not be able to get > totally fixed, until someone else pointed out the design pattern is not > correct. > > .Hzj_jie > -- > From: Edward Ned Harvey (mono) > Sent: 21/9/2014 3:13 > To: Miguel de Icaza ; 何子杰Hzj_jie > Cc: Steffen Kieß ; > mono-devel-list@lists.ximian.com > Subject: RE: [Mono-dev] System.Json string handling > > > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > > boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono) > > > > Tru dat. However, > > I guess I'm actually trying to say two separate things: > > * When broken stuff doesn't get fixed, it's a disincentive for usage > adoption. > and > * When pull requests get ignored, it is a disincentive to contributors > trying to contribute anymore (fixing things). > > This is an unfortunate positive feedback loop, which can hopefully be > broken some day. I know based on my experience here so far, I'm not going > to bother trying to fix anything anymore. My time would have been better > spent, finding an alternative to mono SslStream instead of trying to > contribute the fix to make mono SslStream operational. > > ___ > 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-dev] Updating aspnetwebstack
Hi all, I'm going to try and dedicate a bit of time to the project over the next couple of months and need a little help understanding where to start with something specific. I've been trying make an application mono compliant but came across a bug in that web Api 5.2.2 isn't compatible with mono. I've seen a bug in the xamarin tracker around it, and Miguel has commented that it won't be compatible until we update mono's version of the aspnetwebstack. Therefore, I'd like to look at that and try to fix anything that's needed as I go. I've got no experience of using submodules in git, so any help on steps to pull in the latest code and build/test would be beneficial. I've had a look at the guide on the mono site and it doesn't really make sense to me. Further, I don't want to do this work if there is no chance of it being accepted. The change will be large I assume, and I know there is a problem with getting large Pr's accepted. If I was doing this for myself, I would simply amend the product I'm trying to get working, so I want to make sure it's not going to be in vain. Also, has anyone looked into this in the past and knows of a reason why it won't work? Thanks Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Resx files in Mono
Hi All, I'm looking at trying to get the latest version of the aspnetwebstack working on mono, and came across an issue with Resx files. First, this may be my environment, so if it is, please let me know. The issue is that I'm getting the following error when trying to compile one of the assemblies: /opt/mono-3.0/aspnetwebstack/src/CommonResources.resx: Error: Error: Cannot load support for ResX format: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified. (System.Web.Razor) I've tried adding a reference to it, and I can't find that assembly, even in the mono directories. So the question is, does compiling Resx files work in mono? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Resx files in Mono
Thanks Robert that explains a bit. My goal was to make a minimal amount of changes to the webstack so that it could be kept upto date easily. Looking at the way it's done currently by creating a csproj file that references the files individually, I'm not sure it's possible. What I'm not thinking is that it may be better to simply make the aspnetwebstack source be able to compile standalone on mono. I'm open to suggestions, I'm not sure I'm the best man/woman/person for the job, however I really want to give it a go. Thanks, Martin On 9 October 2014 11:44, Robert Jordan wrote: > On 08.10.2014 23:05, Martin Thwaites wrote: > >> >> I've tried adding a reference to it, and I can't find that assembly, even >> in the mono directories. >> >> So the question is, does compiling Resx files work in mono? >> >> > It does. > > The long story: Microsoft has implemented the ResX support in > the System.Windows.Forms assembly (a GUI library) and reused > it from System.Web. > > For compatibility reasons, Mono did the same (Mono's > System.Windows.Forms can be found in the Native.Windows.Forms > directory side-by-side with System.Web inside "mcs/class"). > > However, since System.Windows.Forms is kinda unsupported > and deprecated under Mono, the team has begun including > the ResX source code directly into System.Web: > > https://github.com/mono/mono/blob/master/mcs/class/System. > Web/System.Web.dll.sources > > > What you can do is: > > - install System.Windows.Forms. It's usually part of Mono > but your disto might have split it into its own package. > > - build your aspnet update inside Mono mcs/class tree while > reusing the build infrastructure. Look at how Mono's System.Web > is built. > > Robert > > > ___ > 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-dev] Mono Encryption
Hi All, In my latest endeavour to get the aspnetwebstack functioning on mono, I've found that the MachineKey.Protect and Unprotect classes aren't implemented. So, I've tried to put together something that would work, but not something that meets all the information supplied on MSDN page (e.g. framework options). My question is, I'm piggybacking on the MachineKey.Encrypt/Decrypt methods, is this sufficient to be accepted by the community? Here's the start of what I'm putting together. https://github.com/martinjt/mono/blob/mvc_fixes/mcs/class/System.Web/System.Web.Security/MachineKey.cs So, would a pull along these lines by accepted, or do all the requirements of the MSDN page need to be met? I'm not asking for a review of the pull right now as I need to check against coding standards, and add some more unit tests, just whether a half baked (but working) implementation is acceptable. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Encryption
Thanks for the quick reply Miguel. The crypto will be at least as secure as the existing MachineKey.Encrypt methods. It's this page that I've not looked: http://msdn.microsoft.com/en-us/library/system.web.configuration.machinekeycompatibilitymode%28v=vs.110%29.aspx There appears to be some new configuration sections that can change the crypto methods used. However, I've not looked into them so I'm not sure what they would change. Thanks, Martin On 16 October 2014 20:23, Miguel de Icaza wrote: > In general, a partial implementation is better than no implementation at > all. > > When it comes to crypto, things are a little bit different, and we need to > be more careful. > > What are the things that would not work from the spec? > > Miguel > > > > On Thu, Oct 16, 2014 at 3:20 PM, Martin Thwaites > wrote: > >> Hi All, >> >> In my latest endeavour to get the aspnetwebstack functioning on mono, >> I've found that the MachineKey.Protect and Unprotect classes aren't >> implemented. >> >> So, I've tried to put together something that would work, but not >> something that meets all the information supplied on MSDN page (e.g. >> framework options). >> >> My question is, I'm piggybacking on the MachineKey.Encrypt/Decrypt >> methods, is this sufficient to be accepted by the community? >> >> Here's the start of what I'm putting together. >> >> >> https://github.com/martinjt/mono/blob/mvc_fixes/mcs/class/System.Web/System.Web.Security/MachineKey.cs >> >> So, would a pull along these lines by accepted, or do all the >> requirements of the MSDN page need to be met? >> >> I'm not asking for a review of the pull right now as I need to check >> against coding standards, and add some more unit tests, just whether a half >> baked (but working) implementation is acceptable. >> >> Thanks, >> 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] Pull Requests
Just to give my2cents on this. I would just like to know that things will get looked at approved at some point. I saw a while back that there was a flurry of activity on PR's, and some people (possibly after direction from Miguel) whacked that list down considerably. Is there anything that Xamarin can do to maybe help out with an ETA on reviewing pull requests? even if it's something along the lines of "This needs X to review it, and we expect to get time next month". I know Xamarin staff aren't the only people who can approve, but maybe that's a fallback if noone can review it earlier. As always, love what you do, and as you said the bar is high in mono which I love. I'm actually using the mono codebase as an example for my staff to look at to see how an opensource project can be done right. Thanks, Martin On 16 October 2014 20:39, Greg Young wrote: > Miguel, > > "In the meantime, if you need quick hacks, you can always fork Mono > and distribute your forked version with your changes." > > To be fair you know the pain we deal with due to this. > > For us if we had a backlog of 200 PRs this would be a wonderful > problem to have. I would immediately hire 1-2 people to knock it down. > I think what most people in the community perceive (which is why I > started the topic) is that outside support is not making it into the > pipeline. > > Cheers, > > Greg > > ps Miguel did I mention you need to come to Lithuania next year? > > On Thu, Oct 16, 2014 at 8:31 PM, Miguel de Icaza > wrote: > > Hello Greg, > > > > The best approach is to stay engaged in the pull requests and bring the > > attention to the mailing list for us to discuss. > > > > Long term, the ideal situation is one where we can give more people > commit > > rights, and review rights. But until we have developed the skills in > the > > community that are needed, we will continue with the current setup. > > > > The bar for mono is high: we can not just take any code and distribute > it, > > since the impact of mistakes is large. > > > > To give an example, even new Xamarin employees that are hired to work > > exclusively on the runtime are working through pull requests, and they > also > > have to wait for some of the more senior people to review and approve the > > patches. We have very nice fixes that we still postpone until we have > the > > bandwidth of doing a full review. > > > > In the meantime, if you need quick hacks, you can always fork Mono and > > distribute your forked version with your changes. > > > > Miguel > > > > On Thu, Oct 16, 2014 at 3:27 PM, Greg Young > wrote: > >> > >> This topic has been brought up in a ton of other threads I just want > >> to centralize the topic. > >> > >> I have felt the pain many others have discussed (6-12 months for an > >> accept of PR, we actually had a separate distribution of mono for a > >> while). > >> > >> Is there background on the issue? > >> What are the issues that are involved from a xamarin perspective? > >> How can the community help? > >> > >> Cheers, > >> > >> Greg > >> > >> -- > >> Studying for the Turing test > >> ___ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > -- > Studying for the Turing test > ___ > 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] Mono Encryption
Hi Miguel, I've given it a bit more of a look. The things that wouldn't work is being able to provide custom decryption algorithms via the web.config. Nothing else seems to be affected. I'll package it up and send it over, thanks for the help. Thanks, Martin On 16 October 2014 21:26, Miguel de Icaza wrote: > Hello, > > I would say, let us wrap up what you have, and then we can review the > implications that lacking some options might have. > > On Thu, Oct 16, 2014 at 3:30 PM, Martin Thwaites > wrote: > >> Thanks for the quick reply Miguel. >> >> The crypto will be at least as secure as the existing MachineKey.Encrypt >> methods. It's this page that I've not looked: >> >> >> http://msdn.microsoft.com/en-us/library/system.web.configuration.machinekeycompatibilitymode%28v=vs.110%29.aspx >> >> There appears to be some new configuration sections that can change the >> crypto methods used. However, I've not looked into them so I'm not sure >> what they would change. >> >> Thanks, >> Martin >> >> On 16 October 2014 20:23, Miguel de Icaza wrote: >> >>> In general, a partial implementation is better than no implementation at >>> all. >>> >>> When it comes to crypto, things are a little bit different, and we need >>> to be more careful. >>> >>> What are the things that would not work from the spec? >>> >>> Miguel >>> >>> >>> >>> On Thu, Oct 16, 2014 at 3:20 PM, Martin Thwaites < >>> monofo...@my2cents.co.uk> wrote: >>> >>>> Hi All, >>>> >>>> In my latest endeavour to get the aspnetwebstack functioning on mono, >>>> I've found that the MachineKey.Protect and Unprotect classes aren't >>>> implemented. >>>> >>>> So, I've tried to put together something that would work, but not >>>> something that meets all the information supplied on MSDN page (e.g. >>>> framework options). >>>> >>>> My question is, I'm piggybacking on the MachineKey.Encrypt/Decrypt >>>> methods, is this sufficient to be accepted by the community? >>>> >>>> Here's the start of what I'm putting together. >>>> >>>> >>>> https://github.com/martinjt/mono/blob/mvc_fixes/mcs/class/System.Web/System.Web.Security/MachineKey.cs >>>> >>>> So, would a pull along these lines by accepted, or do all the >>>> requirements of the MSDN page need to be met? >>>> >>>> I'm not asking for a review of the pull right now as I need to check >>>> against coding standards, and add some more unit tests, just whether a half >>>> baked (but working) implementation is acceptable. >>>> >>>> Thanks, >>>> 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] Pull Requests
Hi Miguel, I have considered helping out by commenting on PR's, however, I've always felt that I'm not nearly experienced enough to have my opinion/view respected by the committer. I definitely think forcing/gently encouraging people to create a discussion on mailing list to ask for review would help. Maybe a format for the subject? i.e. PR#1123 - . this would help people filter if they so desire. I think if that is the position though, there needs to be a way to say "non-contributors have said it's ok, let's get a proper review now". I'm not sure how you could do that though, is there a workflow in GitHub that could help? maybe something you have at Xamarin that could be re-used? I'm going to try and help out with a few this week and we'll see how it goes. Thanks, Martin. On 16 October 2014 22:28, Miguel de Icaza wrote: > Let me add a couple of points. > > First, I have noticed is that: > >- Contributors do not make a habit out of checking pull requests; I >know I don't > >- GitHub is too chatty, so everyone I know just filters notifications. > I suspect this is why anyone being assigned issues just ignores them. >There is just too much traffic. > > Mono historically took patches from the mailing list. Not from github > pull requests. So culturally, this was never aligned, it just kind of > happened, and we kind of never evolved or changed with it. > > Perhaps what we need is for these pull requests to be posted here on the > list and discussed here on the list. > > I think this is better, as we have a place where the larger community can > comment on patches. It would surface the discussion to everyone, as > opposed to limiting it to those that happen to stumble on the pull requests > or visit the page. > > Second, I think there is a room for folks to contribute to this process, > even if they are not committers, or active contributors. Someone that > could shepherd a contributor and the contribution. Many of the patches do > not meet the basic requirements for a patch review, and we end up wasting > valuable time on them. > > Things that we would need: > >- An actual detailed explanation of the change. Many patches are >submitted with very little information. > >- Test cases: many patches are contributed without tests to show the >problem as it is today nor to ensure that the code does not regress. > >- Style: many patches contain white space changes, unnecessary >refactoring and changes that are not suitable to be contributed. > >- Rebasing: many patches are contributed and fixes are piled on top of >each other. The result is not suitable to be merged as it would >essentially pollute the commit history. So someone that can assist the >less sophisticated among us to "squash" the commits would help. > >- Patches that change the surface and contain no documentation. > >- Steering developers to discuss the patches on the mailing list and >following up directly on the mailing list with the reviewers to ensure that >the patches can be merged. > > I think the above would help us tremendously to accelerate the patch > review process. > > Miguel > > On Thu, Oct 16, 2014 at 4:30 PM, Miguel de Icaza > wrote: > >> There is no point in starting a discussion where you are going to cherry >> pick facts for the sake of your argument. >> >> As for contributing, which one of *your* pull requests have been pending >> and not being reviewed? >> >> Because we would like to provide you with the valuable feedback that you >> need to turn these contributions into patches. >> >> Miguel >> >> On Thu, Oct 16, 2014 at 4:25 PM, David Nelson < >> eatdrinksleepc...@gmail.com> wrote: >> >>> "Long term, the ideal situation is one where we can give more people >>> commit rights, and review rights. But until we have developed the skills >>> in the community that are needed, we will continue with the current setup." >>> >>> This seems to be a chicken-and-egg problem. We need to christen more >>> reviewers in order to handle the volume of PRs and keep the Mono community >>> engaged; but in order to gain enough confidence in a contributor to make >>> them a reviewer, their requests need to be reviewed! How can we "develop >>> the skills in the community" if requests routinely sit idle for over a year? >>> >>> I got really excited about contributing to Mono about two years ago; I >>> love .NET and C#, but many of my colleagues (not to mention many of the >>> companies for which we consult) are staunchly anti-Windows; I wanted to >>> help demonstrate that Mono could be a viable alternative for non-Windows >>> development. But research into the state of the community left me >>> disappointed: PRs are ignored, roadmaps are horribly out of date, builds >>> are constantly broken...in general, not an environment that encourages >>> community members to contribute their valuable time. >>> >>> I understand the desire to maintain a high standa
[Mono-dev] Review of PR1349
Hi all, I've just put up my attempt at getting the MachineKey.Protect and Unprotect methods available in mono. I'd be grateful if someone give it a quick review to make sure it makes sense. https://github.com/mono/mono/pull/1349 Couple of notes. There is no compatibility with encrypted items that were done using Windows. This is a barebones implementation in that it will work and be at least as secure as MachineKey.Encrypt/Decrypt (as it uses the same methods under the hood). This is my first PR for mono, so please be kind. I've tried my best to follow the coding guidelines, but I'm happy to make changes. Thanks Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Review of PR1349
Thanks Chris, The main thing I think will be off benefit with people reviewing is simply getting that second pair of eyes to sanity check it. Looking for basic coding standards stuff, anything obvious. Other things like advice on separating things out etc. On 17 October 2014 20:46, Chris Rogus wrote: > Disclaimer: I know nothing about these classes. > > That said, I firmly support the plan to bring PRs into the mailing list, > and would hate to see such a great plan get no love, so I want to say that > from looking at these (very small and easily digested) changes, they at > least look clean and good. > > From a fellow user of Mono who is interested in its success and expansion > (with no say in any outcomes here), thanks for doing this. > On Oct 16, 2014 6:23 PM, "Martin Thwaites" > wrote: > >> Hi all, >> >> I've just put up my attempt at getting the MachineKey.Protect and >> Unprotect methods available in mono. I'd be grateful if someone give it a >> quick review to make sure it makes sense. >> >> https://github.com/mono/mono/pull/1349 >> >> Couple of notes. There is no compatibility with encrypted items that >> were done using Windows. This is a barebones implementation in that it >> will work and be at least as secure as MachineKey.Encrypt/Decrypt (as it >> uses the same methods under the hood). >> >> This is my first PR for mono, so please be kind. I've tried my best to >> follow the coding guidelines, but I'm happy to make changes. >> >> Thanks >> 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-dev] Closing Pulls
Hi All, This is probably more a question for Miguel, but I thought I'd make it public. I'm looking through the list of PR's (103 at the moment) and I thought it best to go from the end. However, it seems like most of these are either done by someone who no longer has interest in contributing, or probably no longer relevant. I'm wondering whether the best option here is to try and put a bit of a hardline policy for a short time to get the list to a more manageable number, and make sure that PR's will be responded to and updated by the commiter. What I'm thinking is, ping the commiter, give them 1 week to respond (in some way, not necessarily update it, just acknowledge it). After that simply close it. The goal here is that if the list is smaller, so the contributors actually feel that clearing the queue is an achievable task. For this to work, I'm thinking we (I'm happy to dedicate some time to this) could just ping the mailing list to ask you close them Miguel? I'm thinking it's an easy and quick thing to do, so we can expect a fairly quick turnaround? Any thoughts welcome. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Closing Pulls
Thanks Miguel, I appreciate why you would want to keep them, however, do you not feel the list is currently unmanageable? Maybe we could add labels (the ones in GitHub, not used them before but it looks like it could work) to the older ones like "inactive" so we know which ones are worth reviewing and can filter them out? On 17 October 2014 23:17, Miguel de Icaza wrote: > >> For this to work, I'm thinking we (I'm happy to dedicate some time to >> this) could just ping the mailing list to ask you close them Miguel? I'm >> thinking it's an easy and quick thing to do, so we can expect a fairly >> quick turnaround? >> > > I dont think they hurt to keep them open. > > Do not want to throw the baby with the bath water. > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Do we need to maintain the csproj files?
Hi all, I'm wondering if, when adding new classes, we need to also add the file to the relevant .csproj file as well as the .sources files? I'm not sure what state they're in, but I am using them myself to develop with, so it would be useful if that was the rule. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Review of PR1354 - add Request.Abort()
Hi all, I've just submitted a pull to add Request.Abort() to the HttpRequest class. It simply calls "CloseConnection" on the worker request so it's pretty simple. I'm not sure how to add a unit test for this so any help would be appreciated. This is for the work I'm doing on getting the aspnetwebstack working. https://github.com/mono/mono/pull/1354 Thanks Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Review of PR1354 - add Request.Abort()
Thanks Miguel, >From the documentation, it simply says it throws an exception if not integrated so that should be simple to add. I wasn't aware that the pipelines existed in mono which is why I've not done it. Is there an example of doing a check that you know of off the top of your head? In terms of usage, it's used in the WebAPI/MVC, and doesn't appear to be malicious related so maybe it's being misused there. I would imagine though that it's around theory of keeping connections open to the server (probably for something like websockets?). Thanks, Martin On 19 October 2014 00:56, Miguel de Icaza wrote: > Hey Martin, > > Thanks for the patch; The documentation describes that this has two > behaviors depending on the pipeline mode in use: > > > http://msdn.microsoft.com/en-us/library/system.web.httprequest.abort(v=vs.110).aspx > > It might be good to find out if there are other things that this call > should do beyond closing the connection. It seems like it was intended to > be used against a malicious HTTP client (which I have no information about > what they mean by this). > > > > On Sat, Oct 18, 2014 at 5:40 PM, Martin Thwaites > wrote: > >> Hi all, >> >> I've just submitted a pull to add Request.Abort() to the HttpRequest >> class. It simply calls "CloseConnection" on the worker request so it's >> pretty simple. >> >> I'm not sure how to add a unit test for this so any help would be >> appreciated. >> >> This is for the work I'm doing on getting the aspnetwebstack working. >> >> https://github.com/mono/mono/pull/1354 >> >> Thanks >> 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-dev] State of aspnetwebstack on mono
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
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" 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 > 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
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" 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
> 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
>> 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, 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" 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-dev] ASP.NET 4.5 Async Pipeline
Hi all, I'm still working through implementing methods to mvc/webapi, however, I've found that the newer versions of WebApi are reliant on async controllers. Now, my perception is that this means that the note on the mono compatibility page around the Async Pipeline needs to be implemented for that to work. First, please let me know if I've misunderstood. If I take this on, I'm going to need some help to implement it. I see 2 options, first, someone helps me out with some resources that I can use to devise a way to do it, articles on the process, examples of where it might be implemented in the current codebase for other things, etc. Second, we enlist the help of someone who is more equipped. I believe that there are quite a few people who are interested in getting this implemented, and therefore I have an idea that we could potentially crowd fund the money to pay a contractor to potentially do it. My hope would be that with a financial incentive, someone within Xamarin may be willing to put forward their spare time to do it. This would likely give us a better chance of getting it merged due to them already being used Miguel's (understandably high) standards and the processes involved in contributing. So, is there anybody else who would be willing to donate to this (I'm thinking something like a kickstarter campaign so that people can get their money back if it doesn't go ahead). Also, does anyone who has an idea of how it would be done have any idea what sort of effort we would be looking at? Alternatively, can someone give me an idea of where to start with implementing it? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ASP.NET 4.5 Async Pipeline
Hi Miguel, That is a great idea around making them synchronous in the background. I'm sure this would cause some issues for people, however if we can hit the main use cases in the initial stab that would be great. Are you suggesting that this is done in the Webapi code, or somewhere in the mono source. My goal has been to make it so we don't need our own implementation of the aspnetwebstack. It would also be great if we can say that async controllers work in mono, just run synchronously, rather than "use these dlls and Webapi will work". Thanks for offering to help out, if there is some initial Google terms you could point me in the direction of that would be great as Async pipeline doesn't seem to be specific enough. Martin On 22 Oct 2014 14:58, "Miguel de Icaza" wrote: > Hey, > > You could start by "faking" the async controllers for now. This would be > enough to support WebAPI, even if behind the scenes it is entirely sync. > > This buys us some time to research the subject. There were a few > interesting posts on MSDN, and the blogs about how this works a couple of > years ago, so those would be great research material. > > I can assist (in my copious spare time) with this, as I wrote chunks of > the current ASP.NET pipeline with Gonzalo. > > Miguel > > On Tue, Oct 21, 2014 at 4:02 PM, Martin Thwaites > wrote: > >> Hi all, >> >> I'm still working through implementing methods to mvc/webapi, however, >> I've found that the newer versions of WebApi are reliant on async >> controllers. >> >> Now, my perception is that this means that the note on the mono >> compatibility page around the Async Pipeline needs to be implemented for >> that to work. First, please let me know if I've misunderstood. >> >> If I take this on, I'm going to need some help to implement it. I see 2 >> options, first, someone helps me out with some resources that I can use to >> devise a way to do it, articles on the process, examples of where it might >> be implemented in the current codebase for other things, etc. Second, we >> enlist the help of someone who is more equipped. >> >> I believe that there are quite a few people who are interested in getting >> this implemented, and therefore I have an idea that we could potentially >> crowd fund the money to pay a contractor to potentially do it. My hope >> would be that with a financial incentive, someone within Xamarin may be >> willing to put forward their spare time to do it. This would likely give >> us a better chance of getting it merged due to them already being used >> Miguel's (understandably high) standards and the processes involved in >> contributing. >> >> So, is there anybody else who would be willing to donate to this (I'm >> thinking something like a kickstarter campaign so that people can get their >> money back if it doesn't go ahead). >> >> Also, does anyone who has an idea of how it would be done have any idea >> what sort of effort we would be looking at? >> >> Alternatively, can someone give me an idea of where to start with >> implementing it? >> >> Thanks, >> 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] ASP.NET 4.5 Async Pipeline
That's great, there's only a few bits that need doing to make it compile, and I'm pretty sure I can handle those. I've put in some crude implementations of the missing elements to try and scope the work involved, and unless there's something wrong in those, it needs some further work under the hood. The issue I see us that I'm getting never ending calls to Webapi endpoints, whereas standard (non-async) MVC controllers work fine. So my perception is that there is something stopping the pipeline from completing. I think the best option is to complete the missing elements that I believe I can do, then possibly post a simple Webapi solution that reproduces it. Then maybe you could use some of your (obviously large amount of) free time to have a quick look. Unless there is something off the top of your head that you think I could look at? On a side note, do you think you'll be going to Future Decoded on the 12th? There's a possibility I might be going and it would be nice to put a face to the name. Thanks Martin Hey, The changes should be done in Mono. Just enough to have aspnetwebstack compile out of the box. On Wed, Oct 22, 2014 at 11:42 AM, Martin Thwaites wrote: > Hi Miguel, > > That is a great idea around making them synchronous in the background. > I'm sure this would cause some issues for people, however if we can hit the > main use cases in the initial stab that would be great. > > Are you suggesting that this is done in the Webapi code, or somewhere in > the mono source. My goal has been to make it so we don't need our own > implementation of the aspnetwebstack. It would also be great if we can say > that async controllers work in mono, just run synchronously, rather than > "use these dlls and Webapi will work". > > Thanks for offering to help out, if there is some initial Google terms you > could point me in the direction of that would be great as Async pipeline > doesn't seem to be specific enough. > > Martin > On 22 Oct 2014 14:58, "Miguel de Icaza" wrote: > >> Hey, >> >> You could start by "faking" the async controllers for now. This would >> be enough to support WebAPI, even if behind the scenes it is entirely sync. >> >> This buys us some time to research the subject. There were a few >> interesting posts on MSDN, and the blogs about how this works a couple of >> years ago, so those would be great research material. >> >> I can assist (in my copious spare time) with this, as I wrote chunks of >> the current ASP.NET pipeline with Gonzalo. >> >> Miguel >> >> On Tue, Oct 21, 2014 at 4:02 PM, Martin Thwaites < >> monofo...@my2cents.co.uk> wrote: >> >>> Hi all, >>> >>> I'm still working through implementing methods to mvc/webapi, however, >>> I've found that the newer versions of WebApi are reliant on async >>> controllers. >>> >>> Now, my perception is that this means that the note on the mono >>> compatibility page around the Async Pipeline needs to be implemented for >>> that to work. First, please let me know if I've misunderstood. >>> >>> If I take this on, I'm going to need some help to implement it. I see 2 >>> options, first, someone helps me out with some resources that I can use to >>> devise a way to do it, articles on the process, examples of where it might >>> be implemented in the current codebase for other things, etc. Second, we >>> enlist the help of someone who is more equipped. >>> >>> I believe that there are quite a few people who are interested in >>> getting this implemented, and therefore I have an idea that we could >>> potentially crowd fund the money to pay a contractor to potentially do it. >>> My hope would be that with a financial incentive, someone within Xamarin >>> may be willing to put forward their spare time to do it. This would likely >>> give us a better chance of getting it merged due to them already being used >>> Miguel's (understandably high) standards and the processes involved in >>> contributing. >>> >>> So, is there anybody else who would be willing to donate to this (I'm >>> thinking something like a kickstarter campaign so that people can get their >>> money back if it doesn't go ahead). >>> >>> Also, does anyone who has an idea of how it would be done have any idea >>> what sort of effort we would be looking at? >>> >>> Alternatively, can someone give me an idea of where to start with >>> implementing it? >>> >>> Thanks, >>> 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] Heads up: Elimination of the 2.0 and 4.0 profiles
Hi Miguel, Would you be looking at calling this Mono 4.0? Not that it makes any difference really, it just seems there's been a lot of improvements in recently, and an announcement of a new version me give some renewed interest. Thanks, Martin On 22 October 2014 21:10, Miguel de Icaza wrote: > Hey Alex, > > It is very repetitive work, so what I wanted to do was to write a perl > script to remove the *obvious* ifdefs. The tool would remove only those > that match the following criteria (more or less): > >- Remove toplevel #if NET_2_0 with the final #endif >- Only remove those that contain those preprocessor directives > > And then have a human do the more fine-tuned approach. There are a > couple more defines that I remember could be automated, but I would love to > have this in the form of a script. > > I am afraid of applying a patch like that blindly, because there are no > exact guarantees of what happened without reviewing the whole file. So a > script with the invariants would take a lot of my nervousness out. > > Also, when I did it once, I had a setup where I rebuilt the assemblies and > compared the output. This would ensure that removal of ifdefs did not > change the resulting binaries. > > On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger > wrote: > >> Sounds like a good thing ;-) >> >> I've got a branch in my fork where I removed the NET_2_0 ifdefs: >> https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera >> told me a while ago that removing the 2.0 profile is on the horizon when I >> asked about why the ifdefs are still there. >> >> I refrained from making a PR so far because it is quite huge, do you think >> now would be a good time? >> >> -- Alex >> >> >> >> -- >> View this message in context: >> http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html >> Sent from the Mono - Dev mailing list archive at Nabble.com. >> ___ >> 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
[Mono-dev] Unit testing when it's protected
Hi All, I'm currently putting together the MembershipPasswordAttribute class, and writing some unit test, but it occurs to me that I actually can't test it properly due to the fact that one of the overrides needed is protected. What I came up with was to derive a test class from the attribute and add a public method that internals calls the protected one and returns the result. My question is, is that a valid way to write a test in mono? Here's the example: https://github.com/martinjt/mono/blob/AddMembershipPasswordAttr2/mcs/class/System.Web/Test/System.Web.Security/MembershipPasswordAttributeTest.cs The other thing is, I'm creating these tests by simply building a unit test on windows against .NET, and find error message text etc. as I go and refactoring the test so it passes on .NET. The idea being I then simply run the same tests against linux and fix until they all pass. Is that a valid approach? I'm not decompiling, just hitting the API to find out the valid results and then writing asserts around them? I just don't want these contribution to be poisoned by doing it the wrong way. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?
I think I remember seeing a load of ifdefs for j2ee in Httpapplication. On 24 Oct 2014 11:58, "Etienne Champetier" wrote: > Hi > > 2014-10-24 12:37 GMT+02:00 akoeplinger : > >> I removed TARGET_JVM with https://github.com/mono/mono/pull/1200, do you >> still see it somewhere? >> > No (except in changelogs). Writing about TARGET_J2EE i remembered that > there was also a TARGET_JVM, > so I asked about it in my email without checking > > >> TARGET_J2EE should be removed too I guess. >> > I'm reading horrible code right now because TARGET_J2EE doesn't support > volatile or synchronised hashtable or > > >> -- Alex >> >> Etienne > > ___ > 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] PR 1359: System.Web.HttpApplication: set StatusCode = 500 when we send an exception to the client
Is this something that we can unit test to verify against .Net?
On 24 Oct 2014 13:26, "Etienne Champetier"
wrote:
>
>
> 2014-10-24 13:53 GMT+02:00 Etienne Champetier <
> champetier.etie...@gmail.com>:
>
>> I know nothing about customerrors,
>> but we are in the init so we may have fail to parse the config,
>> so using customerror here is dangerous
>>
>>
>> Exception e = initialization_exception; HttpException exc =
>> HttpException.NewWithCode (String.Empty, e,
>> WebEventCodes.RuntimeErrorRequestAbort); + context.Response.StatusCode
>> = 500; FinalErrorWrite (context.Response, exc.GetHtmlErrorMessage ());
>> PipelineDone
>> (); return;
>>
>> static void FinalErrorWrite (HttpResponse response, string error) { try
>> { response.Write (error); response.Flush (true); } catch { response.
>> Close (); } }
>>
>> The only think that i'm sure of is that we are sending an exception with
>> http 200 :)
>>
>> I can replace 500 with exc.GetHttpCode() if you prefer?
>>
>
> Forget about this, this will send 501 Not Implemented, i prefer 500
>
>
>>
>>
>> 2014-10-24 13:33 GMT+02:00 Martin Thwaites :
>>
>>> Does this need to take into account the customerrors setting in the
>>> Web.config or is that handled further down the pipeline?
>>> On 24 Oct 2014 09:57, "Etienne Champetier"
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> when we get an exception in InitOnce (in HttpApplication), we send this
>>>> exception to the browser, without changing StatusCode so we get a wonderful
>>>> http 200.
>>>>
>>>> I've checked and it's the only place where we call FinalErrorWrite and
>>>> we didn't set StatusCode.
>>>>
>>>> https://github.com/mono/mono/pull/1359
>>>>
>>>> Bye
>>>> Etienne
>>>>
>>>>
>>>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
Hi Miguel, I think my preference would be to have the 3.x.x series continue (as security fix only) with all the profiles, and essentially have it be a legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. I think it should continue if people are willing to support it, but the contributors who don't want to have to support it (or don't have the time to implement hacks for it) don't have to. >From a communication perspective it would be easier to get across saying that "From mono 4.0 onwards, we only support the 4.5 profile" rather than 3.11.x onwards as it's not as easy to remember which 3.x number it was when it stopped. A decision and a change like that does really feel "major" and therefore warrant the change. The other question I have is around the linux distros that ship mono as standard (I think Ubuntu does). Do you perceive this having an affect on them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 applications and there are some core pieces that rely on it? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza wrote: > Hey, > > Mhm, that is a good idea. Will think about it. > > Right now we were just planning on calling the next one Mono 3.12. But > perhaps the time has come for a nice bump! > > Miguel > > On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites > wrote: > >> Hi Miguel, >> >> Would you be looking at calling this Mono 4.0? Not that it makes any >> difference really, it just seems there's been a lot of improvements in >> recently, and an announcement of a new version me give some renewed >> interest. >> >> Thanks, >> Martin >> >> On 22 October 2014 21:10, Miguel de Icaza wrote: >> >>> Hey Alex, >>> >>> It is very repetitive work, so what I wanted to do was to write a perl >>> script to remove the *obvious* ifdefs. The tool would remove only those >>> that match the following criteria (more or less): >>> >>>- Remove toplevel #if NET_2_0 with the final #endif >>>- Only remove those that contain those preprocessor directives >>> >>> And then have a human do the more fine-tuned approach. There are a >>> couple more defines that I remember could be automated, but I would love to >>> have this in the form of a script. >>> >>> I am afraid of applying a patch like that blindly, because there are no >>> exact guarantees of what happened without reviewing the whole file. So a >>> script with the invariants would take a lot of my nervousness out. >>> >>> Also, when I did it once, I had a setup where I rebuilt the assemblies >>> and compared the output. This would ensure that removal of ifdefs did not >>> change the resulting binaries. >>> >>> On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger < >>> alex.koeplin...@outlook.com> wrote: >>> >>>> Sounds like a good thing ;-) >>>> >>>> I've got a branch in my fork where I removed the NET_2_0 ifdefs: >>>> https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, >>>> @kumpera >>>> told me a while ago that removing the 2.0 profile is on the horizon >>>> when I >>>> asked about why the ifdefs are still there. >>>> >>>> I refrained from making a PR so far because it is quite huge, do you >>>> think >>>> now would be a good time? >>>> >>>> -- Alex >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html >>>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>>> ___ >>>> 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] Heads up: Elimination of the 2.0 and 4.0 profiles
Hi Miguel, I'm referring to 3.9, 3.10.1, etc. i.e. the current version being 3.10.1. So I guess it should be considered the "3.x" series. I'm meaning that we shouldn't preclude there being a 3.11, or 3.12, if there is a critical bug. Also, do you have an answer to the distro question? Thanks, Martin On 24 October 2014 19:13, Miguel de Icaza wrote: > Hello Martin, > > There is no such thing as a "3.x.x series". It does not exist. It > never did. > > You must be confused. > > Miguel > > On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites < > monofo...@my2cents.co.uk> wrote: > >> Hi Miguel, >> >> I think my preference would be to have the 3.x.x series continue (as >> security fix only) with all the profiles, and essentially have it be a >> legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base. >> I think it should continue if people are willing to support it, but the >> contributors who don't want to have to support it (or don't have the time >> to implement hacks for it) don't have to. >> >> From a communication perspective it would be easier to get across saying >> that "From mono 4.0 onwards, we only support the 4.5 profile" rather than >> 3.11.x onwards as it's not as easy to remember which 3.x number it was when >> it stopped. A decision and a change like that does really feel "major" and >> therefore warrant the change. >> >> The other question I have is around the linux distros that ship mono as >> standard (I think Ubuntu does). Do you perceive this having an affect on >> them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0 >> applications and there are some core pieces that rely on it? >> >> Thanks, >> Martin >> >> On 22 October 2014 22:18, Miguel de Icaza wrote: >> >>> Hey, >>> >>> Mhm, that is a good idea. Will think about it. >>> >>> Right now we were just planning on calling the next one Mono 3.12. But >>> perhaps the time has come for a nice bump! >>> >>> Miguel >>> >>> On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites < >>> monofo...@my2cents.co.uk> wrote: >>> >>>> Hi Miguel, >>>> >>>> Would you be looking at calling this Mono 4.0? Not that it makes any >>>> difference really, it just seems there's been a lot of improvements in >>>> recently, and an announcement of a new version me give some renewed >>>> interest. >>>> >>>> Thanks, >>>> Martin >>>> >>>> On 22 October 2014 21:10, Miguel de Icaza wrote: >>>> >>>>> Hey Alex, >>>>> >>>>> It is very repetitive work, so what I wanted to do was to write a perl >>>>> script to remove the *obvious* ifdefs. The tool would remove only those >>>>> that match the following criteria (more or less): >>>>> >>>>>- Remove toplevel #if NET_2_0 with the final #endif >>>>>- Only remove those that contain those preprocessor directives >>>>> >>>>> And then have a human do the more fine-tuned approach. There are >>>>> a couple more defines that I remember could be automated, but I would love >>>>> to have this in the form of a script. >>>>> >>>>> I am afraid of applying a patch like that blindly, because there are >>>>> no exact guarantees of what happened without reviewing the whole file. So >>>>> a script with the invariants would take a lot of my nervousness out. >>>>> >>>>> Also, when I did it once, I had a setup where I rebuilt the assemblies >>>>> and compared the output. This would ensure that removal of ifdefs did not >>>>> change the resulting binaries. >>>>> >>>>> On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger < >>>>> alex.koeplin...@outlook.com> wrote: >>>>> >>>>>> Sounds like a good thing ;-) >>>>>> >>>>>> I've got a branch in my fork where I removed the NET_2_0 ifdefs: >>>>>> https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, >>>>>> @kumpera >>>>>> told me a while ago that removing the 2.0 profile is on the horizon >>>>>> when I >>>>>> asked about why the ifdefs are still there. >>>>>> >>>>>> I refrained from making a PR so far because it is quite huge, do you >>>>>> think >>>>>> now would be a good time? >>>>>> >>>>>> -- Alex >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html >>>>>> Sent from the Mono - Dev mailing list archive at Nabble.com. >>>>>> ___ >>>>>> 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
[Mono-dev] Review of PR1363: MembershipPasswordAttribute
Hi All, This is part of the ongoing work for the aspnetwebstack. The only thing it's missing is tests around the PasswordStrength regex, however, I'm no good with regex so maybe someone can give me some to add to the test and valid/invalid strings to test against? I'm also hoping that the approach to testing this is ok. Finally, I've done some changes in the formatting a few times, but it's getting to the point where I can't see anything as I've looked at it too much. Please can someone give it a quick look over? Tests pass on Windows and Linux, I don't have a Mac to test it on but it doesn't do anything special. https://github.com/mono/mono/pull/1363 Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Support 2-args Socket ctor added in .NET 4.5
Hi Kei, This looks like a good now (one small coding change I've just added). Note that I'm not someone who can approve the patch, just an enthusiastic volunteer. Does this mean that the "k web" commandline for the vNext example site (Music store) works after the patch? Something I was trying for a while but never got it working. I was under the impression that to use the slimmed down vNext stuff it had to use everything from their myGet repository, so I'm not sure where the mono class libraries would help with that? That said, implementing stuff in mono will likely benefit someone at some point, so it's definitely worthwhile. Thanks, Martin On 25 October 2014 15:38, Kei Nakazawa wrote: > Hello, > > I noticed some test code of Kestrel (web server for ASP.NET vNext) fails > to compile on Linux hosts. > > /kestrel/test/Microsoft.AspNet.Server.KestrelTests/EngineTests.cs(325,34): > error CS1729: 'Socket' does not contain a constructor that takes 2 arguments > ref: > https://github.com/aspnet/KestrelHttpServer/blob/dev/test/Microsoft.AspNet.Server.KestrelTests/EngineTests.cs#L325 > > It's because 2 args ctor is a new one introduced in .NET 4.5 and not > currently exist on Mono. I found a bugzilla entry mentioning this issue: > https://bugzilla.xamarin.com/show_bug.cgi?id=20048 and dug Mono code for > finding solutions. > > After couple of minutes of investigation, I gave up to write a "clean" > dual stack (IPv4/v6) support and wrote a simple proxy ctor: > https://github.com/mono/mono/pull/1364/files (Thanks @martinjt for > reviewing my pull-req.) > > As I don't see any demands for IPv4/v6 dual stack support around ASP.NET > vNext community, I believe hard-coding protocol version to v4 is just > enough and better than nothing at least for now (of course, full support of > dual stack would be great). > > Any comments/feedback are welcomed. > > Regards, Kei. > > ___ > 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-dev] Mono and vNext, What is microsoft supporting
This has just come up in another discussion and I thought I'd separate it
out so it doesn't dirty the PR discussion...
Alex, some questions on your response.
"CoreCLR is intended to be Windows-only too from what I've heard, as it
doesn't make much sense for Mono (you can already do side-by-side
deployment of Mono)."
Where have you seen this, do you have a link you can send? This is a major
missing piece of the puzzle for me. I've been hoping that with vNext,
applications would be truely cross platform, but it seems we are still very
much reliant on Mono's class implementations.
I've read an article[1] that says the CoreCLR ("Cloud Optimized") is to be
"Cross Platform". If that is the case, and there are no plans to make a
linux compatible version and just use mono, they could easily say the same
about the .NET 4.5 class libraries as they are available in mono.
So either, when Microsoft refer to "Cross platform", they are only
referring to applications that rely on no class libraries and only corlib
(is that a thing can an application be purely reliant on no class
libraries?). Alternatively, they are relying on Mono to create a CoreCLR
(I wouldn't be surprised if they've ask for Xamarin's help in doing that).
I am aware that you can side-by-side in mono, however, I thought that one
of the other big benefits of vNext was the reduction in footprint,
specifically around the memory footprint per request. So you can
opt-in/out of specific features.
I'd appreciate anybody chiming in with they thoughts. I'd absolutely love
someone "in the know" to give us something definitive though.
Thanks,
Martin
[1]
http://blogs.msdn.com/b/cesardelatorre/archive/2014/05/12/the-future-of-net-in-the-server-asp-net-vnext-optimized-for-cloud-and-server-workloads.aspx
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] NUnit version for mono source tests
Hi all, I've been writing some unit tests recently and I've noticed (the hard way, by using things that don't exist like Assert.Throws and having to re-write them) that we're using an old version of NUnit (2.4.8). Is there a reason for not upgrading to something more current? The current version is 2.6.3 (and I believe it's mono compliant), however, very soon there will be an amazing new version that will enable tests to run in parallel out of the box (by amending some of the unit tests). Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NUnit version for mono source tests
Hi Miguel/Charlie, If there is no fundamental reason not to use a more recent version, then I'll add it to my list. I seem to recall that Nunit 3.0 is removing support for older framework versions, so if it removes 2.0 we won't be able to do it until "the big purge" happens in mono. Once I've got these bits done for the webstack, I'll have a look. Unless someone beats me to it. Couple of questions. Charlie, were there any breaking changes between 2.4.8 and 2.6.3? and dovyou have a link to the specific breaking changes between 2.6 and 3.0? Miguel, would you accept a PR from the community for this? Given that it may mean your company needs to update their tests too? Thanks Martin On 26 Oct 2014 06:20, "Charlie Poole" wrote: > Is there any way we can help? > > 1) With 2.6.3 / 2.6.4 (coming up) - should be a small effort. > 2) With 3.0 - likely to be a bigger job but easier to maintain thereafter. > > Maybe some monodevelop guy wants to work with us? > > Charlie > > On Sat, Oct 25, 2014 at 8:55 PM, Miguel de Icaza > wrote: > > Time. > > > > On Sat, Oct 25, 2014 at 3:22 PM, Martin Thwaites < > monofo...@my2cents.co.uk> > > wrote: > >> > >> Hi all, > >> > >> I've been writing some unit tests recently and I've noticed (the hard > way, > >> by using things that don't exist like Assert.Throws and having to > re-write > >> them) that we're using an old version of NUnit (2.4.8). Is there a > reason > >> for not upgrading to something more current? > >> > >> The current version is 2.6.3 (and I believe it's mono compliant), > however, > >> very soon there will be an amazing new version that will enable tests > to run > >> in parallel out of the box (by amending some of the unit tests). > >> > >> Thanks, > >> 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] NUnit version for mono source tests
I'm sure Charlie can tell us what considerations there need to be with upgrading from 2.4.8 to 2.6.3 (We have the best resource to do that!). My perception is that the jump to 3.0 might be too big. On 26 October 2014 13:29, Miguel de Icaza wrote: > There are. Someone needs to survey in depth all the ramifications. > Once that happens, then we might consider it. > > > On Sunday, October 26, 2014, Martin Thwaites > wrote: > >> Hi Miguel/Charlie, >> >> If there is no fundamental reason not to use a more recent version, then >> I'll add it to my list. >> >> I seem to recall that Nunit 3.0 is removing support for older framework >> versions, so if it removes 2.0 we won't be able to do it until "the big >> purge" happens in mono. >> >> Once I've got these bits done for the webstack, I'll have a look. Unless >> someone beats me to it. >> >> Couple of questions. >> >> Charlie, were there any breaking changes between 2.4.8 and 2.6.3? and >> dovyou have a link to the specific breaking changes between 2.6 and 3.0? >> >> Miguel, would you accept a PR from the community for this? Given that it >> may mean your company needs to update their tests too? >> >> Thanks >> Martin >> On 26 Oct 2014 06:20, "Charlie Poole" wrote: >> >>> Is there any way we can help? >>> >>> 1) With 2.6.3 / 2.6.4 (coming up) - should be a small effort. >>> 2) With 3.0 - likely to be a bigger job but easier to maintain >>> thereafter. >>> >>> Maybe some monodevelop guy wants to work with us? >>> >>> Charlie >>> >>> On Sat, Oct 25, 2014 at 8:55 PM, Miguel de Icaza >>> wrote: >>> > Time. >>> > >>> > On Sat, Oct 25, 2014 at 3:22 PM, Martin Thwaites < >>> monofo...@my2cents.co.uk> >>> > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I've been writing some unit tests recently and I've noticed (the hard >>> way, >>> >> by using things that don't exist like Assert.Throws and having to >>> re-write >>> >> them) that we're using an old version of NUnit (2.4.8). Is there a >>> reason >>> >> for not upgrading to something more current? >>> >> >>> >> The current version is 2.6.3 (and I believe it's mono compliant), >>> however, >>> >> very soon there will be an amazing new version that will enable tests >>> to run >>> >> in parallel out of the box (by amending some of the unit tests). >>> >> >>> >> Thanks, >>> >> 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] PR #1365: [asp.net] Implement the EventHandlerTaskAsyncHelper and HttpTaskAsyncHandler classes
Hi Miguel, Does that have implications in regards to this PR? i.e. is it just that it doesn't solve the problem, or that the implementation here is wrong? Thanks, Martin On 26 October 2014 13:46, Miguel de Icaza wrote: > Hello, > > The asynchronous pipeline was discussed in various blogs/interviews. > Some switch enables apparently an entirely different flow inside asp.net. > The surface changes were minimal, which is why you won't likely find an API. > > > On Sunday, October 26, 2014, Kornel Pal wrote: > >> Hi, >> >> Inspired by the ASP.NET 4.5 Async Pipeline email thread started by >> Martin Thwaites, I realized that there actually is no new async pipeline in >> ASP.NET 4.5, it merely provides wrappers around tasks to ease >> interfacing with the old async pipeline. >> >> I've looked around a bit, but found no suitable implementation for the >> wrapper, so I've created several unit tests to figure out the MS.NET >> behavior. At the end I came up with TaskAsyncResult, a general purpose TAP >> to APM wrapper. >> >> Please review my pull request: https://github.com/mono/mono/pull/1365 >> >> Thank you. >> >> Kornel >> ___ >> 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] PR #1365: [asp.net] Implement the EventHandlerTaskAsyncHelper and HttpTaskAsyncHandler classes
Thanks Kornel, I've still a few bits of complicated to complete, but I'll feedback as soon as they are done. Martin On 26 October 2014 14:46, Kornel Pal wrote: > Hi, > > I've found this, that fits Miguel's description: > > http://stackoverflow.com/questions/9562836/whats-the-meaning-of-usetaskfriendlysynchronizationcontext > > My PR is is independent of any such changes, and given the API design, I > would be surprised if MS implemented some special handling of these classes. > > As for your requirements, I would give aspnetwebstack a try with the > current pipeline before refactoring the request processing pipeline. > > Thank you. > > Kornel > > > On 10/26/2014 2:50 PM, Martin Thwaites wrote: > > Hi Miguel, > > Does that have implications in regards to this PR? i.e. is it just that > it doesn't solve the problem, or that the implementation here is wrong? > > Thanks, > Martin > > On 26 October 2014 13:46, Miguel de Icaza wrote: > >> Hello, >> >> The asynchronous pipeline was discussed in various blogs/interviews. >> Some switch enables apparently an entirely different flow inside asp.net. >> The surface changes were minimal, which is why you won't likely find an >> API. >> >> >> On Sunday, October 26, 2014, Kornel Pal wrote: >> >>> Hi, >>> >>> Inspired by the ASP.NET 4.5 Async Pipeline email thread started by >>> Martin Thwaites, I realized that there actually is no new async pipeline in >>> ASP.NET 4.5, it merely provides wrappers around tasks to ease >>> interfacing with the old async pipeline. >>> >>> I've looked around a bit, but found no suitable implementation for the >>> wrapper, so I've created several unit tests to figure out the MS.NET >>> behavior. At the end I came up with TaskAsyncResult, a general purpose TAP >>> to APM wrapper. >>> >>> Please review my pull request: https://github.com/mono/mono/pull/1365 >>> >>> Thank you. >>> >>> Kornel >>> ___ >>> 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
[Mono-dev] Review of PR1368: SuppressFormsAuthenticationRedirect implementation
Hi All, This is a simple PR for the property added in .NET 4.5. I couldn't find any existing tests for the module, and I struggled to find a way to test it. All I've done to test it is added to an existing application I have and it functioned the same on windows and linux. Let me know if there are any problems, and if anyone can let me know how to unit test it against .NET I would be grateful. https://github.com/mono/mono/pull/1368 Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PR #1365: [asp.net] Implement the EventHandlerTaskAsyncHelper and HttpTaskAsyncHandler classes
Completely agree Miguel. HttpTaskAsyncHandler is a required class for the webstack to compile (and run I imagine) so any (working) implementation would be useful. Thanks for your help as always Miguel. On 26 Oct 2014 17:24, "Miguel de Icaza" wrote: > I am purely provided some background for interested hackers. > > I stand by the original position that we should do all the minimal changes > required to get ASP.NET vnext to build/run, even if it does not deliver > the performance/scaling benefits at first. > > As for the actual patch, I will review once I am back on my computer > > On Sun, Oct 26, 2014 at 9:50 AM, Martin Thwaites > wrote: > >> Hi Miguel, >> >> Does that have implications in regards to this PR? i.e. is it just that >> it doesn't solve the problem, or that the implementation here is wrong? >> >> Thanks, >> Martin >> >> On 26 October 2014 13:46, Miguel de Icaza wrote: >> >>> Hello, >>> >>> The asynchronous pipeline was discussed in various blogs/interviews. >>> Some switch enables apparently an entirely different flow inside asp.net. >>> The surface changes were minimal, which is why you won't likely find an API. >>> >>> >>> On Sunday, October 26, 2014, Kornel Pal wrote: >>> >>>> Hi, >>>> >>>> Inspired by the ASP.NET 4.5 Async Pipeline email thread started by >>>> Martin Thwaites, I realized that there actually is no new async pipeline in >>>> ASP.NET 4.5, it merely provides wrappers around tasks to ease >>>> interfacing with the old async pipeline. >>>> >>>> I've looked around a bit, but found no suitable implementation for the >>>> wrapper, so I've created several unit tests to figure out the MS.NET >>>> behavior. At the end I came up with TaskAsyncResult, a general purpose TAP >>>> to APM wrapper. >>>> >>>> Please review my pull request: https://github.com/mono/mono/pull/1365 >>>> >>>> Thank you. >>>> >>>> Kornel >>>> ___ >>>> 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
[Mono-dev] Review of PR1370: defaulting the ReadEntityBodyMode.
Hi All, When I put the code in for ReadEntityBodyMode I neglected to implement the default in the HttpRequestBase. I've set this to "Classic" as this should force callers to use the HttpRequestBase.InputStream instead of the buffered/bufferless methods (which aren't implemented). Although we have an implementation GetBufferlessInputStream, it would be a little more work to implement all the logic around ReadEntityBodyMode, therefore this short term fix has been applied. https://github.com/mono/mono/pull/1370 Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Review of PR1371: Add ClientDisconnectedToken to response objects
Hi All, I don't profess to know what it does, however, I've looked at the usage of this in the aspnetwebstack, and under a few scenarios, it defaults it's own helper method to CancellationToken.None. Therefore I'm assuming this is ok as a default in the code. http://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Http.WebHost/HttpResponseBaseExtensions.cs It seems it was added in IIS 7.5, so clients should assume that in some scenarios it's not available. Hope this is ok. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Review of PR1372: Add GetBuffered/lessInputStream methods to the wrappers
Hi All, This adds a couple of methods to the HttpRequestBase and HttpRequestWrapper to access the relevant methods on the request. We do have the GetBufferlessInputStream and it appears to be implemented, however, it will likely not be used as the setting of the ReadEntityBodyMode to "classic" in my previous pull should force the use a properly developed application to use the InputStream instead. Thanks, Martin ___ 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 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" 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] Review of PR1363: MembershipPasswordAttribute
Hi all, I've got a slight problem with this PR, and need some help to fix it. It's a dependency issue, System.Web now depends on System.ComponentModel.DataAnnotations. However, the Makefile puts the component model well after it in the compile order. https://github.com/martinjt/mono/blob/master/mcs/class/Makefile I've checked and the System.ComponentModel.DataAnnotations only depends on System.Core and System.Xml, and System.Data https://github.com/martinjt/mono/blob/master/mcs/class/System.ComponentModel.DataAnnotations/Makefile So I was thinking of moving it up in the class/Makefile to just after the System.Data reference. Any ideas if this is not advisable anyone? Thanks, Martin On 24 October 2014 22:49, Martin Thwaites wrote: > Hi All, > > This is part of the ongoing work for the aspnetwebstack. The only thing > it's missing is tests around the PasswordStrength regex, however, I'm no > good with regex so maybe someone can give me some to add to the test and > valid/invalid strings to test against? > > I'm also hoping that the approach to testing this is ok. > > Finally, I've done some changes in the formatting a few times, but it's > getting to the point where I can't see anything as I've looked at it too > much. > > Please can someone give it a quick look over? > > Tests pass on Windows and Linux, I don't have a Mac to test it on but it > doesn't do anything special. > > https://github.com/mono/mono/pull/1363 > > Thanks, > Martin > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PR 1081: Allow CLR binaries to be passed to Process.Start
You're going to need a new roll of toilet paper for that list soon! Only joking, we all appreciate you spending time with us. On 30 October 2014 21:38, Miguel de Icaza wrote: > In general, it looks fine, but I want to review this in more detail. > > I'll add it to my list. > > On Thu, Oct 30, 2014 at 4:46 PM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > >> This PR (https://github.com/mono/mono/pull/1081) has been sitting in the >> queue for some time. @kumpera already gave his +1 to the patch, so I think >> we could merge it? >> >> >> -- Alex >> ___ >> 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
Amazing, thanks Miguel, comments inline. On 2 Nov 2014 00:52, "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. 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 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" 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
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 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 > wrote: > >> Amazing, thanks Miguel, comments inline. >> >> On 2 Nov 2014 00:52, "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. >> >> 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 >> wrote: >> >>> >> >>> Hi Miguel, >> >>> >> >>> The code that I'm referring to here is that of the aspnetwebstack on >> codeplex. That is
Re: [Mono-dev] State of aspnetwebstack on mono
On 2 November 2014 14:26, Kornel Pal 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 sol
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 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 > 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 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" 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 except
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 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 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 >> 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 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" 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 aroun
[Mono-dev] Review of PR1372 implement Request.GetBufferlessInputStream/GetBufferedInputStream methods
Hi All, I thought I'd break this into a separate review as there as has been some questions raised on it's validity. After reviewing, since we're implementing the change that forces the use of Request.InputStream over the GetBuffer* methods, the only people who will hit the MissingMethodException as those no following the correct convention. Therefore we can hold of on putting this in until all the other methods are there. Therefore I'm going to close this PR for now. If anyone has any other opinions, please let me know. Also, if you want to implement them, feel free. What I realised when trying to implement these is that the BufferlessInputStream needs to store things, or we need to get a second type BufferedInputStream. On top of this, I'm not sure of all the places where all the exceptions need to be raised etc. Finally, I'm not sure how to test this inside a unit test, so it seems like something that would be an "implement and hope" type PR. As it's not required for MVC, I'm pushing this down my list for now. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono and vNext, What is microsoft supporting
So, after thinking about this further. The question I have is not really
about CoreCLR.
What I want to know is, the libraries that Microsoft are making available
via their nuget (myget at the moment), are these going to be tested again
.net, mono and CoreCLR? I.e will the libraries be cross platform?
Thanks
Martin
I just asked about CoreCLR on Linux during today's ASP.NET vNext community
standup and the answer was:
"CoreCLR runs on Windows. On Linux you use Mono." (
https://www.youtube.com/watch?v=2oafQVI4Lx4#t=706)
That should clarify it pretty much :)
-- Alex
> From: alex.koeplin...@outlook.com
> To: monofo...@my2cents.co.uk; mono-devel-list@lists.ximian.com
> Date: Sat, 25 Oct 2014 21:52:59 +0200
> Subject: Re: [Mono-dev] Mono and vNext, What is microsoft supporting
>
> Note: the following is based on discussions with David Fowler (one of the
MS devs) et.al. in JabbR and other places. I'm not part of MS/vNext team or
Xamarin, so I may be totally wrong :)
>
>
>
> >> "CoreCLR is intended to be Windows-only too from what I've heard, as
it doesn't make much sense for Mono (you can already do side-by-side
deployment of Mono)."
> > Where have you seen this, do you have a link you can send? This is a
major missing piece of the puzzle for me. I've been hoping that with vNext,
applications would be truely cross platform, but it seems we are still very
much reliant on Mono's class implementations.
> > I've read an article[1] that says the CoreCLR ("Cloud Optimized") is to
be "Cross Platform". If that is the case, and there are no plans to make a
linux compatible version and just use mono, they could easily say the same
about the .NET 4.5 class libraries as they are available in mono.
>
>
> You should keep in mind that CoreCLR is just that - another runtime
implementation (they based this off of the old Silverlight runtime which
was side-by-side deployable). What they now put on top is the class
libraries distributed via NuGet, resulting in this self-contained
experience. As I said, it's just one of the options alongside .NET CLR and
Mono CLR, like this picture from your article shows:
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-84-75-metablogapi/7356.image_5F00_70B63F1D.png
(the article never says the CoreCLR is cross-platform, just the vNext
application itself)
>
>
> > So either, when Microsoft refer to "Cross platform", they are only
referring to applications that rely on no class libraries and only corlib
(is that a thing can an application be purely reliant on no class
libraries?). Alternatively, they are relying on Mono to create a CoreCLR (I
wouldn't be surprised if they've ask for Xamarin's help in doing that).
>
>
> The end result should be that you can run your app on .NET, CoreCLR and
Mono and the app doesn't care. The problem with the web frameworks like MVC
etc. up until now was that they were tightly coupled to System.Web, which
is not open-source and very difficult to reimplement in Mono (and to be
honest likely also lagged behind because Xamarin's focus is on mobile). The
new vNext stacks don't rely on System.Web anymore and just use the basic
class libraries that are well implemented on Mono too (like corlib,
System.Net etc. as they're important to Xamarin). It should be a much much
better experience given that Microsoft actively tests the vNext stack on
Mono. Now if **your** application code relies on something that isn't
implemented on Mono then that's a problem, sure.
>
>
> > I am aware that you can side-by-side in mono, however, I thought that
one of the other big benefits of vNext was the reduction in footprint,
specifically around the memory footprint per request. So you can opt-in/out
of specific features.
>
>
> Maybe they'll make this whole CoreCLR/small-footprint - experience
available on other OSs as well, but from what I've heard this is targeted
at Windows for now.
>
>
> -- Alex
> ___
> 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-dev] .NET Announcement
Hi All, I have no words... http://www.hanselman.com/blog/AnnouncingNET2015NETAsOpenSourceNETOnMacAndLinuxAndVisualStudioCommunity.aspx Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .NET Announcement
.NET is to be fully opensourced by Microsoft under the MIT Licence. On 12 November 2014 16:20, Gergely Buday wrote: > It is not available at the moment. Could you summarise? > > On 12 November 2014 17:10, Martin Thwaites > wrote: > >> Hi All, >> >> I have no words... >> >> >> http://www.hanselman.com/blog/AnnouncingNET2015NETAsOpenSourceNETOnMacAndLinuxAndVisualStudioCommunity.aspx >> >> 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] [Mono-list] Open source .NET and Mono.
Next stop... Visual Studio on Linux :D On 12 November 2014 19:45, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: mono-list-boun...@lists.ximian.com [mailto:mono-list- > > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza > > > > Hey guys, > > > > I posted details about the open sourcing of .NET and Mono on my blog. > > > > We have already started the work to integrate the .NET Framework code, > > and once I get back to Boston after the event we will check in the > > results. That is the reason we did not want to take the large #ifdef > patch > > removal a couple of weeks ago. > > > > http://tirania.org/blog/archive/2014/Nov-12.html > > WAA - HOO!!! :-D > > Awesome, awesome. Thank you. :-D > ___ > 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] [Mono-list] Open source .NET and Mono.
I want Visual Studio, full, with all bells and whistles. As good as Xamarin Studio/MonoDevelop is, I'd much prefer full VS. I imagine that is likely to not be a reality for a long time. Having said that, I said the same about opensourcing the .NET framework, and just look how wrong I was on that front! On 12 November 2014 20:40, Daniel Espinosa wrote: > Xamarin Studio for Linux is comming soon!!! > > El mié, 12 de nov 2014 a las 2:38 , Martin Thwaites < > monofo...@my2cents.co.uk> escribió: > > Next stop... Visual Studio on Linux :D > > On 12 November 2014 19:45, Edward Ned Harvey (mono) < > edward.harvey.m...@clevertrove.com> wrote: > >> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list- >> > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza >> > >> > Hey guys, >> > >> > I posted details about the open sourcing of .NET and Mono on my blog. >> > >> > We have already started the work to integrate the .NET Framework code, >> > and once I get back to Boston after the event we will check in the >> > results. That is the reason we did not want to take the large #ifdef >> patch >> > removal a couple of weeks ago. >> > >> > http://tirania.org/blog/archive/2014/Nov-12.html >> >> WAA - HOO!!! :-D >> >> Awesome, awesome. Thank you. :-D >> ___ >> 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] [Mono-list] Open source .NET and Mono.
Miljkenko, I'm not sure you understand how Xamarin studio works. It works on Windows, even for iPhone development, you just need to push to a Mac build server if you want to run it/build it. Therefore Xamarin Studio (with iOS) would probably be possible on linux in the same way it is on Windows. That said, Xamarin has publicly said that there aren't plans for it at the moment (can't remember where, probably on this list, or their forum). Martin On 12 November 2014 20:43, Miljenko Cvjetko wrote: > > On 20141112 21:40 , Daniel Espinosa wrote: > > Xamarin Studio for Linux is comming soon!!! > > Remeber MonoDevelop? > > MonoDevelop is not dead it is the core of XS, so it is there. If you mean > on Xamarin.Android support that is another story. > Xamarin.iOS will be NO-GO because of Apple's requirement to have mac for > iOS, Mac development. > > regards > > Mel > > > El mié, 12 de nov 2014 a las 2:38 , Martin Thwaites > escribió: > > Next stop... Visual Studio on Linux :D > > On 12 November 2014 19:45, Edward Ned Harvey (mono) < > edward.harvey.m...@clevertrove.com> wrote: > >> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list- >> > boun...@lists.ximian.com] On Behalf Of Miguel de Icaza >> > >> > Hey guys, >> > >> > I posted details about the open sourcing of .NET and Mono on my blog. >> > >> > We have already started the work to integrate the .NET Framework code, >> > and once I get back to Boston after the event we will check in the >> > results. That is the reason we did not want to take the large #ifdef >> patch >> > removal a couple of weeks ago. >> > >> > http://tirania.org/blog/archive/2014/Nov-12.html >> >> WAA - HOO!!! :-D >> >> Awesome, awesome. Thank you. :-D >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > > > ___ > Mono-devel-list mailing > listMono-devel-list@lists.ximian.comhttp://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] Crash course on bringing .NET open sourced code to Mono.
Hi Miguel, Is there an ETA on merging your "large fork". I don't want to get started on anything that you guys have already done? Or could you tell us which areas to stay away from for now? Personally, I would want to look at some of the system.web things. Thanks Martin On 15 Nov 2014 03:07, "Miguel de Icaza" wrote: > Hey guys, > > Sami reached out to me, and was wondering how to get started in bringing > some code to Mono, in particular WCF to Mono. So I wrote this small guide > for newcomers. > > I would say it takes a couple of steps: > >- Build your own local version of Mono on Linux. >- Make sure it works "mcs" should be able to run after installing it. >- Run a trivial self-hosted WCF server/client >- Make a trivial change to the WCF class library, and install this >version to test you can make changes locally and have them run: > - cd mono/mcs/class/System.ServiceModel > - Make changes > - make install > - Run your test again in another window > - Repeat >- Make sure you can run the test suite: > - cd mono/mcs/class/System.ServiceModel > - make run-test-local > > Once you are ready, you can start importing code. Ideally, you want to > go for high-value targets: the most buggy parts of Mono's stack (you can > check bugzilla for reports on memory usage, bugs). Or you can pick a > missing feature. > > To import code, modify the relevant ".sources" file in the > System.ServiceModel directory (where you ran the test) and replace a local > file, with a reference to the "referencesource". > > Chances are, you will need to make changes to the "referencesource" code, > since a lot of it is Windows specific. > > Miguel > > > On Fri, Nov 14, 2014 at 5:25 PM, Sami Ben Grine < > sben-gr...@axarosenberg.com> wrote: > >> Sweet – is there anything I can do to make progress? >> >> >> >> I am somewhat ignorant about Mono but I am pretty ok with .NET and Linux. >> >> >> >> thanks >> >> >> > ___ > 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] Crash course on bringing .NET open sourced code to Mono.
So has it been merged yet? I'm going to look at the Buffer stuff I shy'd away from before. Then look at the MachineKey.Protect stuff to implement the things I missed. I've got a separate question around the mismatch in conventions, but I'll ask that on a different thread. I'm struggling to contain my excitement at the moment! Thanks, Martin On 15 November 2014 13:03, Miguel de Icaza wrote: > Hello, > > We worked only on System.Configuration, regex, the crypto and web stack. > > The rest you can do, including the web stack. > > I took a look at asp.net. I think in the long term we want to replace > most of it, but it needs to be done in stages, as it still contains a bunch > of native stuff.m > > > > Miguel > > On Saturday, November 15, 2014, Martin Thwaites > wrote: > >> Hi Miguel, >> >> Is there an ETA on merging your "large fork". I don't want to get >> started on anything that you guys have already done? >> >> Or could you tell us which areas to stay away from for now? Personally, >> I would want to look at some of the system.web things. >> >> Thanks >> Martin >> On 15 Nov 2014 03:07, "Miguel de Icaza" wrote: >> >>> Hey guys, >>> >>> Sami reached out to me, and was wondering how to get started in bringing >>> some code to Mono, in particular WCF to Mono. So I wrote this small guide >>> for newcomers. >>> >>> I would say it takes a couple of steps: >>> >>>- Build your own local version of Mono on Linux. >>>- Make sure it works "mcs" should be able to run after installing it. >>>- Run a trivial self-hosted WCF server/client >>>- Make a trivial change to the WCF class library, and install this >>>version to test you can make changes locally and have them run: >>> - cd mono/mcs/class/System.ServiceModel >>> - Make changes >>> - make install >>> - Run your test again in another window >>> - Repeat >>>- Make sure you can run the test suite: >>> - cd mono/mcs/class/System.ServiceModel >>> - make run-test-local >>> >>> Once you are ready, you can start importing code. Ideally, you want to >>> go for high-value targets: the most buggy parts of Mono's stack (you can >>> check bugzilla for reports on memory usage, bugs). Or you can pick a >>> missing feature. >>> >>> To import code, modify the relevant ".sources" file in the >>> System.ServiceModel directory (where you ran the test) and replace a local >>> file, with a reference to the "referencesource". >>> >>> Chances are, you will need to make changes to the "referencesource" >>> code, since a lot of it is Windows specific. >>> >>> Miguel >>> >>> >>> On Fri, Nov 14, 2014 at 5:25 PM, Sami Ben Grine < >>> sben-gr...@axarosenberg.com> wrote: >>> >>>> Sweet – is there anything I can do to make progress? >>>> >>>> >>>> >>>> I am somewhat ignorant about Mono but I am pretty ok with .NET and >>>> Linux. >>>> >>>> >>>> >>>> thanks >>>> >>>> >>>> >>> ___ >>> 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-dev] Coding conventions when porting MS code.
Hi All, I'm looking into porting some code over from the reference source, and I've noticed that it doesn't match the mono coding conventions. Things like spaces instead of tabs, no space before the opening bracket in a method call etc. They seem like minor things, so I'm curious what the stance should be? Maybe it's 2 rules? if you port the entire file without changes, it's ok to keep with MS conventions? if you are porting individual methods you need to match the surrounding code? Also, if you are porting an entire file, should the Microsoft copyright header be retained? I'm sure there are other things, so there probably needs to be a section on the site to cover the rules around porting from the reference source. Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coding conventions when porting MS code.
So is the plan to pull the repository in as a submodule to reference the files? Maybe we could that part committed so we can start referencing the files? I'm not sure how a partial class approach would work (all the MS Classes seem to not be partials), so if you could maybe provide some examples of this I would be very interested. On 15 November 2014 14:49, Miguel de Icaza wrote: > Most of the time we just "reference" the file, so we shouldn't make style > changes to it. > > In the cases where we only bring bits, we have a spectrum of options from > using partial classes to having to copy-paste and only in hat case we would > reformat > > > On Saturday, November 15, 2014, Martin Thwaites > wrote: > >> Hi All, >> >> I'm looking into porting some code over from the reference source, and >> I've noticed that it doesn't match the mono coding conventions. >> >> Things like spaces instead of tabs, no space before the opening bracket >> in a method call etc. >> >> They seem like minor things, so I'm curious what the stance should be? >> >> Maybe it's 2 rules? if you port the entire file without changes, it's ok >> to keep with MS conventions? if you are porting individual methods you need >> to match the surrounding code? >> >> Also, if you are porting an entire file, should the Microsoft copyright >> header be retained? >> >> I'm sure there are other things, so there probably needs to be a section >> on the site to cover the rules around porting from the reference source. >> >> Thanks, >> Martin >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Crash course on bringing .NET open sourced code to Mono.
Thanks Miguel, That clears up a lot. I'll wait until Monday before I ask more questions :-D enjoy the weekend. Martin On 15 November 2014 15:58, Miguel de Icaza wrote: > Let me give more color on the situation. > > Tasks: > >- *Not building the 2.0 Profile*: while this is a very simple change, >it currently breaks the F# compilation. I have to dig out the reasons, I >can not remember why, but it does. Something related to MSBuild targets or >something. > >- *Removal of the #ifdef junk for old profiles: *this will make it >hard to merge our changes later, so I rather not have to do this for now. >In addition, a tool was used, so we can just use the tool in the future. > >- *Adding .NET Reference Code to Mono:* for all the bits that have >started trickling out, we can use the approach described earlier. I >should probably formalize the process in a document. This does not really >require either one of the previous tasks, in general, it is easy to add >#ifs temporarily. > > In addition to the list mentioned before, we also need to formalize/review > the following: > >- *DEFINE use in .NET's code:* we can not just take the code blindly, >we need to review that every file that is incorporated also defines the >proper defines in the build, or we would end up with a build that is not >correct. > >- *Put together a priority list:* this is merely a list of the most >valuable pieces of code that we want to incorporate into Mono. The ones >that bring the most bang for the buck to the Mono community. > >*Note:* this is independent of anyone picking a task they care about, >and just running with it. This is just a public list of things we should >look into. > >- *Process to port Windows code:* there seems to be a lot more native >code that I even expected. So in many cases, we can not blindly copy the >code without regressing at a later time. So each replacement need to be >evaluated. Let us put together a checklist. > > I am taking care of the kids on the weekend, but will start writing some > of these in the nights and hope to publish on Monday on the web site. > Then anyone can contribute to the guidelines by making changes to the > website module on github. > > Miguel > > On Sat, Nov 15, 2014 at 10:37 AM, Miguel de Icaza > wrote: > >> Hey, >> >> It is a tangential problem. >> >> The big problem with removing the profile right now, is that removing it >> causes F# to fail building. >> >> We are trying to fix that. >> >> Miguel >> >> On Sat, Nov 15, 2014 at 10:05 AM, Kornel Pal wrote: >> >>> Given these obstacles, I think that going forward with the originally >>> announced plan of removing non-4.5 profile support from the current Mono >>> code base - without introducing MS code yet - would make the gradual >>> adoption of MS code much easer. >>> >>> >>> On 11/15/2014 2:11 PM, Miguel de Icaza wrote: >>> >>> It hasn't. When we do, we will announce. >>> >>> >>> Two issues: we worked with reference source and the github push is >>> only slowly getting the bits. And the second is that the layout they are >>> pushing is different. >>> >>> On Saturday, November 15, 2014, Martin Thwaites < >>> monofo...@my2cents.co.uk> wrote: >>> >>>> So has it been merged yet? >>>> >>>> I'm going to look at the Buffer stuff I shy'd away from before. Then >>>> look at the MachineKey.Protect stuff to implement the things I missed. >>>> >>>> I've got a separate question around the mismatch in conventions, but >>>> I'll ask that on a different thread. >>>> >>>> I'm struggling to contain my excitement at the moment! >>>> >>>> Thanks, >>>> Martin >>>> >>>> On 15 November 2014 13:03, Miguel de Icaza wrote: >>>> >>>>> Hello, >>>>> >>>>> We worked only on System.Configuration, regex, the crypto and web >>>>> stack. >>>>> >>>>> The rest you can do, including the web stack. >>>>> >>>>> I took a look at asp.net. I think in the long term we want to >>>>> replace most of it, but it needs to be done in stages, as it still >>>>> contains >>>>> a bunch of native stuff.m >>>>> >>>>> >>>>> >>>
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
HI Miguel, Thanks, exactly what I've been waiting for! I only really have 1 question. In the ways that we are going to port things, you mention pulling in the entire assembly. How exactly would you be thinking this would work? try building and fixing anything that it depends from other libraries in the other libraries? or are you going to fork the reference source, submodule it, reference all the files in the .sources files within mono, then fix (i.e. add #ifdefs etc.) to the fork? Essentially, are you thinking that there will be an assembly that can simply be copied without changes in the above circumstance? Thanks, Martin On 19 November 2014 17:48, Miguel de Icaza wrote: > Hey guys, > > As promised, the plans: > > http://www.mono-project.com/docs/about-mono/dotnet-integration/ > > If you start work on something, please notify the list, and update the > Trello board: > > https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono > > Miguel > > ___ > Mono-list maillist - mono-l...@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hi Miguel, That sounds good. In terms of System.Web then, would you prefer your internal team does it? or am I ok to start replacing some files when the sub-module is added? I was thinking of trying to hit the HttpApplication class first and work my way out from there. Thanks, Martin On 19 November 2014 19:41, Miguel de Icaza wrote: > Hey, > > I do not think we would be moving the code. We would do two things: > > >- Make changes to the fork in mono/referencesoure >- Reference the new files from mono/external/referencesource > > Miguel > > On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites > wrote: > >> HI Miguel, >> >> Thanks, exactly what I've been waiting for! I only really have 1 >> question. >> >> In the ways that we are going to port things, you mention pulling in the >> entire assembly. How exactly would you be thinking this would work? try >> building and fixing anything that it depends from other libraries in the >> other libraries? or are you going to fork the reference source, submodule >> it, reference all the files in the .sources files within mono, then fix >> (i.e. add #ifdefs etc.) to the fork? >> >> Essentially, are you thinking that there will be an assembly that can >> simply be copied without changes in the above circumstance? >> >> Thanks, >> Martin >> >> On 19 November 2014 17:48, Miguel de Icaza wrote: >> >>> Hey guys, >>> >>> As promised, the plans: >>> >>> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >>> >>> If you start work on something, please notify the list, and update the >>> Trello board: >>> >>> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >>> >>> Miguel >>> >>> ___ >>> Mono-list maillist - mono-l...@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-list >>> >>> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Will do, I'm on "Gardening leave" for the next week, so I've got sometime to look at it. Do you have an ETA on when the fork will be created and the sub-module added? On 19 November 2014 20:50, Miguel de Icaza wrote: > Hey, > > Xamarin's team is not likely going to do System.Web, so feel free to step > in. > > I am not sure if we can bring System.Web as a whole yet, I think it is a > clear case of something that will have to be done in steps and starting > with HttpApplication is as good as an idea as antyhing else. > > On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites > wrote: > >> Hi Miguel, >> >> That sounds good. >> >> In terms of System.Web then, would you prefer your internal team does it? >> or am I ok to start replacing some files when the sub-module is added? I >> was thinking of trying to hit the HttpApplication class first and work my >> way out from there. >> >> Thanks, >> Martin >> >> On 19 November 2014 19:41, Miguel de Icaza wrote: >> >>> Hey, >>> >>> I do not think we would be moving the code. We would do two things: >>> >>> >>>- Make changes to the fork in mono/referencesoure >>>- Reference the new files from mono/external/referencesource >>> >>> Miguel >>> >>> On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites < >>> monofo...@my2cents.co.uk> wrote: >>> >>>> HI Miguel, >>>> >>>> Thanks, exactly what I've been waiting for! I only really have 1 >>>> question. >>>> >>>> In the ways that we are going to port things, you mention pulling in >>>> the entire assembly. How exactly would you be thinking this would work? >>>> try building and fixing anything that it depends from other libraries in >>>> the other libraries? or are you going to fork the reference source, >>>> submodule it, reference all the files in the .sources files within mono, >>>> then fix (i.e. add #ifdefs etc.) to the fork? >>>> >>>> Essentially, are you thinking that there will be an assembly that can >>>> simply be copied without changes in the above circumstance? >>>> >>>> Thanks, >>>> Martin >>>> >>>> On 19 November 2014 17:48, Miguel de Icaza wrote: >>>> >>>>> Hey guys, >>>>> >>>>> As promised, the plans: >>>>> >>>>> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >>>>> >>>>> If you start work on something, please notify the list, and update the >>>>> Trello board: >>>>> >>>>> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >>>>> >>>>> Miguel >>>>> >>>>> ___ >>>>> Mono-list maillist - mono-l...@lists.ximian.com >>>>> http://lists.ximian.com/mailman/listinfo/mono-list >>>>> >>>>> >>>> >>> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Hi Miguel, Have you come up with a plan on how to implement the resource methodology that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we just going to implement some partial class that we can add extend for each assembly? Theres loads throughout HttpApplication. Thanks, Martin On 19 November 2014 21:02, Martin Thwaites wrote: > Will do, I'm on "Gardening leave" for the next week, so I've got sometime > to look at it. > > Do you have an ETA on when the fork will be created and the sub-module > added? > > On 19 November 2014 20:50, Miguel de Icaza wrote: > >> Hey, >> >> Xamarin's team is not likely going to do System.Web, so feel free to step >> in. >> >> I am not sure if we can bring System.Web as a whole yet, I think it is a >> clear case of something that will have to be done in steps and starting >> with HttpApplication is as good as an idea as antyhing else. >> >> On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites < >> monofo...@my2cents.co.uk> wrote: >> >>> Hi Miguel, >>> >>> That sounds good. >>> >>> In terms of System.Web then, would you prefer your internal team does >>> it? or am I ok to start replacing some files when the sub-module is added? >>> I was thinking of trying to hit the HttpApplication class first and work my >>> way out from there. >>> >>> Thanks, >>> Martin >>> >>> On 19 November 2014 19:41, Miguel de Icaza wrote: >>> >>>> Hey, >>>> >>>> I do not think we would be moving the code. We would do two things: >>>> >>>> >>>>- Make changes to the fork in mono/referencesoure >>>>- Reference the new files from mono/external/referencesource >>>> >>>> Miguel >>>> >>>> On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites < >>>> monofo...@my2cents.co.uk> wrote: >>>> >>>>> HI Miguel, >>>>> >>>>> Thanks, exactly what I've been waiting for! I only really have 1 >>>>> question. >>>>> >>>>> In the ways that we are going to port things, you mention pulling in >>>>> the entire assembly. How exactly would you be thinking this would work? >>>>> try building and fixing anything that it depends from other libraries in >>>>> the other libraries? or are you going to fork the reference source, >>>>> submodule it, reference all the files in the .sources files within mono, >>>>> then fix (i.e. add #ifdefs etc.) to the fork? >>>>> >>>>> Essentially, are you thinking that there will be an assembly that can >>>>> simply be copied without changes in the above circumstance? >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> On 19 November 2014 17:48, Miguel de Icaza wrote: >>>>> >>>>>> Hey guys, >>>>>> >>>>>> As promised, the plans: >>>>>> >>>>>> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >>>>>> >>>>>> If you start work on something, please notify the list, and update >>>>>> the Trello board: >>>>>> >>>>>> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >>>>>> >>>>>> Miguel >>>>>> >>>>>> ___ >>>>>> Mono-list maillist - mono-l...@lists.ximian.com >>>>>> http://lists.ximian.com/mailman/listinfo/mono-list >>>>>> >>>>>> >>>>> >>>> >>> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
So just replace them with static strings via a script? or create an individual class somewhere and simply add to it as we implement new classes from the referencesource? On 19 November 2014 22:50, Miguel de Icaza wrote: > I was thinking we just use a perl script ;-) > > On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites > wrote: > >> Hi Miguel, >> >> Have you come up with a plan on how to implement the resource methodology >> that's used for strings? i.e. the SR.GetString(SR.Name) type stuff? Are we >> just going to implement some partial class that we can add extend for each >> assembly? Theres loads throughout HttpApplication. >> >> Thanks, >> Martin >> >> On 19 November 2014 21:02, Martin Thwaites >> wrote: >> >>> Will do, I'm on "Gardening leave" for the next week, so I've got >>> sometime to look at it. >>> >>> Do you have an ETA on when the fork will be created and the sub-module >>> added? >>> >>> On 19 November 2014 20:50, Miguel de Icaza wrote: >>> >>>> Hey, >>>> >>>> Xamarin's team is not likely going to do System.Web, so feel free to >>>> step in. >>>> >>>> I am not sure if we can bring System.Web as a whole yet, I think it is >>>> a clear case of something that will have to be done in steps and starting >>>> with HttpApplication is as good as an idea as antyhing else. >>>> >>>> On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites < >>>> monofo...@my2cents.co.uk> wrote: >>>> >>>>> Hi Miguel, >>>>> >>>>> That sounds good. >>>>> >>>>> In terms of System.Web then, would you prefer your internal team does >>>>> it? or am I ok to start replacing some files when the sub-module is added? >>>>> I was thinking of trying to hit the HttpApplication class first and work >>>>> my >>>>> way out from there. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> On 19 November 2014 19:41, Miguel de Icaza wrote: >>>>> >>>>>> Hey, >>>>>> >>>>>> I do not think we would be moving the code. We would do two things: >>>>>> >>>>>> >>>>>>- Make changes to the fork in mono/referencesoure >>>>>>- Reference the new files from mono/external/referencesource >>>>>> >>>>>> Miguel >>>>>> >>>>>> On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites < >>>>>> monofo...@my2cents.co.uk> wrote: >>>>>> >>>>>>> HI Miguel, >>>>>>> >>>>>>> Thanks, exactly what I've been waiting for! I only really have 1 >>>>>>> question. >>>>>>> >>>>>>> In the ways that we are going to port things, you mention pulling in >>>>>>> the entire assembly. How exactly would you be thinking this would work? >>>>>>> try building and fixing anything that it depends from other libraries in >>>>>>> the other libraries? or are you going to fork the reference source, >>>>>>> submodule it, reference all the files in the .sources files within mono, >>>>>>> then fix (i.e. add #ifdefs etc.) to the fork? >>>>>>> >>>>>>> Essentially, are you thinking that there will be an assembly that >>>>>>> can simply be copied without changes in the above circumstance? >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>>> >>>>>>> On 19 November 2014 17:48, Miguel de Icaza >>>>>>> wrote: >>>>>>> >>>>>>>> Hey guys, >>>>>>>> >>>>>>>> As promised, the plans: >>>>>>>> >>>>>>>> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >>>>>>>> >>>>>>>> If you start work on something, please notify the list, and update >>>>>>>> the Trello board: >>>>>>>> >>>>>>>> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >>>>>>>> >>>>>>>> Miguel >>>>>>>> >>>>>>>> ___ >>>>>>>> Mono-list maillist - mono-l...@lists.ximian.com >>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-list >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
Great, so we're going to dump that as a class in the main codebase somewhere? Do we have a place where this sort of thing normally goes? On 19 November 2014 23:09, Miguel de Icaza wrote: > The following script: > > git grep 'SR\.[A-Za-z_]*' | sed -e 's/SR.GetString//' | grep SR. | sed > -e 's/.*SR\.//' -e 's/[,)};].*//' | sort | uniq | sed 's/\(.*\)/public > const string \1 = "\1";/' > > Generated this: > > https://gist.github.com/migueldeicaza/d130779095f377cdcf90 > > On Wed, Nov 19, 2014 at 5:50 PM, Miguel de Icaza > wrote: > >> I was thinking we just use a perl script ;-) >> >> On Wed, Nov 19, 2014 at 5:48 PM, Martin Thwaites < >> monofo...@my2cents.co.uk> wrote: >> >>> Hi Miguel, >>> >>> Have you come up with a plan on how to implement the resource >>> methodology that's used for strings? i.e. the SR.GetString(SR.Name) type >>> stuff? Are we just going to implement some partial class that we can add >>> extend for each assembly? Theres loads throughout HttpApplication. >>> >>> Thanks, >>> Martin >>> >>> On 19 November 2014 21:02, Martin Thwaites >>> wrote: >>> >>>> Will do, I'm on "Gardening leave" for the next week, so I've got >>>> sometime to look at it. >>>> >>>> Do you have an ETA on when the fork will be created and the sub-module >>>> added? >>>> >>>> On 19 November 2014 20:50, Miguel de Icaza wrote: >>>> >>>>> Hey, >>>>> >>>>> Xamarin's team is not likely going to do System.Web, so feel free to >>>>> step in. >>>>> >>>>> I am not sure if we can bring System.Web as a whole yet, I think it is >>>>> a clear case of something that will have to be done in steps and starting >>>>> with HttpApplication is as good as an idea as antyhing else. >>>>> >>>>> On Wed, Nov 19, 2014 at 2:50 PM, Martin Thwaites < >>>>> monofo...@my2cents.co.uk> wrote: >>>>> >>>>>> Hi Miguel, >>>>>> >>>>>> That sounds good. >>>>>> >>>>>> In terms of System.Web then, would you prefer your internal team does >>>>>> it? or am I ok to start replacing some files when the sub-module is >>>>>> added? >>>>>> I was thinking of trying to hit the HttpApplication class first and work >>>>>> my >>>>>> way out from there. >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>>> >>>>>> On 19 November 2014 19:41, Miguel de Icaza >>>>>> wrote: >>>>>> >>>>>>> Hey, >>>>>>> >>>>>>> I do not think we would be moving the code. We would do two things: >>>>>>> >>>>>>> >>>>>>>- Make changes to the fork in mono/referencesoure >>>>>>>- Reference the new files from mono/external/referencesource >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> On Wed, Nov 19, 2014 at 2:26 PM, Martin Thwaites < >>>>>>> monofo...@my2cents.co.uk> wrote: >>>>>>> >>>>>>>> HI Miguel, >>>>>>>> >>>>>>>> Thanks, exactly what I've been waiting for! I only really have 1 >>>>>>>> question. >>>>>>>> >>>>>>>> In the ways that we are going to port things, you mention pulling >>>>>>>> in the entire assembly. How exactly would you be thinking this would >>>>>>>> work? >>>>>>>> try building and fixing anything that it depends from other libraries >>>>>>>> in >>>>>>>> the other libraries? or are you going to fork the reference source, >>>>>>>> submodule it, reference all the files in the .sources files within >>>>>>>> mono, >>>>>>>> then fix (i.e. add #ifdefs etc.) to the fork? >>>>>>>> >>>>>>>> Essentially, are you thinking that there will be an assembly that >>>>>>>> can simply be copied without changes in the above circumstance? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin >>>>>>>> >>>>>>>> On 19 November 2014 17:48, Miguel de Icaza >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey guys, >>>>>>>>> >>>>>>>>> As promised, the plans: >>>>>>>>> >>>>>>>>> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >>>>>>>>> >>>>>>>>> If you start work on something, please notify the list, and update >>>>>>>>> the Trello board: >>>>>>>>> >>>>>>>>> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >>>>>>>>> >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> ___ >>>>>>>>> Mono-list maillist - mono-l...@lists.ximian.com >>>>>>>>> http://lists.ximian.com/mailman/listinfo/mono-list >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Porting HttpApplication and associated classes
Hi All, I'm planning on taking on the porting of part of System.Web, so I thought I would make people aware so that we're not all working on the same thing. My process is to start with importing HttpApplication in it's entirety, then pull in the surrounding classes so it compiles. I can then start running some tests to see how close we are. Until the fork is in, I've copied them into my local instance, and changing them there, so the sooner we get the fork setup the better. So far, I've noted that there are a few things that this work will be dependent on. First, we need to the fork and sub-module up and running for the reference source, so I can doing pull requests on there. Second, come up with a way to exclude code without deleting it (I'm assuming we won't to go down the #ifdef route rather than simply removing the code from the fork). I'm thinking there's probably something we can use already, so just need to know what that is. (something like #if !MONO ??) Third, Miguel had an idea of how to do the String resources so we don't need to refactor large amounts of the referencesource. The script needs work, and is probably a job in it's own right. Finally, as I won't be replacing every file, some will just have large amounts of additions/fixes, it's probably worth getting the legacy #ifdef's before I send a pull. I have around a week to get this done, if I don't manage to get it completed, I will be able to do some work, just not full-time. I will however make my fork available for people to continue it. Please let me know your thoughts, and if you think there may be a better way to do this. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting HttpApplication and associated classes
Thanks Miguel, I'll get started properly tonight. So the DEFINE will be #if !CROSS_PLATFORM to exclude anything that is native and won't work on non-windows? On 20 November 2014 13:27, Miguel de Icaza wrote: > >> First, we need to the fork and sub-module up and running for the >> reference source, so I can doing pull requests on there. >> > > The referencesource submodule is there > > >> Second, come up with a way to exclude code without deleting it (I'm >> assuming we won't to go down the #ifdef route rather than simply removing >> the code from the fork). I'm thinking there's probably something we can >> use already, so just need to know what that is. (something like #if !MONO >> ??) >> > > We should introduce a define, yes. > > Perhaps we can introduce a "CROSS_PLATFORM" define that we use on the > Reference source to annotate those cases. > > Third, Miguel had an idea of how to do the String resources so we don't >> need to refactor large amounts of the referencesource. The script needs >> work, and is probably a job in it's own right. >> > > That will get you running for now ;) > > Finally, as I won't be replacing every file, some will just have large >> amounts of additions/fixes, it's probably worth getting the legacy #ifdef's >> before I send a pull. >> > > Nah, I think it is easy. > > The way you replace a class, is to remove the file from the .sources and > add the new one. That should cover most bases. > > Miguel > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
In terms of the "mono download", are you referring to a git clone? or the source tarball? In terms of clone, I'd say it's valid to be there, they may not change often but it would be good to see the version history within that fork, rather than having to compare across mono and the fork. However, for the tarball, we could strip out the files that aren't required with some kind of clever script. On 21 November 2014 18:35, Miguel de Icaza wrote: > Follow up. > > I am wondering if we should submodule the reference source, or just copy > the files? > > The module wont be updated frequently, and it is making the Mono download > a lot longer than it needs to be. > > Miguel > > On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza > wrote: > >> Hey guys, >> >> As promised, the plans: >> >> http://www.mono-project.com/docs/about-mono/dotnet-integration/ >> >> If you start work on something, please notify the list, and update the >> Trello board: >> >> https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono >> >> Miguel >> > > > ___ > Mono-list maillist - mono-l...@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] .NET Reference source terminology
Hi All, Has anyone got any idea what FEATURE_PAL is? It's a define, and seems to have a lot of comments around IIS, and that if it's Enabled, then don't do IIS stuff. Seems like something that we could just add in our stuff to exclude alot of windows specific stuff without having to add our own defines? e.g. https://github.com/Microsoft/referencesource/blob/fa352bbcac7dd189f66546297afaffc98f6a7d15/System.Web/HttpRuntime.cs#L139 The best explanation I've seen says it's the "Platform Adaptation Layer", and is to do with compiling it for other architectures such as ARM. Seems like something that we would want to enable? I'm sure there will be others, so do we think it's worth putting up a glossary on the mono site? Thanks, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
On 27 November 2014 at 18:19, Alexander Köplinger < alex.koeplin...@outlook.com> wrote: > > > > * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source > and on NuGet, should be used from there > > > I am actually not sure about this one, is that really the case? > > > The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, > so I think it should be fine to remove. It might not work perfectly until > the System.Web from referencesource is integrated, but the same applies to > the existing (outdated) copy we ship currently. > > This is something I've been working on. MVC 5.2.2 (the one available on NuGet) just doesn't work at the moment due to this pull https://github.com/mono/mono/pull/1349 being required (and I haven't had chance to fix the things that Miguel wanted). In addition, the old notes on getting MVC 3 working on mono, said to remove the MS supplied versions of the dlls IIRC, so these would stop working on upgrade (and replacing with the nuget ones for MVC3 probably won't work). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
Do we not have a flag for if it's compiled for tests, rather than release? On 14 Dec 2014 05:14, "Edward Ned Harvey (mono)" < edward.harvey.m...@clevertrove.com> wrote: > > From: Miguel de Icaza [mailto:mig...@xamarin.com] > > > > We would love a test case to add to the test suite. > > > > We are building a new test suite as part of this work anyways. > > This is almost done. Granted it is microscopic in scope - the test I've > written tests only for the case that I know fails; it's far from being a > generalized test for the SslStream class as a whole. > > Quick question: > > I'd like to make the behavior different on mono and .Net. Particularly, > I've generated a junk root CA, and on mono I'd like to use > > Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Import(junkRootCert); > To programatically import that cert momentarily for the scope of the test > (and subsequently remove it). > > Obviously, this doesn't exist in .Net. And as far as I know there is no > way to programatically import a root CA in .Net. > > So is there some #ifdef clause I can use to detect if this is mono or .Net? > > I searched the other test classes, and there's RUN_ONDOTNET, but I'm not > certain it's the right thing for the job. > ___ > 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
