Re: [Mono-list] Trying to authenticate users against Active Directory from Mono

[Martin Thwaites]

I think you'll struggle with this.  Authenticating with a 403 challenge (as
in NTLM) may not work on the linux.  You may be able to try doing the
concurrent bind about the domain with the credentials, but I doubt you'll
get it in the same way as windows authentication works in IIS.

A better option would be to implement an ADFS server in your domain, and
accept users using a SAML response.  There are various libraries out there
that do that, not sure which work on mono, but they use standard libraries
so I can't imagine it would be that hard.  We use Kentor.AuthServices on
windows, but I would imagine it would work on Mono.

On 23 June 2016 at 11:57, James Allsopp 
wrote:

> Hello,
> I'm trying to authenticate users of an Asp.Net MVC4 site against an Active
> Directory Server. The site's going to be running on CentOS 7 running nginx.
>
> I've managed to use the Novell.Directory.LDAP code to successfully query a
> OpenDS LDAP test server, and I've used LDAPAdmin to connect to the main AD
> server, but this required the GSSAPI option with "Use current user
> credentials" option. I have no idea how to supply this from Mono.
>
> Once I've done this, I've then no idea how I should reimplement the
> "PrincipalContext.ValidateCredentials" method using the Novell code.
>
> If anyone can offer any suggestions, I would be very grateful,
>
> Thanks,
> James
>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Behavior change in XmlWriterSettings/XmlTextWriter

[Martin Thwaites]

I'd have to agree with Martin here.  The output of 2 functions should
surely match.  The fact that the referencesource uses something that
defaults to something different per platform should be irrelevant.

The only point to consider is, should the output of a method be able to
differ per platform and still be valid.  For this situation I imagine that
the xaml that is being produced is invalid, and therefore the behaviour for
the xaml writer is incorrect.
On 29 Sep 2015 05:55, "Atsushi Eno" 
wrote:

> You have no reason to be afraid of asking Microsoft to change the
> behavior. I cannot find any justification to just ask Mono to change
> things against Microsoft code behavior without asking Microsoft about it.
>
> Atsushi Eno
>
> On 2015年09月29日 01:15, Martin Potter wrote:
> > I wasn’t aware that the MSDN .NET documentation was viewed as being
> > platform specific documentation.
> >
> > I am not sure how this is a Microsoft bug so much as an issue with the
> > fact they did not consider it being run on other platforms. Given that
> > Mono is cross-platform, whereas Microsoft’s implementation is not, and
> > Mono has made other changes to the reference source (which is very
> Windows
> > specific) to provide consistency across platforms it is unclear as to why
> > the previous behavior of using \r\n (prior to the switch to the reference
> > source) is incorrect.
> >
> > ― Martin
> >
> > On 9/28/15, 9:58 AM, "Atsushi Eno"  >
> > wrote:
> >
> >> MSDN documentation describes the behavior how .NET Framework works on
> >> Windows, hence it says \r\n. As the referencesource is explicitly
> >> implemented, it is NOT the case on non-Windows platform.
> >>
> >> If you are unhappy about Microsoft behavior, you should file a bug to
> >> Microsoft. referencesource is not for reporting issues though (as its
> >> README explicitly says so).
> >>
> >> Atsushi Eno
> >>
> >> On 2015年09月28日 23:15, Martin Potter wrote:
> >>> The default for XamlWriterSettings NewLineChars was changed from "\r\n"
> >>> to
> >>> "\n" when you imported the reference source and is what is present on
> >>> the
> >>> 4.2 branch. This is not what the previous behavior was, nor what the
> >>> documentation on MSDN,
> >>>
> >>>
> https://msdn.microsoft.com/en-us/library/system.xml.xmlwritersettings.new
> >>> li
> >>> nechars(v=vs.110).aspx, states.
> >>>
> >>> "The character string to use for line breaks. This can be set to any
> >>> string value. However, to ensure valid XML, you should specify only
> >>> valid
> >>> white space characters, such as space characters, tabs, carriage
> >>> returns,
> >>> or line feeds. The default is \r\n (carriage return, new line)."
> >>>
> >>> ― Martin
> >>>
> >>> On 9/28/15, 8:08 AM, "Atsushi Eno"
> >>> 
> >>> wrote:
> >>>
>  Current Microsoft-based implementation is the correct one and it's
> been
>  there in post-4.0 versions.
> 
>  Atsushi Eno
> 
>  On 2015年09月28日 22:46, Martin Potter wrote:
> > Atsushi,
> >
> > Were you (or someone else) going to get this fixed before 4.2 is
> ready
> > to
> > ship?
> >
> > Thank you,
> > Martin
> >
> > On 9/8/15, 8:03 PM, "Atsushi Eno"
> > 
> > wrote:
> >
> >> I had no idea when that commit was made, but that change was wrong.
> >> Microsoft behavior is the one we should use in that case.
> >>
> >> Atsushi Eno
> >>
> >> On 2015年09月09日 01:50, Martin Potter wrote:
> >>> Way back in 2012, this commit
> >>>
> >>>
> >>>
> >>>
> https://github.com/mono/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3
> >>> e7
> >>> 74
> >>> 33b
> >>>
> >>>
> >>>
> >>> <
> https://github.com/LogosBible/mono/commit/9215ddf7ade5f0f0f54c2adb7b
> >>> 16
> >>> 5e
> >>> 4e3e77433b> changed
> >>> the default newline in XmlWriterSettings to be "\r\n” to be
> >>> compatible
> >>> with MS (which some of our tests rely on). It appears that when the
> >>> reference source was imported in
> >>>
> >>>
> >>>
> >>>
> https://github.com/mono/mono/commit/4990b4c47b8fe1b219c64884fad98d586
> >>> 15
> >>> 46
> >>> a05#diff-5561e6ab8de20ec168dcb1f7b415b353,
> >>> it was changed back to be platform specific. Was this an
> intentional
> >>> change?
> >>>
> >>> Thank you,
> >>> 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
> 

Re: [Mono-list] which confused about which mono

[Martin Thwaites]

do you have a mono version in ~/tmp/mono? if so it will use that first, but
i don;t think which takes into account your current directory.

On 1 May 2015 at 13:47, Matt Calder mvcal...@gmail.com wrote:

 I see odd inconsistencies when I run mono from the command line. Does
 anyone know what could cause this:

 calder@pharos:~/tmp/mono$ mono --version
 Mono JIT compiler version 3.2.7 ((no/1b62dca Thu Mar 13 21:13:52 PDT 2014)
 ...

 calder@pharos:~/tmp/mono$ which mono
 /usr/bin/mono

 calder@pharos:~/tmp/mono$ /usr/bin/mono --version
 Mono JIT compiler version 4.1.0 (master/3f87ade Fri May  1 07:50:52 EDT
 2015)
 ...

 I get errors installing mono after successfully building it, and I suspect
 they are related to the above. Here is the error during sudo make install:

 make[7]: Entering directory `/home/calder/tmp/mono/mcs/class/System'
 make intermediate=secxml/ ./../../class/lib/basic/secxml/System.dll
 make[8]: Entering directory `/home/calder/tmp/mono/mcs/class/System'
 MCS [secxml/basic] System.dll
 Corlib not in sync with this runtime: expected corlib version 130, found
 128.
 Loaded from: /usr/lib/mono/4.5/mscorlib.dll
 Download a newer corlib or a newer runtime at
 http://www.mono-project.com/download.
 make[8]: *** [../../class/lib/basic/secxml/System.dll] Error 1
 make[8]: Leaving directory `/home/calder/tmp/mono/mcs/class/System'

 Thanks for any help.

 Matt

 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Error compiling master - Dynamic does not exist

[Martin Thwaites]

Hi all,

I'm doing some work on mono, and everything was working fine until I did a
rebase against master, and now I'm getting an error when running make.  I
haven't touched anything at this level, so I don't think it's something
I've done, so thought I'd check first.

Bootstrap compiler: Mono C# compiler version 3.10.1.0
MCS [basic] basic.exe
dynamic.cs(17,7): error CS0234: The type or namespace name `Dynamic' does
not exist in the namespace `System'. Are you missing an assembly reference?
cs-parser.jay(144,8): error CS0246: The type or namespace name `Tuple'
could not be found. Are you missing an assembly reference?
assembly.cs(1186,94): error CS0246: The type or namespace name `Tuple'
could not be found. Are you missing an assembly reference?
dynamic.cs(75,12): error CS0246: The type or namespace name
`DynamicMetaObject' could not be found. Are you missing an assembly
reference?
dynamic.cs(77,34): error CS0246: The type or namespace name
`DynamicMetaObject' could not be found. Are you missing an assembly
reference?
dynamic.cs(88,10): error CS0246: The type or namespace name
`DynamicMetaObject' could not be found. Are you missing an assembly
reference?
eval.cs(69,31): error CS0246: The type or namespace name `Tuple' could not
be found. Are you missing an assembly reference?
eval.cs(849,12): error CS0246: The type or namespace name `Tuple' could not
be found. Are you missing an assembly reference?
ikvm.cs(234,17): error CS0246: The type or namespace name `Tuple' could not
be found. Are you missing an assembly reference?
location.cs(506,51): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(512,51): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(518,51): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(524,51): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(414,26): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(417,34): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(422,34): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(428,34): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
location.cs(434,34): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
settings.cs(88,15): error CS0246: The type or namespace name `Tuple' could
not be found. Are you missing an assembly reference?
statement.cs(4716,8): error CS0246: The type or namespace name `Tuple'
could not be found. Are you missing an assembly reference?

Thanks,
Martin
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-list] System.Web.Security.Membership causes an exception on mono platform

[Martin Thwaites]

Next suggestions...

We need to establish if you have a working mono version.

Can you install the latest packages from the mono repository?

http://www.mono-project.com/docs/getting-started/install/linux/#centos-fedora-and-derivatives

Then, try running the site using XSP directly.  Go to the directory in a
terminal window and type xsp4.

I'm really struggling to come up with reasons why a site would run MVC
methods, but won't run your site.

Could you put up your site somewhere that someone could download and try?

Thanks,
Martin

On 19 January 2015 at 14:55, Olli Heiskanen ohjelmistoarkkite...@gmail.com
wrote:

 Thanks a million for helping Martin, I've been stuck with this for a while
 and really need to get something working, or at least ways to dig up more
 information. I use VS for developing on a Win8 machine, on that everything
 works perfectly.

 And thank You Gonzalo for your suggestion, unfortunately changing
 /boacommander to / had no effect on the errors. I have the default httpd
 conf file, tried to disable file indexes by using Options -Indexes
 FollowSymLinks setting under Directory / but removing -Indexes did not
 have an effect on the errors.

 Yes, a MVC3 site created from a VS template without any changes anywhere
 is my fresh site.

 No, I haven't gotten any websites working, only a very simple empty web
 app without any functionality. Tried a WebForms, MVC3 and MVC4 apps so far.
 A simple empty web app without any functionality works fine.

 On my MVC sites if I have an action link like:
 @Html.ActionLink(About, About, Home)

 this works fine, I can navigate between pages, but whenever I'm posting a
 form, like registering a new user or logging in, I get the Failed to map
 path '/' -error. This seems like an extremely crucial error.

 cheers,
 Olli

 2015-01-18 2:17 GMT+02:00 Gonzalo Paniagua Javier gonzalo.m...@gmail.com
 :

 Hi Olli,

 Your MonoApplications line is:
MonoApplications boacommander /boacommander:/var/www/html/
 boacommander

 So there is no ASP.NET application configured for /, which is the error
 you are seeing.
 A possible fix is to change that to read:
   MonoApplications boacommander /:/var/www/html/boacommander

 Or set up something else on / that just redirects to /boacommander.

 -Gonzalo



 On Sat, Jan 17, 2015 at 2:20 AM, Olli Heiskanen 
 ohjelmistoarkkite...@gmail.com wrote:

 Hello,

 A little more information on this:

 The actual problem is an error that says Failed to map path '/', that
 is what I get in an inner exception:

 System.InvalidOperationException
 Failed to map path '/'

  at System.Web.HttpRequest.MapPath (System.String virtualPath,
 System.String baseVirtualDir, Boolean allowCrossAppMapping) [0x001a4] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web/HttpRequest.cs:1563
   at System.Web.HttpRequest.MapPath (System.String virtualPath)
 [0xd] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web/HttpRequest.cs:1520
   at System.Web.Hosting.HostingEnvironment.MapPath (System.String
 virtualPath) [0x00042] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Hosting/HostingEnvironment.cs:156
   at System.Web.Hosting.DefaultVirtualPathProvider.DirectoryExists
 (System.String virtualDir) [0x00016] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Hosting/DefaultVirtualPathProvider.cs:59
   at System.Web.Configuration.WebConfigurationManager.FindWebConfig
 (System.String path, System.Boolean inAnotherApp) [0x0001a] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:592
   at
 System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration
 (System.String path, System.String site, System.String locationSubPath,
 System.String server, System.String userName, System.String password,
 Boolean fweb) [0x00026] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:360
   at System.Web.Configuration.WebConfigurationManager.GetSection
 (System.String sectionName, System.String path, System.Web.HttpContext
 context) [0xd] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:456
   at System.Web.Configuration.WebConfigurationManager.GetSection
 (System.String sectionName, System.String path) [0x0] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:435
   at System.Web.Security.SqliteMembershipProvider.Initialize
 (System.String name, System.Collections.Specialized.NameValueCollection
 config) [0x0028b] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Security/SqliteMembershipProvider.cs:143
   at System.Web.Configuration.ProvidersHelper.InstantiateProvider
 (System.Configuration.ProviderSettings providerSettings, System.Type
 providerType) [0x00069] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/ProvidersHelper.cs:61
   at System.Web.Configuration.ProvidersHelper.InstantiateProviders
 

Re: [Mono-list] System.Web.Security.Membership causes an exception on mono platform

[Martin Thwaites]

Hi Olli,

I can't shed much light on the error itself, however, have you had any
asp.net site working on this installation?

Also, where was the site developed, VS, MD, Xs?

You say it happens on a fresh MVC site, what do you mean by fresh? A VS
template?

Also, have you tried disabling the Membership system altogether to see if
the error that's presented is masking something else?

I'll try to respond to further e-mails but I'm busy for the next few days.
Hopefully the answers to those questions will either get you to a solution
or enable somebody to help.

Thanks
Martin
On 17 Jan 2015 10:20, Olli Heiskanen ohjelmistoarkkite...@gmail.com
wrote:

 Hello,

 A little more information on this:

 The actual problem is an error that says Failed to map path '/', that is
 what I get in an inner exception:

 System.InvalidOperationException
 Failed to map path '/'

  at System.Web.HttpRequest.MapPath (System.String virtualPath,
 System.String baseVirtualDir, Boolean allowCrossAppMapping) [0x001a4] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web/HttpRequest.cs:1563
   at System.Web.HttpRequest.MapPath (System.String virtualPath) [0xd]
 in /usr/local/src/mono/mcs/class/System.Web/System.Web/HttpRequest.cs:1520
   at System.Web.Hosting.HostingEnvironment.MapPath (System.String
 virtualPath) [0x00042] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Hosting/HostingEnvironment.cs:156
   at System.Web.Hosting.DefaultVirtualPathProvider.DirectoryExists
 (System.String virtualDir) [0x00016] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Hosting/DefaultVirtualPathProvider.cs:59
   at System.Web.Configuration.WebConfigurationManager.FindWebConfig
 (System.String path, System.Boolean inAnotherApp) [0x0001a] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:592
   at System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration
 (System.String path, System.String site, System.String locationSubPath,
 System.String server, System.String userName, System.String password,
 Boolean fweb) [0x00026] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:360
   at System.Web.Configuration.WebConfigurationManager.GetSection
 (System.String sectionName, System.String path, System.Web.HttpContext
 context) [0xd] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:456
   at System.Web.Configuration.WebConfigurationManager.GetSection
 (System.String sectionName, System.String path) [0x0] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/WebConfigurationManager.cs:435
   at System.Web.Security.SqliteMembershipProvider.Initialize
 (System.String name, System.Collections.Specialized.NameValueCollection
 config) [0x0028b] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Security/SqliteMembershipProvider.cs:143
   at System.Web.Configuration.ProvidersHelper.InstantiateProvider
 (System.Configuration.ProviderSettings providerSettings, System.Type
 providerType) [0x00069] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/ProvidersHelper.cs:61
   at System.Web.Configuration.ProvidersHelper.InstantiateProviders
 (System.Configuration.ProviderSettingsCollection configProviders,
 System.Configuration.Provider.ProviderCollection providers, System.Type
 providerType) [0x0003e] in
 /usr/local/src/mono/mcs/class/System.Web/System.Web.Configuration_2.0/ProvidersHelper.cs:72



 My Web.config does not have any custom stuff, other than a custom
 membership provider, but the same error occurs on a fresh mvc3 site without
 any added code or customizations.

 My apache/mod_mono configuration is directly from
 http://go-mono.com/config-mod-mono/, without any change, here it is:

 Alias /boacommander /var/www/html/boacommander
   MonoServerPath boacommander /usr/bin/mod-mono-server4
   MonoDebug boacommander true
   MonoSetEnv boacommander MONO_IOMAP=all
   MonoApplications boacommander /boacommander:/var/www/html/boacommander
   Location /boacommander
 Allow from all
 Order allow,deny
 MonoSetServerAlias boacommander
 SetHandler mono
 SetOutputFilter DEFLATE
 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
   /Location
   IfModule mod_deflate.c
 AddOutputFilterByType DEFLATE text/html text/plain text/xml
 text/javascript
   /IfModule


 I have observed this error on mono versions 3.10.0, 3.10.1 and 3.12.0, all
 compiled from git branches.


 Based on my searches for a solution, I've seen some posts where this error
 occurs on a windows platform and a workaround is to run Visual Studio as
 administrator. This is not what I can do as the error does not occur on my
 windows platform, and apache process is run as root.

 Still I feel this might be a configuration issue, as it has something to
 do with path mapping. So far though, I've not found a configuration change
 that 

Re: [Mono-list] TypeLoadException with ASP.NET

[Martin Thwaites]

You want at least 3.10, or build from source (not hard).

Alternatively, you vacancies use the link I sent to simply add the package
for Ubuntu that were created by the mono team.  they should be more current
than 3.8.

Main thing is don't give up, it's not even close to a lost cause.

Thanks
Martin
On 15 Jan 2015 03:25, Igor Shmukler igor.shmuk...@gmail.com wrote:

 Hello Martin,

 I tried with modules from version 3.81. I understand those are fairly
 modern. No change.
 On my Ubuntu, had quite a lot of minor problems installing and
 removing various packages with apt-get, btw.
 On the subject, I spent hours and did not manage apache2 to load types
 or give proper diagnostics and logging. XSP4 worked out of the box on
 both Mac and Linux.

 If someone wants to dig into this, I would be delighted to assist. My
 boss is a big supporter of open source, and the code in question is
 trivial. I should probably be able to share binaries and sources, to
 whoever wants to dive into improving mod_mono on apache2.

 Sincerely,

 Igor Shmukler

 On Thu, Jan 15, 2015 at 12:00 AM, Martin Thwaites
 monofo...@my2cents.co.uk wrote:
  Hi Igor,
 
  Your version of mono is very old, so first, I would upgrade.
 
 
 http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives
 
  That should give you an idea how to do it.
 
  Once you've done that, if you're still getting problems try sending us
 the
  actual types (you replaced them with XXX in your message).
 
  Thanks,
  Martin
 
  On 13 January 2015 at 22:21, Igor Shmukler igor.shmuk...@gmail.com
 wrote:
 
  Hello Marco,
 
  Thank you for your email.
 
  I don't have to use apache2. I could use any production quality web
  server. The ability to handle load, is not even that important. We
  need to run an embedded server.
 
  If nginx+fastcgi is easy to setup, we would probably for it. Is this
  easy to setup? I had problems with XSP2, but version 4 just works for
  me on both Mac and Linux. Whatever it is, I am happy.
 
  Sincerely,
 
  Igor Shmukler
 
 
  On Tue, Jan 13, 2015 at 11:56 PM, Marco Ridoni m.rid...@gmail.com
 wrote:
   Igor, sorry if I'm asking something you already answered somehow: do
 you
   absolutely have to use Apache+mod_mono? I found nginx + fastcgi much
   faster
   and reliable in my case.
  
   m.
  
   2015-01-13 20:33 GMT+01:00 Igor Shmukler igor.shmuk...@gmail.com:
  
   Hello Andres,
  
   I agree that a cryptic message is not the friendliest thing for a
   programmer, such as myself. I should be coding, instead I am
   pretending to be a system administrator. IMHO, what is a bug: is in
   the eye of the beholder. I would love it, if every project was
   moderated according to your standards. :)
  
   After a lot more digging, so I am delighted to share the few
   additional insights.
  
   I tried various apache2+mono configurations using mod_mono_auto
 and/or
   mod_mono with manual site configuration. No matter what configuration
   was selected, the default.aspx compiles then loading a type from a
 DLL
   fails - otherwise, things look the same.
   I tried running my code with XSP2, and got exactly the same output as
   with apache2+mod_mono[_auto].
  
   Finally, I tried XSP4 - the same server that Xamarin packaged for
   XamarinStudio, which I use on my OSX laptop. XSP4 works.
   [I quickly tried mono-apache-server4, but did not get it to work fast
   enough. Perhaps, another pass at mono-server4 makes even more sense,
   now.]
  
   Sincerely,
  
   Igor Shmukler
  
   On Tue, Jan 13, 2015 at 8:29 PM, Andrés G. Aragoneses
   kno...@gmail.com
   wrote:
And when I say a bug I mean either a Mono bug, or a mod_mono bug.
   
On 13 January 2015 at 19:29, Andrés G. Aragoneses 
 kno...@gmail.com
wrote:
   
Igor, a misconfiguration problem should never rise a cryptic
TypeLoadException. You're simply hitting a bug with your codebase.
If
you
keep reducing the testcase, you will be able to know where is the
problem,
so you can open a more detailed bug report about it, or even fix
 it
yourself.
   
On 13 January 2015 at 10:01, Igor Shmukler 
 igor.shmuk...@gmail.com
wrote:
   
Hi Andres,
   
Thank you again
   
 I already know that my code runs fine [on Mac].

 With what web server?
   
On Mac [OS X], I have been using XamarinStudio, which hosts on
 XSP4
[at least by default]. XSP4 on Mac works great, but on Linux
 things
are strange. I am totally perplexed.
Do you think that 0.0.0.0 is the proper assembly version? What
 do I
do
to find out what is wrong. Does mod_mono have a separate log
somewhere? Does it make sense that apache2 error log shows no
errors?
   
 What would running my code with XSP prove?

 It would give more info to pinpoint if it's a bug in mono's
 ASP.NET
 stack,
 or in mod_mono (which is a different codebase).
   
Do you think that there is indeed a bug in a codebase

Re: [Mono-list] TypeLoadException with ASP.NET

[Martin Thwaites]

Hi Igor,

Your version of mono is very old, so first, I would upgrade.

http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives

That should give you an idea how to do it.

Once you've done that, if you're still getting problems try sending us the
actual types (you replaced them with XXX in your message).

Thanks,
Martin

On 13 January 2015 at 22:21, Igor Shmukler igor.shmuk...@gmail.com wrote:

 Hello Marco,

 Thank you for your email.

 I don't have to use apache2. I could use any production quality web
 server. The ability to handle load, is not even that important. We
 need to run an embedded server.

 If nginx+fastcgi is easy to setup, we would probably for it. Is this
 easy to setup? I had problems with XSP2, but version 4 just works for
 me on both Mac and Linux. Whatever it is, I am happy.

 Sincerely,

 Igor Shmukler


 On Tue, Jan 13, 2015 at 11:56 PM, Marco Ridoni m.rid...@gmail.com wrote:
  Igor, sorry if I'm asking something you already answered somehow: do you
  absolutely have to use Apache+mod_mono? I found nginx + fastcgi much
 faster
  and reliable in my case.
 
  m.
 
  2015-01-13 20:33 GMT+01:00 Igor Shmukler igor.shmuk...@gmail.com:
 
  Hello Andres,
 
  I agree that a cryptic message is not the friendliest thing for a
  programmer, such as myself. I should be coding, instead I am
  pretending to be a system administrator. IMHO, what is a bug: is in
  the eye of the beholder. I would love it, if every project was
  moderated according to your standards. :)
 
  After a lot more digging, so I am delighted to share the few
  additional insights.
 
  I tried various apache2+mono configurations using mod_mono_auto and/or
  mod_mono with manual site configuration. No matter what configuration
  was selected, the default.aspx compiles then loading a type from a DLL
  fails - otherwise, things look the same.
  I tried running my code with XSP2, and got exactly the same output as
  with apache2+mod_mono[_auto].
 
  Finally, I tried XSP4 - the same server that Xamarin packaged for
  XamarinStudio, which I use on my OSX laptop. XSP4 works.
  [I quickly tried mono-apache-server4, but did not get it to work fast
  enough. Perhaps, another pass at mono-server4 makes even more sense,
  now.]
 
  Sincerely,
 
  Igor Shmukler
 
  On Tue, Jan 13, 2015 at 8:29 PM, Andrés G. Aragoneses kno...@gmail.com
 
  wrote:
   And when I say a bug I mean either a Mono bug, or a mod_mono bug.
  
   On 13 January 2015 at 19:29, Andrés G. Aragoneses kno...@gmail.com
   wrote:
  
   Igor, a misconfiguration problem should never rise a cryptic
   TypeLoadException. You're simply hitting a bug with your codebase. If
   you
   keep reducing the testcase, you will be able to know where is the
   problem,
   so you can open a more detailed bug report about it, or even fix it
   yourself.
  
   On 13 January 2015 at 10:01, Igor Shmukler igor.shmuk...@gmail.com
   wrote:
  
   Hi Andres,
  
   Thank you again
  
I already know that my code runs fine [on Mac].
   
With what web server?
  
   On Mac [OS X], I have been using XamarinStudio, which hosts on XSP4
   [at least by default]. XSP4 on Mac works great, but on Linux things
   are strange. I am totally perplexed.
   Do you think that 0.0.0.0 is the proper assembly version? What do I
 do
   to find out what is wrong. Does mod_mono have a separate log
   somewhere? Does it make sense that apache2 error log shows no
 errors?
  
What would running my code with XSP prove?
   
It would give more info to pinpoint if it's a bug in mono's
 ASP.NET
stack,
or in mod_mono (which is a different codebase).
  
   Do you think that there is indeed a bug in a codebase? My guess is
   that something is funky with configuration. Obviously, I don't know
   what are the answers to my own questions. Hence, with that many
   variables, my guess is only so educated.
  
   Please advise.
  
   Sincerely,
  
   Igor Shmukler
  
  
  
  ___
  Mono-list maillist  -  Mono-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-list
 
 
 
  ___
  Mono-list maillist  -  Mono-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-list
 
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] TypeLoadException with ASP.NET

[Martin Thwaites]

I did fix most of these for asp.net MVC, what are you trying to run? And
how are you installing mono? Source? Package? Tarball?

Does it not give you enough information in the error message?
On 12 Jan 2015 11:29, Igor Shmukler igor.shmuk...@gmail.com wrote:

 Hello everyone,

 I am trying to formalize my project setup procedure for something I
 have been doing.
 I am responsible for both code and administration. We would rather not
 just rebuild everything locally, but instead understand what we have
 inside our template system so we know why things work or do not
 work.

 I developed some ASP.NET code on my Mac laptop. It works fine.
 Deployed it to Ubuntu running apache2+mono.

 Now, I am getting TypeLoadException claiming that my type cannot be
 load from an assembly:
 Could not load type 'XXX.YYY' from assembly 'XXX, Version=0.0.0.0,
 Culture=neutral, PublicKeyToken=null'.

 How can I go about figuring out what is causing the problem? I have
 seen that people have it. I am sure it is fixable. What can I do about
 tracing the error?

 Sincerely,

 Igor Shmukler
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] TypeLoadException with ASP.NET

[Martin Thwaites]

Hi igor,

I still haven't seen the full error, and you haven't said how you get mono.

Thanks
Martin
On 12 Jan 2015 21:38, Igor Shmukler igor.shmuk...@gmail.com wrote:

 Hello Martin,

 Thank you for your email.

 I get nothing useful in the apache error log, at this time. My guess
 is that the problem is related to apache2 configuration, as much as it
 is related to Mono... Still, I need the thing working.
 At one point, it was complaining about .mono/ access and problems with
 keys. I created the .mono directory and keys are there, now.
 Personally, I think that .mono is an issue to consider for whoever
 packages the stuff. Still, does not appear to be affecting me.

 To enable mono on apache2, I executed $sudo a2enmod mod_mono_auto

 It is my understanding that module is enabled somewhere other than
 apache2/sites-available. The reason being that if I edit
 /etc/apache2/sites-available/000-default.conf to include Mono with
 debugging enabled, I get an error on apache2 restart:

 [Mon Jan 12 20:59:12.223211 2015] [core:notice] [pid 7548:tid
 140595311900544] AH00094: Command line: '/usr/sbin/apache2'
 Listening on: /tmp/mod_mono_server_global
 Root directory: /
 Listening on: /tmp/mod_mono_server_global
 Root directory: /
 Error: There's already a server listening on /tmp/mod_mono_server_global

 I tried to enable debugging to mods-available/mod_mono.conf before the
 Include /etc/mono-server2/mono-server2-hosts.conf line. It did not
 do anything either - nothing in the apache2 error log.

 Debugging is enabled in web.config, so I get the stack trace. It is
 not useful for my purposes, all line numbers are missing, i.e.:
 at System.Web.UI.WebControls.Button.OnClick (System.EventArgs e)
 [0x0] in filename unknown:0
 at System.Web.UI.WebControls.Button.RaisePostBackEvent (System.String
 eventArgument) [0x0] in filename unknown:0
 at
 System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent
 (System.String eventArgument) [0x0] in filename unknown:0

 I am a bit at loss. Seems to be a trivial issue. Yet, I am confused.
 Any relevant information - whether why line numbers are missing and
 how to have those displayed, and/or - how do I trace my TypeLoad
 errors down, would be extremely helpful.

 Sincerely,

 Igor Shmukler

 On Mon, Jan 12, 2015 at 8:34 PM, Martin Thwaites
 monofo...@my2cents.co.uk wrote:
  I did fix most of these for asp.net MVC, what are you trying to run?
 And how
  are you installing mono? Source? Package? Tarball?
 
  Does it not give you enough information in the error message?
 
  On 12 Jan 2015 11:29, Igor Shmukler igor.shmuk...@gmail.com wrote:
 
  Hello everyone,
 
  I am trying to formalize my project setup procedure for something I
  have been doing.
  I am responsible for both code and administration. We would rather not
  just rebuild everything locally, but instead understand what we have
  inside our template system so we know why things work or do not
  work.
 
  I developed some ASP.NET code on my Mac laptop. It works fine.
  Deployed it to Ubuntu running apache2+mono.
 
  Now, I am getting TypeLoadException claiming that my type cannot be
  load from an assembly:
  Could not load type 'XXX.YYY' from assembly 'XXX, Version=0.0.0.0,
  Culture=neutral, PublicKeyToken=null'.
 
  How can I go about figuring out what is causing the problem? I have
  seen that people have it. I am sure it is fixable. What can I do about
  tracing the error?
 
  Sincerely,
 
  Igor Shmukler
  ___
  Mono-list maillist  -  Mono-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 1.2

[Martin Thwaites]

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

Re: [Mono-list] mvc and razorgenerator

[Martin Thwaites]

Hi Peter,

If you let us know what the error is, maybe I can have a look.  It maybe
that it will be fixed as part of some other work we're doing.

Thanks
Martin
On 1 Dec 2014 21:51, Peter Hagen pe...@willow-media.nl wrote:

 Hi,

 I tried the latest Xamarin Studio with my MVC 4 project, and this time it
 worked out of the box! I can start the application and its runs fine in
 combination with MySql on my Mac. The production website already worked on
 Mono, but from the IDE it was a problem before. This time the nuget stuff
 didn’t update directly to the latest versions, and thats perfect!

 There is only one thing I ran into. I use RazorGenerator to compile the
 views at compile time. This way I don’t even supply the cshtml files in the
 production site. Does anyone has any idea if its possible to use
 RazorGenerator in combination with Xamarin Studio (or MonoDevelop). In
 Visual Studio its an extension that uses a custom tool to generate the cs
 files.

 Cheers

 Peter
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] List of cleanup candidates for Mono 4.0

[Martin Thwaites]

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

[Mono-dev] .NET Reference source terminology

[Martin Thwaites]

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] [Mono-list] .NET and Mono integration, the plans

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com
 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-list] .NET and Mono integration, the plans

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com
 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-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Debug.Assert - a cross-platform issue

[Martin Thwaites]

(This is my personal opinion, I'm not a collaborator)  This is also a
question that is better for the dev list.

My personal opinion is that if it's a verbatim port from the
referencesource on github, that you shouldn't be precluded from
contributing.

Anything beyond that would be questionable I would imagine.  You have to
remember that the referencesource isn't the same decompiled source from
previous versions.  I'm not sure where the patent promise would sit in that
instance.

I know a few people who fell under this same rule, so I would like to see
some clarity too.

Thanks,
Martin

On 22 November 2014 00:25, MarLOne infoseeker...@gmail.com wrote:

 Hello,

 I have to thank Microsoft to open-source the .Net library allowing me to
 read their code to get to the bottom of Microsoft's treatment (even I have
 already asserted the value at runtime) of default values for the
 System.Diagnostics.DefaultTraceListener. For those interested in reading
 this can find it here:  DefaultTraceListener.cs
 
 https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs
 
 . The default value of property that determines the reaction of
 Debug.Assert
 is set here:  assertuienabled
 
 https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/AssertSection.cs
 
 .

 It is not true that Mono does not create an instance of
 DefaultTraceListener
 on start up otherwise code like this:
 DefaultTraceListener defListener = Debug.Listeners[Default] as
 DefaultTraceListener;

 will produce a null value for defListener.

 It will be good if these classes and assemblies from Microsoft open-sources
 are incorporated verbatim into Mono to replace its inconsistent code.

 In this thread some one had pointed out to me that because I admitted
 routinely disassembling Microsoft's assemblies, in accordance to Mono's
 contribution rule 
 http://www.mono-project.com/Contributing#Important_Rules
 , I cannot contribute.

 With Microsoft now open-sourcing their .Net library, what will happen to
 this contribution rule?

 MarL



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Debug-Assert-a-cross-platform-issue-tp4662174p4664765.html
 Sent from the Mono - General mailing list archive at Nabble.com.
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Porting HttpApplication and associated classes

[Martin Thwaites]

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 mig...@xamarin.com 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-list] ASP.net and Licensing

[Martin Thwaites]

Does this not cover it?

https://github.com/mono/mono/blob/master/LICENSE

(Note, I'm not a legal expert so if you're concerned in anyway, get you
lawyer to look into it)

You've got to look at the individual libraries you're using though.  If
they are Mono libraries, chances are they are MIT/X11, so you're safe, and
we are more open that the microsoft licencing.  Give that it's a very, very
(add 20 or so more verys there) common framework to build websites, I'd
say that yes you can build a piece of commercial software with it.

That said, you would need to be more specific.  Using the libraries in .NET
or mono should not be a problem in terms of building a commercial website
without any acknowledgement in my opinion.  I've built major websites using
.NET and the ASP.NET framework (WebForms and MVC), and our legal department
never raised an eyebrow.

That said, is it not always nice to acknowledge people's hard work and give
credit where it's due?

Mono is NOT Xamarin.  Xamarin do something very specific with Mobile.
Xamarin's offerings use Mono under the hood, and therefore they commit any
changes/enhancements back to the mono project.  Anything on GitHub is not
owned by Xamarin (as I understand it, and check the licences if you're
unsure), therefore they cannot (nor would they want to) force you to buy a
licence to use them.

Hope that helps
Martin

On 20 November 2014 16:00, William Ivanski william.ivan...@gmail.com
wrote:

 Great question, I would like to know that too.

 William Ivanski

 2014-11-20 9:13 GMT-02:00 aleksit aleksi.tanska...@live.com:

 Hey
 What is licensing terms of ASP.net of mono ? Is they same than licenses of
 mono ?
 Can I do commercial software with it and if I can what kind of things I
 need
 to add with my project ? And what is the license terms if I host my
 project
 for customers ? Do I need to buy Xamarin license ?



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/ASP-net-and-Licensing-tp4664729.html
 Sent from the Mono - General mailing list archive at Nabble.com.
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list



 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans

[Martin Thwaites]

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 mig...@xamarin.com 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

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com 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

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com 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 mig...@xamarin.com 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

[Martin Thwaites]

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 monofo...@my2cents.co.uk 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 mig...@xamarin.com 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 mig...@xamarin.com 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 mig...@xamarin.com 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

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
 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 mig...@xamarin.com 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 mig...@xamarin.com 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 mig...@xamarin.com
 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

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com
 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 monofo...@my2cents.co.uk
 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 mig...@xamarin.com 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 mig...@xamarin.com
 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 mig...@xamarin.com
 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

[Martin Thwaites]

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] Crash course on bringing .NET open sourced code to Mono.

[Martin Thwaites]

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 mig...@xamarin.com 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.

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
 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 mig...@xamarin.com 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.

[Martin Thwaites]

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.

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
 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.

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com
 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 kornel...@gmail.com 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 mig...@xamarin.com 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 
 monofo...@my2cents.co.uk 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 mig...@xamarin.com 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

[Mono-list] vNext MusicStore on linux using Kestrel, working?

[Martin Thwaites]

Hi All,

Spurred on by the latest announcement, I've decided to see if I can the
MusicStore sample app working on ubuntu.

Unfortunately, I'm hitting the common libuv error when trying to run
kestrel.

System.NullReferenceException: Object reference not set to an instance of
an object
  at Microsoft.AspNet.Server.Kestrel.Networking.Libuv.loop_size ()
[0x0] in filename unknown:0
  at Microsoft.AspNet.Server.Kestrel.Networking.UvLoopHandle.Init
(Microsoft.AspNet.Server.Kestrel.Networking.Libuv uv) [0x0] in
filename unknown:0
  at Microsoft.AspNet.Server.Kestrel.KestrelThread.ThreadStart
(System.Object parameter) [0x0] in filename unknown:0

I've tried downloading the file from
http://carolynvanslyck.com/blog/2014/09/dotnet-vnext-impressions/ and
overwriting the existing file, but I get the small problem.

My question is, has anyone had any luck getting it working on ubuntu with
the latest version of mono?  If so, it could be an issue with my install,
or configuration, I just don't want to try that if there is a known issue.

Thanks,
Martin
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] .NET Announcement

[Martin Thwaites]

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

[Martin Thwaites]

summary
.NET is to be fully opensourced by Microsoft under the MIT Licence.
/summary

On 12 November 2014 16:20, Gergely Buday gbu...@gmail.com wrote:

 It is not available at the moment. Could you summarise?

 On 12 November 2014 17:10, Martin Thwaites monofo...@my2cents.co.uk
 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.

[Martin Thwaites]

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 eso...@gmail.com 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.

[Martin Thwaites]

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 mcvje...@holisticware.net
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
 monofo...@my2cents.co.uk 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 
 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-list] [Mono-dev] Open source .NET and Mono.

[Martin Thwaites]

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-l...@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] [Mono-dev] Open source .NET and Mono.

[Martin Thwaites]

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 eso...@gmail.com 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-l...@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Mono and vNext, What is microsoft supporting

[Martin Thwaites]

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

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

Hi Miguel,

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

Thanks again for all you're doing.

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

Martin

On 2 November 2014 13:51, Miguel de Icaza mig...@xamarin.com wrote:

 I don't really have a strong opinion.   Can you teens me the email you
 want me to look at?


 On Sunday, November 2, 2014, Martin Thwaites monofo...@my2cents.co.uk
 wrote:

 Thanks Miguel,

 I'll remove that and rebase then.  As the test does both protect an
 unprotect, should there really be a separate test?

 Martin

 On 2 November 2014 13:09, Miguel de Icaza mig...@xamarin.com wrote:

 Hello Martin,

 The TODO should be used to flag to the consumer that something is not
 implemented or half implemented.

 But we do not do this for missing items that could be configured out of
 band.  For those, if they matter, we file bug reports.

 Miguel

 On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites 
 monofo...@my2cents.co.uk wrote:

 Amazing, thanks Miguel, comments inline.

 On 2 Nov 2014 00:52, Miguel de Icaza mig...@xamarin.com wrote:
 
 
  PR1349: https://github.com/mono/mono/pull/1349
  This is the machine key work, and needs a small tweak before it can
 be merged that I will do this week.
 
 
  I believe the TODO can be removed.   Can you do that?  See comments
 on pull request.

 I don't believe the TODO can be removed as the Encrypt Decrypt methods
 don't allow you use custom decryptors (from what I could tell) it's 4.5
 specific functionality and controlled via the Web.config.

 Do you want me to expand on the TODO to make it clearer?
 
 
  PR1363: https://github.com/mono/mono/pull/1363
  Another of mine with the MembershipPasswordAttribute
 
 
  Do you mind resending this?  It can no longer be auto-merged from the
 UI.

 Before I send this, I need to change the build order in the mcs/class
 makefile, and wanted to run that past you first as it strikes me as
 something via fragile.  I sent a message to the list a few days about it,
 could you respond on that and I'll resend?
 
 
  PR1365: https://github.com/mono/mono/pull/1365
  This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has
 said he'll take a look at it.
 
 
  Manually aded
 
 
  PR1370: https://github.com/mono/mono/pull/1370
  Small one implementing a default of the ReadEntityBodyMode
 
 
  Got this one by hand.
 
 
  PR1371: https://github.com/mono/mono/pull/1371
  Another small one, implementing the ClientDisconnectedToken
 
 
  And this one automatically.
 
 
  PR1372: https://github.com/mono/mono/pull/1372
  A final small one around the GetBuffer* methods in the httprequest.
 
 
  I do not like this one.  Is there a reason we can not implement the
 required functionality instead?
 It's not actually required as the default on ReadEntityBodyMode means
 that all clients of the code should go directly to input stream.  The code
 here is enough to ensure that calling code works.

 Looking at various posts about how to used the
 GetBufferlessInputStream,  it looks like it needs Async reads as well as
 Synchronous, so it's a little more involved.

 The only thing that we could potentially do is change the exception to
 one you get when you try to read it buffered when classic is set.
 
  Miguel
 
  There is 1 final small piece that either myself of Chris Carroll
 will get done this week which is around the AppendTrailing slash and
 lowercaseUrls properties in RouteBase class.  We just need to put the
 implementation together.
 
  Anyway, after applying all of these, my large WebAPI solution not
 only compiles, but it also runs!
 
  If you want to checkout what it looks like with all the patches
 applied, that would be great, I'd love to have some more information on
 whether it does work.  I'm sure there will still be bugs, but if it works
 mostly, then bug fixing is easy (famous last words).
 
  https://github.com/martinjt/mono/tree/mvc_allfixes
 
  Thanks for everyone's help.
 
  Martin
 
  On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk
 wrote:
 
  Hi Miguel,
 
  The code that I'm referring to here is that of the aspnetwebstack
 on codeplex.  That is to say that they are not something where you can
 remove the code and recompile (unless there as a specific mono
 implementation which is not ideal).  The goal is to have the compiled dlls
 that are available on nuget work, without tweaking to a person's
 application.
 
  I'll have a look and see if I can see where it would be used, but
 still as you've said on one of my pulls, a half done implementation is
 better than none.
 
  Having the application throw a missing method exception should not
 be the recommended approach when we can add the property and default it to
 false.
 
  Thanks, and please don't think that things won't getting

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

Hi Miguel,

I've also updated the MachineKey.Protect implementation to have the TODO
removed now.

Please can you merge both https://github.com/mono/mono/pull/1363
(Membership) and https://github.com/mono/mono/pull/1349 (MachineKey) when
you're next free.

I'll start another thread about the other outstanding stuff.

Thanks,
Martin

On 3 November 2014 21:48, Martin Thwaites monofo...@my2cents.co.uk wrote:

 Hi Miguel,

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

 Thanks again for all you're doing.

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

 Martin

 On 2 November 2014 13:51, Miguel de Icaza mig...@xamarin.com wrote:

 I don't really have a strong opinion.   Can you teens me the email you
 want me to look at?


 On Sunday, November 2, 2014, Martin Thwaites monofo...@my2cents.co.uk
 wrote:

 Thanks Miguel,

 I'll remove that and rebase then.  As the test does both protect an
 unprotect, should there really be a separate test?

 Martin

 On 2 November 2014 13:09, Miguel de Icaza mig...@xamarin.com wrote:

 Hello Martin,

 The TODO should be used to flag to the consumer that something is not
 implemented or half implemented.

 But we do not do this for missing items that could be configured out of
 band.  For those, if they matter, we file bug reports.

 Miguel

 On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites 
 monofo...@my2cents.co.uk wrote:

 Amazing, thanks Miguel, comments inline.

 On 2 Nov 2014 00:52, Miguel de Icaza mig...@xamarin.com wrote:
 
 
  PR1349: https://github.com/mono/mono/pull/1349
  This is the machine key work, and needs a small tweak before it can
 be merged that I will do this week.
 
 
  I believe the TODO can be removed.   Can you do that?  See comments
 on pull request.

 I don't believe the TODO can be removed as the Encrypt Decrypt methods
 don't allow you use custom decryptors (from what I could tell) it's 4.5
 specific functionality and controlled via the Web.config.

 Do you want me to expand on the TODO to make it clearer?
 
 
  PR1363: https://github.com/mono/mono/pull/1363
  Another of mine with the MembershipPasswordAttribute
 
 
  Do you mind resending this?  It can no longer be auto-merged from
 the UI.

 Before I send this, I need to change the build order in the mcs/class
 makefile, and wanted to run that past you first as it strikes me as
 something via fragile.  I sent a message to the list a few days about it,
 could you respond on that and I'll resend?
 
 
  PR1365: https://github.com/mono/mono/pull/1365
  This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel
 has said he'll take a look at it.
 
 
  Manually aded
 
 
  PR1370: https://github.com/mono/mono/pull/1370
  Small one implementing a default of the ReadEntityBodyMode
 
 
  Got this one by hand.
 
 
  PR1371: https://github.com/mono/mono/pull/1371
  Another small one, implementing the ClientDisconnectedToken
 
 
  And this one automatically.
 
 
  PR1372: https://github.com/mono/mono/pull/1372
  A final small one around the GetBuffer* methods in the httprequest.
 
 
  I do not like this one.  Is there a reason we can not implement the
 required functionality instead?
 It's not actually required as the default on ReadEntityBodyMode means
 that all clients of the code should go directly to input stream.  The code
 here is enough to ensure that calling code works.

 Looking at various posts about how to used the
 GetBufferlessInputStream,  it looks like it needs Async reads as well as
 Synchronous, so it's a little more involved.

 The only thing that we could potentially do is change the exception to
 one you get when you try to read it buffered when classic is set.
 
  Miguel
 
  There is 1 final small piece that either myself of Chris Carroll
 will get done this week which is around the AppendTrailing slash and
 lowercaseUrls properties in RouteBase class.  We just need to put the
 implementation together.
 
  Anyway, after applying all of these, my large WebAPI solution not
 only compiles, but it also runs!
 
  If you want to checkout what it looks like with all the patches
 applied, that would be great, I'd love to have some more information on
 whether it does work.  I'm sure there will still be bugs, but if it works
 mostly, then bug fixing is easy (famous last words).
 
  https://github.com/martinjt/mono/tree/mvc_allfixes
 
  Thanks for everyone's help.
 
  Martin
 
  On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk
 wrote:
 
  Hi Miguel,
 
  The code that I'm referring to here is that of the aspnetwebstack
 on codeplex.  That is to say that they are not something where you can
 remove the code and recompile (unless there as a specific mono
 implementation which is not ideal).  The goal is to have the compiled dlls
 that are available on nuget work

[Mono-dev] Review of PR1372 implement Request.GetBufferlessInputStream/GetBufferedInputStream methods

[Martin Thwaites]

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] State of aspnetwebstack on mono

[Martin Thwaites]

Amazing, thanks Miguel, comments inline.

On 2 Nov 2014 00:52, Miguel de Icaza mig...@xamarin.com wrote:


 PR1349: https://github.com/mono/mono/pull/1349
 This is the machine key work, and needs a small tweak before it can be
merged that I will do this week.


 I believe the TODO can be removed.   Can you do that?  See comments on
pull request.

I don't believe the TODO can be removed as the Encrypt Decrypt methods
don't allow you use custom decryptors (from what I could tell) it's 4.5
specific functionality and controlled via the Web.config.

Do you want me to expand on the TODO to make it clearer?


 PR1363: https://github.com/mono/mono/pull/1363
 Another of mine with the MembershipPasswordAttribute


 Do you mind resending this?  It can no longer be auto-merged from the UI.

Before I send this, I need to change the build order in the mcs/class
makefile, and wanted to run that past you first as it strikes me as
something via fragile.  I sent a message to the list a few days about it,
could you respond on that and I'll resend?


 PR1365: https://github.com/mono/mono/pull/1365
 This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has
said he'll take a look at it.


 Manually aded


 PR1370: https://github.com/mono/mono/pull/1370
 Small one implementing a default of the ReadEntityBodyMode


 Got this one by hand.


 PR1371: https://github.com/mono/mono/pull/1371
 Another small one, implementing the ClientDisconnectedToken


 And this one automatically.


 PR1372: https://github.com/mono/mono/pull/1372
 A final small one around the GetBuffer* methods in the httprequest.


 I do not like this one.  Is there a reason we can not implement the
required functionality instead?
It's not actually required as the default on ReadEntityBodyMode means that
all clients of the code should go directly to input stream.  The code here
is enough to ensure that calling code works.

Looking at various posts about how to used the GetBufferlessInputStream,
it looks like it needs Async reads as well as Synchronous, so it's a little
more involved.

The only thing that we could potentially do is change the exception to one
you get when you try to read it buffered when classic is set.

 Miguel

 There is 1 final small piece that either myself of Chris Carroll will
get done this week which is around the AppendTrailing slash and
lowercaseUrls properties in RouteBase class.  We just need to put the
implementation together.

 Anyway, after applying all of these, my large WebAPI solution not only
compiles, but it also runs!

 If you want to checkout what it looks like with all the patches applied,
that would be great, I'd love to have some more information on whether it
does work.  I'm sure there will still be bugs, but if it works mostly, then
bug fixing is easy (famous last words).

 https://github.com/martinjt/mono/tree/mvc_allfixes

 Thanks for everyone's help.

 Martin

 On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk
wrote:

 Hi Miguel,

 The code that I'm referring to here is that of the aspnetwebstack on
codeplex.  That is to say that they are not something where you can remove
the code and recompile (unless there as a specific mono implementation
which is not ideal).  The goal is to have the compiled dlls that are
available on nuget work, without tweaking to a person's application.

 I'll have a look and see if I can see where it would be used, but still
as you've said on one of my pulls, a half done implementation is better
than none.

 Having the application throw a missing method exception should not be
the recommended approach when we can add the property and default it to
false.

 Thanks, and please don't think that things won't getting better with my
reviews.  I'm learning what you want so I can review better and help reduce
the burden on you and your staff.

 Martin

 On 20 Oct 2014 20:04, Miguel de Icaza mig...@xamarin.com wrote:

 As for the properties, although they should do something to the
generated urls, simply adding them should surely be a valid pull?  the
issue at the moment is that without them, you get an exception even if it
should be false.  I actually think that these are used by other classes
when generating urls, not the route collection itself, but I don't know for
sure.  Considering that adding them is very low risk, can we not just
accept the pull and ask for further work.

 Nope, all they do is allow some code to be compiled, and then get the
wrong result.

 You might as well remove the dependency of those properties, and see
what else breaks on whatever piece of code you are trying to build.

 Miguel



 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

Thanks Miguel,

I'll remove that and rebase then.  As the test does both protect an
unprotect, should there really be a separate test?

Martin

On 2 November 2014 13:09, Miguel de Icaza mig...@xamarin.com wrote:

 Hello Martin,

 The TODO should be used to flag to the consumer that something is not
 implemented or half implemented.

 But we do not do this for missing items that could be configured out of
 band.  For those, if they matter, we file bug reports.

 Miguel

 On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites monofo...@my2cents.co.uk
 wrote:

 Amazing, thanks Miguel, comments inline.

 On 2 Nov 2014 00:52, Miguel de Icaza mig...@xamarin.com wrote:
 
 
  PR1349: https://github.com/mono/mono/pull/1349
  This is the machine key work, and needs a small tweak before it can be
 merged that I will do this week.
 
 
  I believe the TODO can be removed.   Can you do that?  See comments on
 pull request.

 I don't believe the TODO can be removed as the Encrypt Decrypt methods
 don't allow you use custom decryptors (from what I could tell) it's 4.5
 specific functionality and controlled via the Web.config.

 Do you want me to expand on the TODO to make it clearer?
 
 
  PR1363: https://github.com/mono/mono/pull/1363
  Another of mine with the MembershipPasswordAttribute
 
 
  Do you mind resending this?  It can no longer be auto-merged from the
 UI.

 Before I send this, I need to change the build order in the mcs/class
 makefile, and wanted to run that past you first as it strikes me as
 something via fragile.  I sent a message to the list a few days about it,
 could you respond on that and I'll resend?
 
 
  PR1365: https://github.com/mono/mono/pull/1365
  This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has
 said he'll take a look at it.
 
 
  Manually aded
 
 
  PR1370: https://github.com/mono/mono/pull/1370
  Small one implementing a default of the ReadEntityBodyMode
 
 
  Got this one by hand.
 
 
  PR1371: https://github.com/mono/mono/pull/1371
  Another small one, implementing the ClientDisconnectedToken
 
 
  And this one automatically.
 
 
  PR1372: https://github.com/mono/mono/pull/1372
  A final small one around the GetBuffer* methods in the httprequest.
 
 
  I do not like this one.  Is there a reason we can not implement the
 required functionality instead?
 It's not actually required as the default on ReadEntityBodyMode means
 that all clients of the code should go directly to input stream.  The code
 here is enough to ensure that calling code works.

 Looking at various posts about how to used the GetBufferlessInputStream,
 it looks like it needs Async reads as well as Synchronous, so it's a little
 more involved.

 The only thing that we could potentially do is change the exception to
 one you get when you try to read it buffered when classic is set.
 
  Miguel
 
  There is 1 final small piece that either myself of Chris Carroll will
 get done this week which is around the AppendTrailing slash and
 lowercaseUrls properties in RouteBase class.  We just need to put the
 implementation together.
 
  Anyway, after applying all of these, my large WebAPI solution not only
 compiles, but it also runs!
 
  If you want to checkout what it looks like with all the patches
 applied, that would be great, I'd love to have some more information on
 whether it does work.  I'm sure there will still be bugs, but if it works
 mostly, then bug fixing is easy (famous last words).
 
  https://github.com/martinjt/mono/tree/mvc_allfixes
 
  Thanks for everyone's help.
 
  Martin
 
  On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk
 wrote:
 
  Hi Miguel,
 
  The code that I'm referring to here is that of the aspnetwebstack on
 codeplex.  That is to say that they are not something where you can remove
 the code and recompile (unless there as a specific mono implementation
 which is not ideal).  The goal is to have the compiled dlls that are
 available on nuget work, without tweaking to a person's application.
 
  I'll have a look and see if I can see where it would be used, but
 still as you've said on one of my pulls, a half done implementation is
 better than none.
 
  Having the application throw a missing method exception should not be
 the recommended approach when we can add the property and default it to
 false.
 
  Thanks, and please don't think that things won't getting better with
 my reviews.  I'm learning what you want so I can review better and help
 reduce the burden on you and your staff.
 
  Martin
 
  On 20 Oct 2014 20:04, Miguel de Icaza mig...@xamarin.com wrote:
 
  As for the properties, although they should do something to the
 generated urls, simply adding them should surely be a valid pull?  the
 issue at the moment is that without them, you get an exception even if it
 should be false.  I actually think that these are used by other classes
 when generating urls, not the route collection itself, but I don't know for
 sure.  Considering that adding them is very

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

On 2 November 2014 14:26, Kornel Pal kornel...@gmail.com wrote:

  Hi,

 I've noticed that new functionality is going into the wrappers, while in
 my opinion that the functionality belongs to HttpRequest and HttpResponse:

- HttpRequestBase.ReadEntityBodyMode: returning 0 instead of
ReadEntityBodyMode.Classic made more sense
 - HttpRequestWrapper.ReadEntityBodyMode: wrapper is not supposed to
implement functionality, that belongs to HttpRequest

 These are a bit of a fudge granted, at the moment, what we're doing is
forcing the client (calling application) to use the Request.InputStream
stream instead of using the Buffer methods.  This is important until we
have a full implementation of the methods required to do all the other
logic.


- HttpRequestWrapper.Abort: wrapper is not supposed to implement
functionality, that belongs to HttpRequest

 This is a crude implementation, and will need to be properly implemented
in HttpRequest at some point. I opted to do it in the Wrapper so it's known
that it's not a proper implementation.  There is a bug here that I'm not
sure whether it causes the BeginGetRequestStream or BeginGetResponse to be
called, so it really needs a fair bit of work.


- HttpResponseWrapper.ClientDisconnectedToken: wrapper is not supposed
to implement functionality, that belongs to HttpResponse

 This should be an easy fix, to simply do the return CancellationToken.None
from the HttpResponse instead.



 As for the GetBuffer* methods:

- Mono already implements HttpRequest.GetBufferlessInputStream, so
hard coding ReadEntityBodyMode.Classic limits Mono's compatibility

 Essentially, I had choose only 1 value as I didn't have time to implement
the other options.  Choosing Classic meant that we could ensure that new
clients revert to functionality we know works.  We're not saying that this
is the way it will always work, just that this is a starting point for
people.  Once all the methods have been implemented, this will obviously be
changed.


- Implementing GetBufferedInputStream based on the existing
GetBufferlessInputStream implementation doesn't seem to be too difficult

 Difficulty is in the eye of the beholder.


- HttpWorkerRequest in 4.5 has support for asynchronous operations,
but that does not have to be implemented for this to work because the
Stream base class implements async operations using the sync methods

 I've simply not had the time to look into this part yet.  I've been
thinking of a minimal viable product that allows MVC/WebAPI to work out of
the box on mono, not looking at what methods need to be implemented to
complete a full implementation of ASP.NET.

This whole area is something that is coupled with the ReadEntityBodyMode,
it will be great to get them all in, and I will be looking at them, they
are just not part of the MVP work.



 Thank you.

 Kornel


 On 11/2/2014 1:52 AM, Miguel de Icaza wrote:


  PR1349: https://github.com/mono/mono/pull/1349

 *This is the machine key work, and needs a small tweak before it can be
 merged that I will do this week. *


  I believe the TODO can be removed.   Can you do that?  See comments on
 pull request.


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

 *Another of mine with the MembershipPasswordAttribute *


  Do you mind resending this?  It can no longer be auto-merged from the UI.


  PR1365: https://github.com/mono/mono/pull/1365

 *This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has
 said he'll take a look at it. *


  Manually aded


  PR1370: https://github.com/mono/mono/pull/1370

 *Small one implementing a default of the ReadEntityBodyMode *


  Got this one by hand.


  PR1371: https://github.com/mono/mono/pull/1371

 *Another small one, implementing the ClientDisconnectedToken *


  And this one automatically.


  PR1372: https://github.com/mono/mono/pull/1372

 *A final small one around the GetBuffer* methods in the httprequest. *


  I do not like this one.  Is there a reason we can not implement the
 required functionality instead?

  Miguel

  There is 1 final small piece that either myself of Chris Carroll will
 get done this week which is around the AppendTrailing slash and
 lowercaseUrls properties in RouteBase class.  We just need to put the
 implementation together.

 Anyway, after applying all of these, my large WebAPI solution not only
 compiles, but it also runs!

  If you want to checkout what it looks like with all the patches
 applied, that would be great, I'd love to have some more information on
 whether it does work.  I'm sure there will still be bugs, but if it works
 mostly, then bug fixing is easy (famous last words).

 https://github.com/martinjt/mono/tree/mvc_allfixes

  Thanks for everyone's help.

  Martin

 On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk
 wrote:

 Hi Miguel,

 The code that I'm referring to here is that of the aspnetwebstack on
 codeplex.  That is to say

[Mono-list] MoMa for latest mono version.

[Martin Thwaites]

Hi all,

Is anyone aware of an update MoMa tool that shows support for 3.10?

Thanks
Martin
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] PR 1081: Allow CLR binaries to be passed to Process.Start

[Martin Thwaites]

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 mig...@xamarin.com 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-list] Error installing XSP - missing required Mono 4.0 assembly: System.Web.dll

[Martin Thwaites]

I think you need to run ./Autogen.sh --prefix=/usr instead of configure.

Also, your mono version is quite out of date.  Since you are comfortable
compiling from source, I would recommend upgrading to 3.10.

Hope that helps
Martin
On 30 Oct 2014 13:48, Klein, Josh jkle...@partners.org wrote:

  Using CentOS 6.5 and Mono version 3.4.0.

 While installing xsp with the following:

 cd ~/mono/xsp-2.10.2
 ./configure --prefix=/usr


 I get the following error:

 Configure: error: missing required Mono 4.0 assembly: System.Web.dll

 What am I missing?

 Thanks,

 Josh



 The information in this e-mail is intended only for the person to whom it
 is
 addressed. If you believe this e-mail was sent to you in error and the
 e-mail
 contains patient information, please contact the Partners Compliance
 HelpLine at
 http://www.partners.org/complianceline . If the e-mail was sent to you in
 error
 but does not contain patient information, please contact the sender and
 properly
 dispose of the e-mail.

 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list


___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Review of PR1363: MembershipPasswordAttribute

[Martin Thwaites]

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 monofo...@my2cents.co.uk 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] NUnit version for mono source tests

[Martin Thwaites]

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 char...@nunit.com 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 mig...@xamarin.com
 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

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
 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 char...@nunit.com 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 mig...@xamarin.com
 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

[Martin Thwaites]

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 mig...@xamarin.com 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 kornel...@gmail.com 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

[Martin Thwaites]

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 kornel...@gmail.com 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 mig...@xamarin.com 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 kornel...@gmail.com 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

[Martin Thwaites]

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

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
  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 mig...@xamarin.com 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 kornel...@gmail.com 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.

[Martin Thwaites]

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

[Martin Thwaites]

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

[Martin Thwaites]

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

[Martin Thwaites]

Hi All,

Just another quick update.

Some potentially amazing news.  I've managed to get a fairly large MVC
5.2/WebAPI running on mono!  That is out of the box, without any special
versions of dll's (other than removing the Microsoft.Web.Infrastructure.dll
I think.

So, there are a few outstanding PR's that need to reviewed and merged, but
the end is in sight! Special thanks go out to Kornel Pal for implementing
the HttpTaskAsyncHandler as this was going to be a big uphill struggle for
me so you saved me a lot of time.

So the list of PR's that need reviewing (not including ones already
reviewed and merged) in order to make this work are:

PR1163: https://github.com/mono/mono/pull/1163

*This is done by Mike Morano and has recently been re-done without the
offending code (now added in my PR1363).*
PR1349: https://github.com/mono/mono/pull/1349

*This is the machine key work, and needs a small tweak before it can be
merged that I will do this week.*
PR1363: https://github.com/mono/mono/pull/1363

*Another of mine with the MembershipPasswordAttribute*
PR1365: https://github.com/mono/mono/pull/1365

*This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has said
he'll take a look at it.*
PR1370: https://github.com/mono/mono/pull/1370

*Small one implementing a default of the ReadEntityBodyMode*
PR1371: https://github.com/mono/mono/pull/1371

*Another small one, implementing the ClientDisconnectedToken*
PR1372: https://github.com/mono/mono/pull/1372

*A final small one around the GetBuffer* methods in the httprequest.*
There is 1 final small piece that either myself of Chris Carroll will get
done this week which is around the AppendTrailing slash and lowercaseUrls
properties in RouteBase class.  We just need to put the implementation
together.

Anyway, after applying all of these, my large WebAPI solution not only
compiles, but it also runs!

If you want to checkout what it looks like with all the patches applied,
that would be great, I'd love to have some more information on whether it
does work.  I'm sure there will still be bugs, but if it works mostly, then
bug fixing is easy (famous last words).

https://github.com/martinjt/mono/tree/mvc_allfixes

Thanks for everyone's help.

Martin

On 20 October 2014 20:42, Martin Thwaites monofo...@my2cents.co.uk wrote:

 Hi Miguel,

 The code that I'm referring to here is that of the aspnetwebstack on
 codeplex.  That is to say that they are not something where you can remove
 the code and recompile (unless there as a specific mono implementation
 which is not ideal).  The goal is to have the compiled dlls that are
 available on nuget work, without tweaking to a person's application.

 I'll have a look and see if I can see where it would be used, but still as
 you've said on one of my pulls, a half done implementation is better than
 none.

 Having the application throw a missing method exception should not be the
 recommended approach when we can add the property and default it to false.

 Thanks, and please don't think that things won't getting better with my
 reviews.  I'm learning what you want so I can review better and help reduce
 the burden on you and your staff.

 Martin
 On 20 Oct 2014 20:04, Miguel de Icaza mig...@xamarin.com wrote:

 As for the properties, although they should do something to the generated
 urls, simply adding them should surely be a valid pull?  the issue at the
 moment is that without them, you get an exception even if it should be
 false.  I actually think that these are used by other classes when
 generating urls, not the route collection itself, but I don't know for
 sure.  Considering that adding them is very low risk, can we not just
 accept the pull and ask for further work.

 Nope, all they do is allow some code to be compiled, and then get the
 wrong result.

 You might as well remove the dependency of those properties, and see what
 else breaks on whatever piece of code you are trying to build.

 Miguel


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Support 2-args Socket ctor added in .NET 4.5

[Martin Thwaites]

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 m...@muo.jp 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

[Martin Thwaites]

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

[Martin Thwaites]

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] elimination of TARGET_J2EE/TARGET_JVM ?

[Martin Thwaites]

I think I remember seeing a load of ifdefs for j2ee in Httpapplication.
On 24 Oct 2014 11:58, Etienne Champetier champetier.etie...@gmail.com
wrote:

 Hi

 2014-10-24 12:37 GMT+02:00 akoeplinger alex.koeplin...@outlook.com:

 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

[Martin Thwaites]

Is this something that we can unit test to verify against .Net?
On 24 Oct 2014 13:26, Etienne Champetier champetier.etie...@gmail.com
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 mar...@my2cents.co.uk:

 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 champetier.etie...@gmail.com
 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

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com 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

[Martin Thwaites]

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 mig...@xamarin.com 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 mig...@xamarin.com 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 mig...@xamarin.com 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

[Martin Thwaites]

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] ASP.NET 4.5 Async Pipeline

[Martin Thwaites]

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 mig...@xamarin.com 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] ASP.NET 4.5 Async Pipeline

[Martin Thwaites]

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 monofo...@my2cents.co.uk
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 mig...@xamarin.com 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

[Martin Thwaites]

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 mig...@xamarin.com 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] Unit testing when it's protected

[Martin Thwaites]

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

[Mono-dev] ASP.NET 4.5 Async Pipeline

[Martin Thwaites]

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] State of aspnetwebstack on mono

[Martin Thwaites]

Hi Daniel,

I'm referring to all the work coming out of the aspnetwebstack repository
on codeplex.  I don't think MVC 6 is being developed there yet.

Currently that cover MVC and Webapi that I know of, but there could be
others.  It essentially the codebase used to create the nuget packages.

I actually hit a little snag last night in that after stubbing
everythingthat shouldn't be relevant, I've got to a point where all
typeload exceptions are gone in WebAPI.  However, all Webapi requests just
result in an endless request to the server.  So this may be a fruitless
journey.  On the plus side, MVC 5.2.2 works out of the box it seems.

Thanks,
Martin
On 20 Oct 2014 02:43, Daniel Lo Nigro li...@dan.cx wrote:

 By aspnetwebstack do you mean the current ASP.NET stack or do you mean
 ASP.NET vNext?

 On Sun, Oct 19, 2014 at 1:37 AM, Martin Thwaites monofo...@my2cents.co.uk
  wrote:

 Hi all,

 Just wanted to give a quick update on where I'm at with getting things
 implemented for the aspnetwebstack to work on mono.

 As I've said before, my goal is to make it so that the aspnetwebstack
 solution will compile against mono, without tweaking anything (this is
 stage 1).  It's proving to both a relatively small task, but also very
 taxing in terms of me having to learn quite a lot.

 *Note: I'm not looking at the tests in aspnetwebstack at the moment, that
 will be stage 2, a lot seem to require things we don't have yet.*

 In summary, it's not that far off, and once it's done, at least we'll be
 able to see which methods may need bugfixing as the webstack will load at
 least.  The main issue is getting the PRs approved, but my hope is that if
 we can collate a list of the all, we can ask that they are reviewed
 together and considering they will make one of the most up and coming web
 technologies work on mono, I would say there is a good reason to try and
 prioritise it.

 Here are the current PR's, I've reviewed the ones that aren't mine and
 they now look ok, we just need a contributor to review/merge them.

 PR874 - from Chris Carroll with a few properties implemented around routes
 PR1163 - from AerisG222 which includes a few changes around Unvalidated
 parameters and some other bits
 PR1349 - From me regarding MachineKey.Protect methods
 PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work,
 just the interface)
 PR1354 - From me regarding Request.Abort

 Outstanding items that I could do with help with:


1. ReadEntityBodyMode needs properly implementing
2. Request.GetBufferedInputStream needs implementing.
Request.GetBufferlessInputStream needs implementing (looks like it's
already partially implemented).
3. HttpResponseBase.SuppressFormsAuthenticationRedirect needs
implementing
4. HttpTaskAsyncHandler needs implementing.
5. HttpResponse.ClientDisconnectedToken needs implementing (can just
return CancellationToken.None and it should be fine but a proper
implementation would be better).
6. Do something about System.Data.EntityState, it's supposed to live
in System.Data.Entity.dll which we don't have but MVC checks against.
7. Do something about System.Web.UI.DataVisualization.Charting, I
don't want to have to change the aspnetwebstack code to exclude it, so
maybe just stub it all out?


 I'm planning on doing the HttpTaskAyncHandler next which will probably
 take me a couple of evenings this week.  However, if someone thinks that
 they could do it without extensive learning (which is what I'm going to
 need to do), then by all means take that on and I'll do some of the others.

 I'll let you all know when I get further.
 Martin

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

Hi Miguel,

I did look at the Membership stuff, but it looked to me that the names
made sense, therefore didn't think it was decompiled.

I haven't actually looked at that much so I'll implement it this week.

@Mike, mail me when you're done if you want and I'll review it.

As for the properties, although they should do something to the generated
urls, simply adding them should surely be a valid pull?  the issue at the
moment is that without them, you get an exception even if it should be
false.  I actually think that these are used by other classes when
generating urls, not the route collection itself, but I don't know for
sure.  Considering that adding them is very low risk, can we not just
accept the pull and ask for further work.

Thanks for looking at these Miguel.

Martin
On 20 Oct 2014 19:20, Miguel de Icaza mig...@xamarin.com wrote:

 Hey Mike,

 I would just submit a new pull request purely with code that you wrote,
 excluding any third party code.

 As for the WebRoute, like I mentioned, while it adds the properties, it
 looks broken, the properties *should* do something, currently they dont.


 On Mon, Oct 20, 2014 at 12:32 PM, Mike Morano mmor...@mikeandwan.us
 wrote:

 Miguel,

 I can not apologize enough for the issue you point out in regards to the
 poisoned patch, I had no idea it was sourced from MS.  I have been a big
 mono fan since 2003, and certainly was not trying to jeopardize mono.  As I
 identified in my commit message, I found that from another repo on github
 when I was trying to see if anyone had already implemented this (similar to
 how I found PR874 which was a pre-requisite), though will never do that
 again.

 Are the files outside of the files listed in the other repo acceptable
 (everything except MembershipPasswordAttribute.cs)?

 Sorry,
 Mike



 On Mon, Oct 20, 2014 at 10:06 AM, Miguel de Icaza mig...@xamarin.com
 wrote:

 Hello,

 PR874 - from Chris Carroll with a few properties implemented around
 routes


 While the properties were added, they are not actually used for
 anything, this looks bogus.

 The tests basically show that setting a boolean property back and forth
 is set, but likely what needs to be tested is the other methods it affects.

 The point of these properties is to alter the behavior of the route
 collection.


 PR1163 - from AerisG222 which includes a few changes around Unvalidated
 parameters and some other bits


 This patch is poisoned.

 There were a couple of elements that looked very suspicious, like this
 bit (which also, does not follow the Mono coding guidelines):

 int? _minRequiredPasswordLength;
 int? _minRequiredNonAlphanumericCharacters;
 string _passwordStrengthRegularExpression;

 readonly string _minRequiredPasswordLengthError = {0} must 
 have at least {1} characters;
 readonly string _minNonAlphanumericCharactersError = {0} must 
 have at least {1} special characters;
 readonly string _passwordStrengthError = {0} is weak;


 What are the chances of getting every internal method name to match the
 one in .NET I asked myself?   Close to zero.   So this was clearly
 decompiled and submitted.

 Rejected.  Someone *else* that has not worked on that code will have to
 rewrite this, it is unacceptable to have people contribute decompiled code.

 PR1349 - From me regarding MachineKey.Protect methods


 Added a comment, looks like it could go in, but we need tests for the
 Unprotect path.

 And I would like those to be tested against Windows as well.


 PR1353 - From me regarding ReadEntityBodyMode (doesn't actually work,
 just the interface)


 Simple, merged.


 PR1354 - From me regarding Request.Abort


 Simple, merged.

 Miguel.

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

Hi Miguel,

The code that I'm referring to here is that of the aspnetwebstack on
codeplex.  That is to say that they are not something where you can remove
the code and recompile (unless there as a specific mono implementation
which is not ideal).  The goal is to have the compiled dlls that are
available on nuget work, without tweaking to a person's application.

I'll have a look and see if I can see where it would be used, but still as
you've said on one of my pulls, a half done implementation is better than
none.

Having the application throw a missing method exception should not be the
recommended approach when we can add the property and default it to false.

Thanks, and please don't think that things won't getting better with my
reviews.  I'm learning what you want so I can review better and help reduce
the burden on you and your staff.

Martin
On 20 Oct 2014 20:04, Miguel de Icaza mig...@xamarin.com wrote:

 As for the properties, although they should do something to the generated
 urls, simply adding them should surely be a valid pull?  the issue at the
 moment is that without them, you get an exception even if it should be
 false.  I actually think that these are used by other classes when
 generating urls, not the route collection itself, but I don't know for
 sure.  Considering that adding them is very low risk, can we not just
 accept the pull and ask for further work.

 Nope, all they do is allow some code to be compiled, and then get the
 wrong result.

 You might as well remove the dependency of those properties, and see what
 else breaks on whatever piece of code you are trying to build.

 Miguel

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Review of PR1354 - add Request.Abort()

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
  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

[Martin Thwaites]

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-dev] Do we need to maintain the csproj files?

[Martin Thwaites]

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()

[Martin Thwaites]

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 PR1349

[Martin Thwaites]

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 cricel...@gmail.com 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 monofo...@my2cents.co.uk
 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

[Martin Thwaites]

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

[Martin Thwaites]

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 mig...@xamarin.com 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

Re: [Mono-dev] Mono Encryption

[Martin Thwaites]

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 mig...@xamarin.com 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

[Martin Thwaites]

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 gregoryyou...@gmail.com 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 mig...@xamarin.com
 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 gregoryyou...@gmail.com
 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

[Martin Thwaites]

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 mig...@xamarin.com 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 monofo...@my2cents.co.uk
  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 mig...@xamarin.com 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

[Martin Thwaites]

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 - short description.  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 mig...@xamarin.com 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 mig...@xamarin.com
 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 standard for contributed
 code, and I support maintaining that standard; but a process MUST be
 developed 

[Mono-dev] Review of PR1349

[Martin Thwaites]

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-list] System.IO.Package

[Martin Thwaites]

I've always used Npoi, however I'm not sure if it's mono compatible.
On 16 Oct 2014 03:57, 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 Maury Markowitz
 
  I'm testing the waters for a Mono/Xamarin port of an existing VB.net code
  base. The important part of this code uses System.IO.Package to read and
  write Excel-compatible files. I see that there is some level of support
 for
  Package in Mono's WindowsBase, but this does not appear to be part of the
  standard build.
 
  Can anyone offer a little color on this package? Is it suitable for
  production? If so, how would I go about building it on Windows/VS? Most
 of
  the examples here appear to assume Unix and/or CLI builds.
 
  Perhaps someone has a built version as a PCL DLL they might be willing to
  send me?

 I'm just guessing it's not in great shape.  My personal experience is that
 it's good to use mono core assemblies and try to avoid doing anything in
 lesser traveled areas - unless I'm mistaken, WindowsBase is probably pretty
 far down the list of things that are useful to Xamarin and hence, probably
 doesn't get much maintenance attention.  At a glance, I noticed, the latest
 commit to System.IO.Packaging was 2 months ago, (which is the most recent
 thing in WindowsBase).

 It was unfortunately a trivial small change, and prior to that, nothing in
 there had been touched in a couple of years.  So *either* it's so rock
 solid and stable that it doesn't need maintenance anymore, or it's just not
 getting maintained.  I'm going to have to say, it's clearly the latter.

 So there's your answer.  That particular assembly is unfortunately out of
 maintenance for now.  Have you considered http://GemboxSoftware.com?  I'm
 sure there are other packages out there for editing excel files.  Gembox is
 the one I'm aware of and have used.
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Resx files in Mono

[Martin Thwaites]

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-list] Asp.Net questions

[Martin Thwaites]

I run an MVC 3 site on mono, however I build from source.  Not sure if that
helps.
 On 7 Oct 2014 12:52, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: Edward Ned Harvey (mono)
 
  On ubuntu server 12.04 x86_64, the default included version of mono is
  archaic (2.10).  And the xamarin apt repos seem to be also broken (Hash
 Sum
  mismatch).
 
  On ubuntu server 14.04 x86_64, the built-in version of mono is reasonable
  (3.2.8) but when installing libapache2-mod-mono and mono-apache-server2,
  apt simply hangs.

 Oops.  I meant 14.04 in the second one.  Corrected above.
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Updating aspnetwebstack

[Martin Thwaites]

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-list] Serving cshtml files as parsed.

[Martin Thwaites]

I'm trying to run a solution on mono that uses cshtml files without using
MVC.

On Windows, the files are parsed and served, however, on mono it's throwing
them back as if they are static files.

I'm sure I'm missing something obvious, but just can't get my head around
it.

Anyone got any advice?

Thanks,
Martin
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Serving cshtml files as parsed.

[Martin Thwaites]

Thanks Fernando, couple of things I forgot to add...

It's running through XSP in debug through MonoDevelop.  Secondly, it's not
MVC that I'm trying to run.  It's a static cshtml that's self contained.

i.e. admin/index.cshtml, I need it to be processed and served.

Thanks,
Martin

On 28 September 2014 22:12, Fernando Rodriguez 
frodriguez.develo...@outlook.com wrote:

 On Sunday 28 September 2014 9:47:53 PM Martin Thwaites wrote:
  I'm trying to run a solution on mono that uses cshtml files without using
  MVC.
 
  On Windows, the files are parsed and served, however, on mono it's
 throwing
  them back as if they are static files.
 
  I'm sure I'm missing something obvious, but just can't get my head around
  it.
 
  Anyone got any advice?
 
  Thanks,
  Martin

 Did you configure the web server to handle .cshtml files by mono?

 Also to get MVC4 working on mono (I could never get MVC5 working)  I had to
 copy all the System.Web.WebPages.* and Razor assemblies to my bin
 directory so
 you may need to do the same.


 --
 Fernando Rodriguez
 frodriguez.develo...@outlook.com
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] System.Json string handling

[Martin Thwaites]

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 hzj_...@hotmail.com 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) edward.harvey.m...@clevertrove.com
 Sent: ‎21/‎9/‎2014 3:13
 To: Miguel de Icaza mig...@xamarin.com; 何子杰Hzj_jie hzj_...@hotmail.com
 Cc: Steffen Kieß steffen.ki...@ipvs.uni-stuttgart.de;
 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

Re: [Mono-list] Running ASP.Net 4.5 MVC Application on Mono

[Martin Thwaites]

The namesakes for views are imported from the Web.config in the views
directory, that could be your issue there.

Glad you got it working.

Martin
On 18 Sep 2014 05:18, Fernando Rodriguez frodriguez.develo...@outlook.com
wrote:

 On Wednesday 17 September 2014 10:25:47 PM Martin Thwaites wrote:
  Have you tried the MVC3 boilerplate solution, even just the one that is
  generated from Visual Studio?

 I got it. I've tried so many things I'm not exactly sure which of them
 make a
 difference but I think:

 1. Build against mono's System.Web.Mvc v3.0.0.0. If I build it on Windows
 the
 redirect thing on Web.config doesn't seem to work.

 2. Do not reference System.Web.WebPages.* but do copy then to the bin
 directory after building. Apparently they're only needed a runtime to
 compile
 the views. If I reference them it throws an exception on startup.

 3. Make sure every reference to System.Web.Mvc on web.config is to version
 3.0.0.0 and WebPages to version 2.0.0.0 and add the assemblyBinding
 redirect
 thing for all of them. I actually got merged versions of the Web.Configs
 for
 this and the MVC3 solution, I'll clean them up tomorrow.

 The namespaces defined on Web.config are not being imported into the Views,
 either that or some of the bundled packages are getting loaded but I'll
 figure
 that out tomorrow.

 Thanks for the help.

 --
 Fernando Rodriguez
 frodriguez.develo...@outlook.com
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Running ASP.Net 4.5 MVC Application on Mono

[Martin Thwaites]

You're running a fork, not mono's main, therefore you may (and probably
don't) have the latest version.  Try with the main repository.

The main thing missing in mono at the moment as far as I'm aware is the
async controllers and all the new identity stuff.

The @ syntax is the Razor View engine, that was MVC 3 and that works fine
on mono as all my sites use it.

To be honest it looks like an issue with configuration or your
installation.  Try running directly through monodevelop.  when you get the
view error, the actual compilation error appears in the output window.

Thanks
Martin
On 17 Sep 2014 01:41, Fernando Rodriguez frodriguez.develo...@outlook.com
wrote:

 On Tuesday 16 September 2014 11:39:00 PM Martin Thwaites wrote:
  The error around no view engine appears no matter what the error is in
 your
  view.  Also of the time I get it due to the view not being able to
  compiled, not missing.  Things like incorrect syntax in the view throw
 that
  error.

 That's what I'm thinking, the syntax is valid for MVC5 but not MVC3 or
 whatever mono supports. Do you know what version introduced the @ syntax? I
 noticed that the MVC3 solution created by MonoDevelop uses server side tags
 instead. All I'm doing on the views is displaying fields from the model
 and I
 got maybe 1 or 2 if statements on the whole app.

 According to this guys: https://bugzilla.xamarin.com/show_bug.cgi?id=16475
 the
 problem was fixed back in february but on the current github version is not
 fixed. Also he posts the output of mono --version and it shows 4.0.0 but I
 built from the current github tree and the version is 3.10.2.

 Do you know how can I got the same github version he got? His output show
 it
 was master/5597172 I tried:

 git checkout 5597172

 and I haven't built that one yet but I ran autogen.sh and looked at the
 Makefile and it still shows version 3.10.2.

 I'm building this fork right now: https://github.com/matthid/mono

  Viewbag was Atleast MVC3 I think.  So that error could be your issue.
 Does
  the solution run in IIS on windows without mono?
 
  If you don't know that you have a working installation yet, I'd try
 running
  a barebones example solution first.

 I'm only using the ViewBag for debugging to display exceptions if something
 goes wrong so I just created a class with an Error property that may be
 wrong
 (does every requests gets it's own controller instance) but right now all I
 want is to get it to run.

 It works fine on IIS, on Visual Studio Web Server and on XSP (MonoDevelop)
 on
 Windows but I think is running on that .NET even though it uses some mono
 assemblies.

 Thanks for your time.

 --
 Fernando Rodriguez
 frodriguez.develo...@outlook.com
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Running ASP.Net 4.5 MVC Application on Mono

[Martin Thwaites]

Have you tried the MVC3 boilerplate solution, even just the one that is
generated from Visual Studio?

On 17 September 2014 20:20, Fernando Rodriguez 
frodriguez.develo...@outlook.com wrote:

 That last message I sent this this morning but it didn't get posted cause
 sombody unsubscribed me.

 If I check local copy for any of my references a everything gets copied to
 my
 bin directory, but now all the them are the right ones (I diff them
 against the
 ones in lib/mono/4.5) including System.Web.Mvc.dll. But then I'm back to
 this
 exception:

 System.MissingMethodException: Method not found:
 'System.Configuration.IConfigurationSectionHandler.Create'.
   at

 System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection
 (System.String configKey) [0xd] in

 /usr/src/mono/mono-3.8.0/mcs/class/System.Configuration/System.Configuration/ClientConfigurationSystem.cs:62
   at System.Configuration.ConfigurationManager.GetSection (System.String
 sectionName) [0x0] in

 /usr/src/mono/mono-3.8.0/mcs/class/System.Configuration/System.Configuration/ConfigurationManager.cs:162
   at System.Configuration.ConfigurationManager.get_AppSettings ()
 [0x0] in

 /usr/src/mono/mono-3.8.0/mcs/class/System.Configuration/System.Configuration/ConfigurationManager.cs:176
   at Mono.WebServer.XSP.Server.get_AppSettings () [0x1] in
 /usr/src/mono/xsp-3.0.11/src/Mono.WebServer.XSP/main.cs:244
   at Mono.WebServer.XSP.Server+ApplicationSettings..ctor () [0x0002b] in
 /usr/src/mono/xsp-3.0.11/src/Mono.WebServer.XSP/main.cs:65


 If I delete System.Configuration.dll from the bin directory (or just
 uncheck
 local copy) then the app runs and I get the error that we where discussing
 before I suppose because my Web.config doesn't get loaded?

 However when I run it on monodevelop I can see the paths of the loaded
 assemblies and it's loading the same assembly that I had on the bin
 directory
 so it's confusing. I also noticed that when I get the error about the views
 none of the Mvc or Razor assemblies got loaded.

 I found several posts about this issue but the solution seems to always be
 to
 make sure there is a symlink to xsp.exe and mod-mono-server.exe on the
 right
 framework directory and that the shell script used to run it uses it but
 that's already done on my system.

 My project is set to target Mono / .NET 4.5 and I got the right mono
 runtime
 (3.8.0) selected on MonoDevelop what am I missing?

 Thanks
 Fernando


 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Running ASP.Net 4.5 MVC Application on Mono

[Martin Thwaites]

Have you made sure to remove the Microsoft.Web.Infrastructure.dll file...

There is a tutorial somewhere about running MVC 3 on mono (which I do with
great success).  There a few files that you need to make sure are not
deployed as part of your application.

That said, I've not tried anything 4.5 related on mono yet.

Also, you could try compiling from git, it maybe more upto date that the
tarball.

Hope that helps
Martin
On 16 Sep 2014 05:41, Fernando Rodriguez frodriguez.develo...@outlook.com
wrote:

 Hi,

 I'm trying to get an Asp.Net 4.5 MVC app to run on mono and I'm getting the
 error shown bellow (also posted here). I get the same error in apache using
 mod_mono as in xsp4. I built mono, xsp, and mod_mono on the server from the
 latest tarball releases (simple ./configure  make  make install). Other
 Asp.Net applications run fine on the same server (targetting earlier
 runtimes).
 The server run Gentoo and I remove all mono, xsp, and mod_mono packages
 before
 building the source.

 I found several posts that suggest a bug in xsp (don't apply since I'm
 using
 latest tarball and also tried earlier versions) or mono loading the wrong
 framework version stack trace and exception message suggest is loading the
 right assemblies (most assemblies on the 4.5 directory are symlinks to
 4.0). I
 did tried to run xsp.exe with mono ---runtime=v4.5 and it tells me it's not
 available, same for 4.0 but it is available and the and the exception shows
 it's using it.

 The application was built on Windows with Visual Studio but I also built on
 MonoDevelop (Xamarin) on Windows to target Mono. It does not use any
 external
 references except for PayPal's API Library but I used this same library on
 other applications that run on mono so that shouldn't be the problem. I'm
 trying to setup a parallel mono environment on a Linux desktop to compile
 it
 on Linux to see if it makes a difference (my distro's version are really
 outdated).


 Another thing I noticed is that Visual Studio copies all the Mvc and Razor,
 etc assemblies to the bin folder, if I delete them mono wines about not
 finding
 them even though there's Mono's implementation on the GAC (which I believe
 are
 built from the same source). Also in the Visual Studio generated
 Web.config the
 httpRuntime and other tags had a targetFramework=4.5 attribute, and I
 had
 to remove it cause mono wined about it (unrecognized attribute or something
 like that). Yet the same Web.config works fine in Mono under Windows.

 I think that's all I got, suggestions are appreciated.

 Exception caught during reading the configuration file:
 System.MissingMethodException: Method not found:
 'System.Configuration.IConfigurationSectionHandler.Create'.
   at

 System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection
 (System.String configKey) [0x0] in filename unknown:0
   at System.Configuration.ConfigurationManager.GetSection (System.String
 sectionName) [0x0] in filename unknown:0
   at System.Configuration.ConfigurationManager.get_AppSettings ()
 [0x0] in
 filename unknown:0
   at Mono.WebServer.XSP.Server.get_AppSettings () [0x0] in filename
 unknown:0
   at Mono.WebServer.XSP.Server+ApplicationSettings..ctor () [0x0] in
 filename unknown:0
 xsp4
 Listening on address: 0.0.0.0
 Root directory: /var/www/stage.fernansoft.net
 Listening on port: 8080 (non-secure)
 Hit Return to stop the server.
 Missing method

 System.Configuration.IConfigurationSectionHandler::Create(object,object,XmlNode)
 in assembly /usr/local/lib64/mono/4.0/System.dll, referenced in assembly
 /usr/local/lib64/mono/4.0/System.Configuration.dll
 Missing method
 System.Configuration.ConfigurationManager::get_AppSettings() in
 assembly

 /usr/local/lib64/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll,
 referenced in assembly

 /usr/local/lib64/mono/gac/Mono.WebServer2/0.4.0.0__0738eb9f132ed756/Mono.WebServer2.dll
 Missing method
 System.Configuration.ConfigurationManager::get_AppSettings() in
 assembly

 /usr/local/lib64/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll,
 referenced in assembly /usr/local/lib64/mono/4.0/System.Web.dll
 Missing method
 System.Configuration.ConfigurationManager::get_AppSettings() in
 assembly

 /usr/local/lib64/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll,
 referenced in assembly /usr/local/lib64/mono/4.0/System.Web.dll
 Missing method

 System.Configuration.ConfigurationProperty::.ctor(string,Type,object,TypeConverter,ConfigurationValidatorBase,ConfigurationPropertyOptions)
 in assembly

 /usr/local/lib64/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll,
 referenced in assembly /usr/local/lib64/mono/4.0/System.Web.dll


 -
 Fernando Rodriguez
 frodriguez.develo...@outlook.com
 ___
 Mono-list maillist  -  

Re: [Mono-list] Running ASP.Net 4.5 MVC Application on Mono

[Martin Thwaites]

That last error is misleading.  I think someone did look into fixing the
error message.  It basically masks the underlying error.  Check your logs,
you'll probably see the actual error.

In terms of the packages ending up in bin... From your description you
appear to missing how references work.  Deleting the nuget packages doesn't
stop things from being copied in.  It's how you define the reference in the
csproj file (by defining copy local as true).  Apologies if you knew
that, but your description wasn't clear.

Also, you shouldn't really be referencing the assemblies with a full path,
you should do it through the GAC.

There was a PR for the append trailing slash one, not sure where it ended
up though.

What I would say though is, what are you using that requires MVC 4? Could
you revert to MVC3? As that does work on mono.
On 16 Sep 2014 20:07, Fernando Rodriguez frodriguez.develo...@outlook.com
wrote:

 Thanks for the replies.

 I did made some progress, that specific error is my xsp was quite old, I
 built
 it from the latest tarball on Mono's website but it is outdated, so I had
 to
 get it from github.

 After that I got another missing method exception:
 System.Web.Routing.RouteCollection.get_AppendTrailingSlash. This method
 does
 not exist currently in mono (I read it's on the current github tree but
 not on
 releases). So obviously it's because my app was using MS assemblies.

 So I installed Mono and MonoDevelop 5.1 from tarballs on a desktop. Then
 opened the solution removed all Package References and added References to
 the
 right assemblies on /usr/local/lib/mono/4.5 and deleted everything in the
 bin
 directory. It still wouldn't compile because it doesn't find the ViewBag
 property on the Controller class (I guess because it's a dynamic type and I
 guess Mono can't handle it), so I created quick custom ViewBag extension
 and
 it compiled but I still get the same error so I look on the bin directory
 and
 they're back! I don't know where MonoDevelop got them cause I deleted them
 from packages directory. So I deleted everything from the bin directory
 except
 for my DLL and a couple third party DLLs (everything else is in the GAC),
 then
 without recompiling I ran from my project directory root.

 xsp4 --root . --applications /:.

 now I'm getting:

 System.InvalidOperationException
 The view 'Index' or its master was not found or no view engine supports the
 searched locations. The following locations were searched:
 ~/Views/Default/Index.aspx
 ~/Views/Default/Index.ascx
 ~/Views/Shared/Index.aspx
 ~/Views/Shared/Index.ascx
 ~/Views/Default/Index.cshtml
 ~/Views/Default/Index.vbhtml
 ~/Views/Shared/Index.cshtml
 ~/Views/Shared/Index.vbhtml


 But Views/Default/Index.cshtml is there with rwx permission for everyone.
 As a
 desperate move I even tried copying the View directory to my home
 directory in
 case it was interpreting ~ to be my home dir instead of the app root. So
 right
 now I'm stuck. I'm using the right case on the url. Any suggestions?





 On Tuesday 16 September 2014 3:32:31 PM Martin Thwaites wrote:
  Have you made sure to remove the Microsoft.Web.Infrastructure.dll file...
 
  There is a tutorial somewhere about running MVC 3 on mono (which I do
 with
  great success).  There a few files that you need to make sure are not
  deployed as part of your application.
 
  That said, I've not tried anything 4.5 related on mono yet.
 
  Also, you could try compiling from git, it maybe more upto date that the
  tarball.
 
  Hope that helps
  Martin
  On 16 Sep 2014 05:41, Fernando Rodriguez
 frodriguez.develo...@outlook.com
  wrote:
 
   Hi,
  
   I'm trying to get an Asp.Net 4.5 MVC app to run on mono and I'm getting
 the
   error shown bellow (also posted here). I get the same error in apache
 using
   mod_mono as in xsp4. I built mono, xsp, and mod_mono on the server from
 the
   latest tarball releases (simple ./configure  make  make install).
 Other
   Asp.Net applications run fine on the same server (targetting earlier
   runtimes).
   The server run Gentoo and I remove all mono, xsp, and mod_mono packages
   before
   building the source.
  
   I found several posts that suggest a bug in xsp (don't apply since I'm
   using
   latest tarball and also tried earlier versions) or mono loading the
 wrong
   framework version stack trace and exception message suggest is loading
 the
   right assemblies (most assemblies on the 4.5 directory are symlinks to
   4.0). I
   did tried to run xsp.exe with mono ---runtime=v4.5 and it tells me it's
 not
   available, same for 4.0 but it is available and the and the exception
 shows
   it's using it.
  
   The application was built on Windows with Visual Studio but I also
 built
 on
   MonoDevelop (Xamarin) on Windows to target Mono. It does not use any
   external
   references except for PayPal's API Library but I used this same
 library on
   other applications that run on mono so that shouldn't be the problem.
 I'm
   trying to setup

Re: [Mono-dev] How to run full mono test suites

[Martin Thwaites]

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 liwei.p...@microsoft.com 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