Edward Ned Harvey (mono | 24 Apr 17:14 2014

build failures

I am attempting to build on Ubuntu server 12.04, Ubuntu server 14.04, and OSX Mavericks.

 

On all 3 platforms, 3.2.8 builds fine, and on all 3 platforms, 3.4.0 failed...  I checked out 2014-04-11-8df0121, which also failed, 2014-04-23-ff938b5, which also failed...

 

I don't believe this is relevant, but I fetched 3.4.0 from tarball, while I fetched the others with "svn export -r 101768" and just simply "svn export" which I did last night to get the ff938b5

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Martin Thwaites | 23 Apr 20:56 2014
Picon

DynamicModuleHelper and HttpApplication RegisterModule methods

First, I'm not asking for something to be implemented, I'm asking for help implementing it as I think there will be more and I'm endeavoring to implement them all if possible.

I'm having a play with trying to get the MVC5 boilerplate working on mono and one of the libraries (Microsoft.Owin) uses the new HttpApplication.RegisterModule method, which is not yet present in the current master branch.

Looking at the descriptions on MSDN, there is very little information on what it's supposed to do, but it looks like it just does the same as the method DynamicModuleHelper.RegisterModule... in that it just registers a module at runtime, in memory.

So, in light of the above, I have a few questions.
1. Would a pull be accepted if it just copies the implementation from the Microsoft.Web.Infrastructure class in the current mono codebase?  Given that the new method is in the HttpApplication class, I would say that it's a valid assumption that it's only Web modules that can be added.
2. If I'm just copying the implementation into System.Web, would it be advisable to edit the Microsoft.Web.Infrastructure class to just forward through to System.Web?
3. What, if any, tests should be created (I'm used to working in an environment with interfaces that could be mocked with Moq).  I could do with some information on how to do this, in terms of possibly some examples that are considered good, and locations in the current codebase.
4. Given that this is only available in .NET 4.5, is there some way I should stop it from being accessible on .NET 4.0 (if so, how)? I'm not sure there is an issue with leaving it available on .NET 4.0 other than the mono version has more methods than .NET...

References:

http://msdn.microsoft.com/en-us/library/microsoft.web.infrastructure.dynamicmodulehelper.dynamicmoduleutility.registermodule%28v=vs.111%29.aspx
http://msdn.microsoft.com/en-us/library/system.web.httpapplication.registermodule%28v=vs.110%29.aspx
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Edward Ned Harvey (mono | 22 Apr 23:39 2014

System.Security.Authentication.ExchangeAlgorithmType 44550

Just FYI, in case for some reason I neglect to commit an update.  Microsoft has already deployed to the wild,
code updates that cause an ExchangeAlgorithmType to evaluate to 44550, which is an undocumented value. 
For shame.   ;-)   

When they update MSDN, I plan to commit the new info to mono, but for now, it's unknown what it will be.  I do know
44550 corresponds to an ECDH Ephemeral key exchange, and obviously mono is nowhere near supporting that,
but it will be important to update the enum with the new value, to prevent compile errors.

http://msdn.microsoft.com/en-us/library/vstudio/system.security.authentication.exchangealgorithmtype(v=vs.100).aspx
and
http://social.msdn.microsoft.com/Forums/vstudio/en-US/d0298622-a7cc-40e8-a4bf-8b74696ff548/sslstreamkeyexchangealgorithm-44550?forum=netfxbcl
Miguel de Icaza | 22 Apr 21:53 2014

Repeat builds of core assemblies

Hey guys,

I was looking at making the MSBuild system work, and during the process I have encountered a few problems that we have in our existing build system that are problematic.

The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies.   So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration.   Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on.

To build a complete System.dll for a particular profile (net_2_0, net_4_0, etc) takes three steps: 
  • Core Build
  • Secondary Build:
    • Core Build + 
    • Defines: XML_DEP + SECURITY_DEP
    • Refs: 
      • -r:PrebuiltSystem=../lib/Previous/System.dll 
      • -r:System.Xml.dll
      • -r:MonoSecurity=Mono.Security.dll
  • Final Build:
    • Secondary Build + 
    • defines: -d:CONFIGURATION_DEP
    • Refs:
      • System.Configuration.dll
The above is what is required to bring up System.

Our implementation has one major problem: it overwrites the intermediate files.  So the core build output is overwritten by the secondary build, and the secondary build is overwritten by the final build.

It seems that historically, instead of introducing temporary directories for each stage, instead we hacked our way out of it.   We introduced a LIBRARY_USE_INTERMEDIATE_FILE whose sole purpose was to work around the case where Windows was actively telling us we were doing something wrong (we were overwriting a file that we were actively referencing!)

The above is also likely going to prevent reliable parallel builds, or probably means that we introduced some gross hack to make the above work in parallel.

I am going to try to fix this, but the Makefile goop is pretty dense, and I might fail.   I just figured I should share my findings in case civilization comes to an end and a future archeologist tries to figure out why this was not working.

These are the defines that we use to bring up System for each profile:

basic Profile:

basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0

basic: -d:NET_1_1 -d:NET_2_0 -d:BOOTSTRAP_BASIC -d:CONFIGURATION_2_0 -d:XML_DEP


Build Profile:

build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0

build: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0  -d:XML_DEP


Net 2.0 profile:

net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0

net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0  -d:XML_DEP -d:SECURITY_DEP 

net_2_0: -d:NET_1_1 -d:NET_2_0  -d:CONFIGURATION_2_0  -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP 


Net 4.0 profile:

net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0

net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 -d:XML_DEP  -d:SECURITY_DEP

net_4_0: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:CONFIGURATION_2_0 -d:XML_DEP  -d:SECURITY_DEP  -d:CONFIGURATION_DEP


Net 4.5 profile:

net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0 

net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0 -d:XML_DEP  -d:SECURITY_DEP 

net_4_5: -d:NET_1_1 -d:NET_2_0 -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -d:NET_4_5 -d:CONFIGURATION_2_0  -d:XML_DEP -d:SECURITY_DEP -d:CONFIGURATION_DEP 


Miguel
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Edward Ned Harvey (mono | 21 Apr 23:03 2014

Re: bug in Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.LocalValidation

> From: Edward Harvey
> Sent: Tuesday, April 8, 2014 2:35 PM
> 
>             // const string hostname = "telefolder.vgocom.net";    // works
>             const string hostname = "telefolder.clevertrove.net";

Update:  I changed the name of telefolder.clevertrove.net, to synctuary.clevertrove.net, and
regenerated the cert, but still have the problem on that new cert, and not with any other certs on any other servers.
Edward Ned Harvey (mono | 21 Apr 22:23 2014

Can anyone explain this to me? It's the Bermuda triangle.

I'm trying to figure out why mono is rejecting one of my server's certs (while not rejecting some others).  I sprinkled WriteLines in the mono source, and I ran with --debug --trace

 

The last line I ever reach is 635.  And then exceptions are thrown.  Neither 638 nor 641 is ever displayed.  I don't know of any way this is physically possible.  I do have 6,000 lines of trace log starting with the WriteLine at 635, if anybody's interested to look at it...

 

(from 'mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs')

 

internal override bool OnRemoteCertificateValidation(X509Certificate certificate, int[] errors)

{

    System.Console.Error.WriteLine("NEDDEBUG 'mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs' line 635");

    if (this.ServerCertValidation != null)

    {

        System.Console.Error.WriteLine("NEDDEBUG 'mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs' line 638");

        return this.ServerCertValidation(certificate, errors);

    }

    System.Console.Error.WriteLine("NEDDEBUG 'mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs' line 641");

 

    return (errors != null && errors.Length == 0);

}

 

 

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Vardar Sahin | 21 Apr 12:10 2014
Picon

Re: Compiling a C# project with Xamarin Studio + MonoRuntime does not work.

Here a list of the assemblies which I use. I am not using referencing two version of the same assembly. 

The interesting part is that it compiles fine with the MS .Net compiler and it also compiles fine with XamarinStudio 4.1.9 + Mono Compiler. Its also compiles with the new version of Xamarin Studio when I choose .NET 3.5 Client profile as the target framework. But when I choose "Mono / .NET 3.5" i get this error. 

Error CS0433: The imported type `System.Action<T1,T2>' is defined multiple times (CS0433) (ShugenDoEngine)

Another problem even when its compile with the ".NET 3.5 Client profile" is this.

C:\Program Files (x86)\Mono-3.2.3\lib\mono\4.0\Microsoft.Common.targets: Error: Access to the path "D:\projects\ShugenDoBased\ShugenDoNextGen\ShugenDoSDK\bin\base\managed\ShugenDoEngine.dll" is denied.  at System.IO.File.Delete (System.String path) [0x00000] in <filename unknown>:0 
  at Microsoft.Build.Tasks.Copy.CopyFile (System.String source, System.String dest, Boolean create_dir) [0x00000] in <filename unknown>:0 
  at Microsoft.Build.Tasks.Copy.Execute () [0x00000] in <filename unknown>:0  (ShugenDoEngine)

This error also does not occur in XamarinStudio 4.1.9 and also does not occur with Visual Studio. I will try to create a test case which simulates my project. 

Best
Sahin


2014-04-20 18:32 GMT+02:00 Juan Cristóbal Olivares <cristobal <at> cxsoftware.com>:

Which assemblies are you referencing? Are you sure you are not referencing two versions of the same assembly?

On Apr 20, 2014 1:23 PM, "Vardar Sahin" <sakirsoft <at> gmail.com> wrote:
Hi Guys,

I have a C# project which compiles just fine with Visual Studio. It also compiles when I use Xamarin Studio and the .Net runtime. But when I choose to use the MonoRuntime it does not compile anymore. 

I am using the current version of Xamarin Studio ( 4.2.3 ). Interesting is that when I use an older Version of Xamarin Studio ( 4.1.9 ) + MonoRuntime it works.

I am on Windows and use the latest stable version of mono ( 3.2.3 ).

The compiler error I get is the following. 

Error CS0433: The imported type `System.Action<T1,T2>' is defined multiple times (CS0433) 

Also I have a Warning like this

Warning CS1685: The predefined type `System.Runtime.CompilerServices.ExtensionAttribute' is defined multiple times. Using definition from `mscorlib.dll' (CS1685) 

The signature of the function where the error occurs is this. 

private void ApplyCollision(ulong goId, CollisionData data, Action<ICollisionListener, Collision> func)


Any ideas how to fix this?

Best
Sahin

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Alex J Lennon | 21 Apr 10:01 2014
Picon

Problem with Mono 3.4.0 and config appSettings on ARM target

Hi all,

I've encountered a problem with an application I was running on an ARM
VFP (i.MX6) target
under 3.2.8, which now fails under 3.4.0.

The error reported is related to a problem with the configuration file
and in particular the
<appSettings> element,

I have reduced it down to a simple test case as follows,

Program.cs (compiled to Program.exe)

namespace DynamicDevices
{
  public class ConfigTest
  {
    static void Main()
    {
      // NB. Both old deprecated method and new method of obtaining
configuration values fail
      var v =
System.Configuration.ConfigurationManager.AppSettings["testkey"];
//      var v =
System.Configuration.ConfigurationSettings.AppSettings["testkey"];

      Console.WriteLine("Config key: " + v);
    }
  }
}

Program.exe.config

<configuration>
  <appSettings>
    <add key="testkey" value="testval" />
  </appSettings>
</configuration>

The above runs under 3.2.8 on an x86 target or an ARM VFP target

It also runs under 3.4.0 on an x86 target but when I run on an ARM VFP
target I get the following

Unhandled Exception:
System.Configuration.ConfigurationErrorsException: Error Initializing
the configuration system. --->
System.Configuration.ConfigurationErrorsException: Unrecognized
configuration section <appSettings> (/home/root/Program.exe.config line

<snip/> See: http://pastebin.com/GDKTftr4 for the rest

...

Could anybody advise where I'm going wrong / what I need to look at here?

Many thanks,

Alex Lennon
Vardar Sahin | 20 Apr 18:23 2014
Picon

Compiling a C# project with Xamarin Studio + MonoRuntime does not work.

Hi Guys,

I have a C# project which compiles just fine with Visual Studio. It also compiles when I use Xamarin Studio and the .Net runtime. But when I choose to use the MonoRuntime it does not compile anymore. 

I am using the current version of Xamarin Studio ( 4.2.3 ). Interesting is that when I use an older Version of Xamarin Studio ( 4.1.9 ) + MonoRuntime it works.

I am on Windows and use the latest stable version of mono ( 3.2.3 ).

The compiler error I get is the following. 

Error CS0433: The imported type `System.Action<T1,T2>' is defined multiple times (CS0433) 

Also I have a Warning like this

Warning CS1685: The predefined type `System.Runtime.CompilerServices.ExtensionAttribute' is defined multiple times. Using definition from `mscorlib.dll' (CS1685) 

The signature of the function where the error occurs is this. 

private void ApplyCollision(ulong goId, CollisionData data, Action<ICollisionListener, Collision> func)


Any ideas how to fix this?

Best
Sahin
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Alex Rønne Petersen | 19 Apr 07:44 2014

Pull request testing

Hey folks!

If you're subscribed to notifications for mono/mono you may have just
noticed a flood of comments coming your way. We're testing a Jenkins
setup for building pull requests, and it will ask explicitly for
approval to build pull requests. I didn't expect it to comment on
every already-open pull request, though. Sorry for the noise!

I'll keep this thread updated on progress in setting all this up.

Regards,
Alex
Brandon Perry | 18 Apr 03:14 2014
Picon

Compiler exception on fresh ASP.NET application in Xamarin Studio

Hi, it seems that the XSP server Xamarin Studio starts assumes 'mcs' will be in the PATH and it isn't, which causes a fresh ASP.NET application to fail with the below linked exception/ I was able to "solve" this by altering my PATH to include the /Library/Frameworks/ installation mono.

PATH="/Library/Frameworks/Mono.framework/Versions/3.2.6/bin/:"$PATH

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Gmane