[Mono-dev] 3.0.6 Windows installer - missing dcms.bat, and why only 32bits

2013-04-06 Thread Jean-Michel.Perraud
Hi,

While trying to use xbuild on Windows I noticed that dmcs.bat seems to be 
missing from the 3.0.6 /bin directory
   
   Microsoft.CSharp.targets: error : Error executing tool 
'C:\PROGRA~1\MONO-3~1.6\bin\dmcs.bat' [...]  Native error= The system cannot 
find the file specified.

I think it is present in the latest 2.10.x stable installer.
Not difficult to work around of course, but I don't think this was mentioned on 
mailing lists yet.

Second question on the Windows installer: is there an intent to distribute 64 
bits out of the box in the near future? I am working on a package that should 
ideally run embedded Mono from 32 or 64 bit processes (namely the R statistical 
software). While I know this is doable, a Mono installer that sets up both 
architectures on Windows would make it simpler to automate a build against 32 
and 64 bits of mono-2.0.dll.

Is there interest/plan from the maintainers of the Windows installer to upgrade 
to support both architecture? I am mindful that this is probably no small 
amount of work to set up.

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


[Mono-dev] 3.0.6 Windows installer - missing dcms.bat, and why only 32bits

2013-04-06 Thread Jean-Michel.Perraud
Hi,

While trying to use xbuild on Windows I noticed that dmcs.bat seems to be 
missing from the 3.0.6 /bin directory
   
   Microsoft.CSharp.targets: error : Error executing tool 
'C:\PROGRA~1\MONO-3~1.6\bin\dmcs.bat' [...]  Native error= The system cannot 
find the file specified.

I think it is present in the latest 2.10.x stable installer.
Not difficult to work around of course, but I don't think this was mentioned on 
mailing lists yet.

Second question on the Windows installer: is there an intent to distribute 64 
bits out of the box in the near future? I am working on a package that should 
ideally run embedded Mono from 32 or 64 bit processes (namely the R statistical 
software). While I know this is doable, a Mono installer that sets up both 
architectures on Windows would make it simpler to automate a build against 32 
and 64 bits of mono-2.0.dll.

Is there interest/plan from the maintainers of the Windows installer to upgrade 
to support both architecture? I am mindful that this is probably no small 
amount of work to set up.

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


Re: [Mono-dev] TypeForwardedFrom

2013-04-06 Thread Robert Jordan

On 04.04.2013 20:57, Neale Ferguson wrote:

Hi,
  I¹m looking at fixing an incompatibility between .NET and Mono when it
comes to Serialization. Bugzilla 11294 describes the situation but in brief
it is a case that when .NET serializes something that has a
TypeForwardedFrom attribute that information gets put into the serialized
object, but mono does not. It appears that all mono does when it encounters
that attribute it simply stores it away and nothing uses it. To emulate the
.NET behavior that information needs to be accessible in metadata about the
type and that information uses by the Serializers.
  I¹m trying to work out how the information captured by
TypeForwardedFromAttribute.cs can be made available at runtime to the
serializer. My knowledge of how mcs operates and what the contents of
metadata are and how to access them is my roadblock. So any reading/code
that I can be directed to would be a great help.



You don't need to know how mcs operates. The TypeForwardedFrom
information can be obtained via reflection:


public static class TypeExtensions
{
// Returns the assembly name of a type while considering
// TypeForwardedFromAttribute.
public static string GetAssemblyName (this Type self)
{
		var attrs = self.GetCustomAttributes(typeof 
(TypeForwardedFromAttribute), false);

if (attrs.Length == 0)
return self.Assembly.FullName;
else
return ((TypeForwardedFromAttribute)attrs 
[0]).AssemblyFullName;
}
}


I've attached a full sample which proves that MS.NET is simply
emitting TypeForwardedFromAttribute.AssemblyFullName for the
assembly name during serialization.

Robert

using System;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Runtime.CompilerServices;

public static class TypeExtensions
{
	public static string GetAssemblyName (this Type self)
	{
		var attrs = self.GetCustomAttributes(typeof (TypeForwardedFromAttribute), false);
		if (attrs.Length == 0)
			return self.Assembly.FullName;
		else
			return ((TypeForwardedFromAttribute)attrs [0]).AssemblyFullName;
	}
}

[TypeForwardedFrom(SomeOtherAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)]
[Serializable]
public class TestClass
{
}

public class Program
{
	static void Main ()
	{
		Console.WriteLine (TypeForwardedFrom:);
		Console.WriteLine (typeof (TestClass).GetAssemblyName ());

		Console.WriteLine (Serialization dump:);
		Dump (new TestClass ());
	}

	static void Dump (object obj)
	{
		using (var stm = new MemoryStream ()) {
			var fmt = new BinaryFormatter ();
			fmt.Serialize (stm, obj);
			Dump (stm.ToArray (), 72);
		}
	}

	static void Dump(byte[] bytes, int width)
	{
		for (int i = 0; i  bytes.Length; i++) {

			byte b = bytes[i];
			if (b  32)
b = (byte) '.';

			Console.Write (Convert.ToChar(b));
			
			if ((i + 1) % width == 0)
Console.WriteLine ();
		}
		if (bytes.Length % width != 0)
			Console.WriteLine ();
	}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list