Miguel de Icaza | 28 Mar 15:32 2015

Re: Some MSBuild porting progress

Hello,

Question: does XS/MD depend on Microsoft.Build.Engine.dll?

Because we only would need it if the IDE needed it, and in that case, hopefully we could replace it?

But the idea is to make "xbuild" the script just use the new msbuild.

Miguel

On Sat, Mar 28, 2015 at 12:02 AM, Atsushi Enomoto <atsushi <at> xamarin.com> wrote:
Microsoft.Build.dll is the (relatively) new build engine which
obsoleted Microsoft.Build.Engine.dll. The deprecated one is not in the
msbuild repo and that's what we use in xbuild.

Atsushi Eno


On Sat, Mar 28, 2015 at 4:48 AM, Miguel de Icaza <miguel <at> xamarin.com> wrote:
> Hello,
>
> I was under the impression that there were different versions of the MSBuild
> API?
>
> But I guess we implement the right one?
>
> My main concern was not breaking MonoDevelop, so if we do not break it, we
> should be fine.
>
> Let me know when you think you are ready, and we should incorporate MSBuild
> into Mono's current build setup.
>
> Miguel
>
> On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez <lluis <at> xamarin.com> wrote:
>>
>>
>> El 27/03/2015, a les 19:41, Miguel de Icaza <miguel <at> xamarin.com> va
>> escriure:
>>
>> Hello Lluis,
>>
>> I think once we are happy with msbuild, that we should build msbuild as
>> part of the standard Mono build process and ship the resulting libraries and
>> script.
>>
>> My only concern is whether the public API surface that msbuild has is able
>> to replace the assemblies that we currently install on the GAC.
>>
>>
>> Yes, it does. The assemblies are Microsoft.Build,
>> Microsoft.Build.Framework, Microsoft.Build.Tasks and
>> Microsoft.Build.Utilities. We have partial implementations of those in Mono.
>> The msbuild repo fully implements all of them.
>>
>> We can also use the .targets files included in the msbuild repo. I’ve been
>> able to mostly build MD using the new libraries and using both Mono’s
>> targets files and MS’s targets files. There are a few issues in both cases
>> that should not be hard to fix.
>>
>>
>> If it does, then we can get rid of our implementation, if not, we might
>> have to keep both around until we get everyone out of the xbuild
>> implementation.
>>
>>
>> Miguel
>>
>> On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez <lluis <at> xamarin.com> wrote:
>>>
>>> There is a new xplat branch in the msbuild repo with many fixes to make
>>> it work on Mono. I’ve been doing additional fixes and I could make it work
>>> to build the MonoDevelop solution (some Exec tasks are failing though, due
>>> to missing path conversions). I posted my fixes as PRs to the main repo, and
>>> I keep a branch with all of them in my own repo
>>> (https://github.com/slluis/msbuild/tree/fix-xplat).
>>>
>>> What’s the plan for integrating it into Mono?
>>>
>>> El 19/03/2015, a les 20:40, Miguel de Icaza <miguel <at> xamarin.com> va
>>> escriure:
>>>
>>> Hey guys,
>>>
>>> I used the work from Alex to get started, and did some work on my own.
>>>
>>> I posted all the patches to github.com/mono/msbuild
>>>
>>> When using it to bootstrap building itself, it is not breaking at
>>> invoking NuGet.
>>>
>>> I am out of the office until next week, so I think this is as far I will
>>> get.
>>>
>>> Miguel
>>>
>>>
>>
>>
>

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Miguel de Icaza | 27 Mar 20:48 2015

Re: Some MSBuild porting progress

Hello,

I was under the impression that there were different versions of the MSBuild API?

But I guess we implement the right one?

My main concern was not breaking MonoDevelop, so if we do not break it, we should be fine.

Let me know when you think you are ready, and we should incorporate MSBuild into Mono's current build setup.

Miguel

On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez <lluis <at> xamarin.com> wrote:

El 27/03/2015, a les 19:41, Miguel de Icaza <miguel <at> xamarin.com> va escriure:

Hello Lluis,

I think once we are happy with msbuild, that we should build msbuild as part of the standard Mono build process and ship the resulting libraries and script.

My only concern is whether the public API surface that msbuild has is able to replace the assemblies that we currently install on the GAC.  

Yes, it does. The assemblies are Microsoft.Build, Microsoft.Build.Framework, Microsoft.Build.Tasks and Microsoft.Build.Utilities. We have partial implementations of those in Mono. The msbuild repo fully implements all of them.

We can also use the .targets files included in the msbuild repo. I’ve been able to mostly build MD using the new libraries and using both Mono’s targets files and MS’s targets files. There are a few issues in both cases that should not be hard to fix.


If it does, then we can get rid of our implementation, if not, we might have to keep both around until we get everyone out of the xbuild implementation.

Miguel

On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez <lluis <at> xamarin.com> wrote:
There is a new xplat branch in the msbuild repo with many fixes to make it work on Mono. I’ve been doing additional fixes and I could make it work to build the MonoDevelop solution (some Exec tasks are failing though, due to missing path conversions). I posted my fixes as PRs to the main repo, and I keep a branch with all of them in my own repo (https://github.com/slluis/msbuild/tree/fix-xplat).

What’s the plan for integrating it into Mono?

El 19/03/2015, a les 20:40, Miguel de Icaza <miguel <at> xamarin.com> va escriure:

Hey guys,

I used the work from Alex to get started, and did some work on my own.  

I posted all the patches to github.com/mono/msbuild

When using it to bootstrap building itself, it is not breaking at invoking NuGet.

I am out of the office until next week, so I think this is as far I will get.

Miguel




_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Miguel de Icaza | 27 Mar 19:41 2015

Re: Some MSBuild porting progress

Hello Lluis,

I think once we are happy with msbuild, that we should build msbuild as part of the standard Mono build process and ship the resulting libraries and script.

My only concern is whether the public API surface that msbuild has is able to replace the assemblies that we currently install on the GAC.   If it does, then we can get rid of our implementation, if not, we might have to keep both around until we get everyone out of the xbuild implementation.

Miguel

On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez <lluis <at> xamarin.com> wrote:
There is a new xplat branch in the msbuild repo with many fixes to make it work on Mono. I’ve been doing additional fixes and I could make it work to build the MonoDevelop solution (some Exec tasks are failing though, due to missing path conversions). I posted my fixes as PRs to the main repo, and I keep a branch with all of them in my own repo (https://github.com/slluis/msbuild/tree/fix-xplat).

What’s the plan for integrating it into Mono?

El 19/03/2015, a les 20:40, Miguel de Icaza <miguel <at> xamarin.com> va escriure:

Hey guys,

I used the work from Alex to get started, and did some work on my own.  

I posted all the patches to github.com/mono/msbuild

When using it to bootstrap building itself, it is not breaking at invoking NuGet.

I am out of the office until next week, so I think this is as far I will get.

Miguel


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Greg Young | 27 Mar 14:59 2015
Picon

Build Broken?

I am running into this on a build ubuntu 14.14 box bootstrapped with
3.12.1 (first pull down of sources)

MCS     [net_4_5] mono-symbolicate.exe
MDOC    [net_4_5] cs-errors.tree
Error destroying handle 0x40d mutex due to 16

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native)
System.Threading.InternalThread.Thread_free_internal
(System.Threading.InternalThread,intptr) <0xffffffff>
  at System.Threading.InternalThread.Finalize () <0x0001b>
  at (wrapper runtime-invoke)
object.runtime_invoke_virtual_void__this__
(object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

/home/greg/mono/mono/mini/mono(mono_handle_native_sigsegv+0xf0) [0x4d0280]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc90) [0x7f24022e7c90]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7f2401f4ae37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f2401f4c528]
/home/greg/mono/mono/mini/mono() [0x668389]
/home/greg/mono/mono/mini/mono(monoeg_g_logv+0x4c) [0x6685fc]
/home/greg/mono/mono/mini/mono(monoeg_g_log+0x8f) [0x6686cf]
/home/greg/mono/mono/mini/mono() [0x63739d]
/home/greg/mono/mono/mini/mono(wapi_CloseHandle+0x14) [0x638d54]
/home/greg/mono/mono/mini/mono(ves_icall_System_Threading_InternalThread_Thread_free_internal+0x16)
[0x5b9956]
[0x41f899f1]

Debug info from gdb:

[New LWP 27840]
[New LWP 27839]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f24022e7839 in __libc_waitpid (pid=pid <at> entry=27867,
stat_loc=stat_loc <at> entry=0x7fffbe0c497c, options=options <at> entry=0) at
../sysdeps/unix/sysv/linux/waitpid.c:40
40 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
  Id   Target Id         Frame
  3    Thread 0x7f23ff0f7700 (LWP 27839) "Finalizer" sem_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  2    Thread 0x7f23fe39f700 (LWP 27840) "Threadpool moni"
__clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00,
rem=0xffffffffffffffff) at
../sysdeps/unix/sysv/linux/clock_nanosleep.c:49
* 1    Thread 0x7f2402e0a7c0 (LWP 27824) "mono" 0x00007f24022e7839 in
__libc_waitpid (pid=pid <at> entry=27867,
stat_loc=stat_loc <at> entry=0x7fffbe0c497c, options=options <at> entry=0) at
../sysdeps/unix/sysv/linux/waitpid.c:40

Thread 3 (Thread 0x7f23ff0f7700 (LWP 27839)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x000000000065b386 in mono_sem_wait (sem=sem <at> entry=0x990040
<finalizer_sem>, alertable=alertable <at> entry=1) at mono-semaphore.c:101
#2  0x00000000005dc842 in finalizer_thread (unused=<optimised out>) at gc.c:1093
#3  0x00000000005bc014 in start_wrapper_internal (data=<optimised
out>) at threads.c:664
#4  start_wrapper (data=<optimised out>) at threads.c:711
#5  0x0000000000661a65 in inner_start_thread (arg=0x7fffbe0c5b90) at
mono-threads-posix.c:93
#6  0x00007f24022e00a5 in start_thread (arg=0x7f23ff0f7700) at
pthread_create.c:309
#7  0x00007f240200dcfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f23fe39f700 (LWP 27840)):
#0  __clock_nanosleep (clock_id=1, flags=1, req=0x7f23fe39ed00,
rem=0xffffffffffffffff) at
../sysdeps/unix/sysv/linux/clock_nanosleep.c:49
#1  0x000000000064e410 in wapi_SleepEx (ms=ms <at> entry=500,
alertable=alertable <at> entry=1) at wthreads.c:272
#2  0x00000000005bf15d in monitor_thread (unused=<optimised out>) at
threadpool.c:917
#3  0x00000000005bc014 in start_wrapper_internal (data=<optimised
out>) at threads.c:664
#4  start_wrapper (data=<optimised out>) at threads.c:711
#5  0x0000000000661a65 in inner_start_thread (arg=0x7fffbe0c5190) at
mono-threads-posix.c:93
#6  0x00007f24022e00a5 in start_thread (arg=0x7f23fe39f700) at
pthread_create.c:309
#7  0x00007f240200dcfd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f2402e0a7c0 (LWP 27824)):
#0  0x00007f24022e7839 in __libc_waitpid (pid=pid <at> entry=27867,
stat_loc=stat_loc <at> entry=0x7fffbe0c497c, options=options <at> entry=0) at
../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x00000000004d0317 in mono_handle_native_sigsegv
(signal=<optimised out>, ctx=<optimised out>, info=<optimised out>) at
mini-exceptions.c:2348
#2  <signal handler called>
#3  0x00007f2401f4ae37 in __GI_raise (sig=sig <at> entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#4  0x00007f2401f4c528 in __GI_abort () at abort.c:89
#5  0x0000000000668389 in monoeg_log_default_handler
(log_domain=<optimised out>, log_level=G_LOG_LEVEL_ERROR,
message=<optimised out>, unused_data=<optimised out>) at goutput.c:233
#6  0x00000000006685fc in monoeg_g_logv (log_domain=0x0,
log_level=G_LOG_LEVEL_ERROR, format=<optimised out>,
args=args <at> entry=0x7fffbe0c5900) at goutput.c:113
#7  0x00000000006686cf in monoeg_g_log
(log_domain=log_domain <at> entry=0x0,
log_level=log_level <at> entry=G_LOG_LEVEL_ERROR,
format=format <at> entry=0x719990 "Error destroying handle %p mutex due to
%d\n") at goutput.c:123
#8  0x000000000063739d in _wapi_handle_unref_full (handle=0x40d,
ignore_private_busy_handles=ignore_private_busy_handles <at> entry=0) at
handles.c:1123
#9  0x0000000000638787 in _wapi_handle_unref (handle=<optimised out>)
at handles.c:1173
#10 0x0000000000638d54 in wapi_CloseHandle (handle=<optimised out>) at
handles.c:1346
#11 0x00000000005b9956 in
ves_icall_System_Threading_InternalThread_Thread_free_internal
(this=0x7f2402d36df8, thread=<optimised out>) at threads.c:1103
#12 0x0000000041f899f1 in ?? ()
#13 0x00007f2402d36df8 in ?? ()
#14 0x0000000001744fe0 in ?? ()
#15 0x0000000001744fe0 in ?? ()
#16 0x0000000001a26640 in ?? ()
#17 0x00007f2402d36df8 in ?? ()
#18 0x000000000177ffe0 in ?? ()
#19 0x00007fffbe0c5cc0 in ?? ()

--

-- 
Studying for the Turing test
Jon Curry | 26 Mar 21:39 2015

TDS exception using DBNull.Value in SQL integer parameters

My first post…so here goes.

 

I am attempting to port a large enterprise application to mono, and have been pleasantly surprised at how well most things work.

 

I am hitting one snag executing a SqlCommand that includes a SqlParameter whose data type is SqlDbType.TinyInt (have also tried Int), and whose value is DBNull.Value.

 

I just installed the latest monodevelop last Friday (v5.7).  Any fix or workaround would be appreciated!

 

:::Repro C# code:

 

      private static void SqlTest()

      {

         using ( var con = new SqlConnection( "Application Name=MyApp;Data Source=machinename;Database=MGLatest_Mono;User ID=sa;Pwd=xxx;MultipleActiveResultSets=True" ) )

         {

            con.Open();

 

            using ( var cmd = con.CreateCommand() )

            {

               cmd.CommandType = System.Data.CommandType.StoredProcedure;

               cmd.CommandText = "DoTest";

               cmd.Parameters.Add( new SqlParameter( " <at> byte", System.Data.SqlDbType.TinyInt ) );

               cmd.Parameters[ " <at> byte" ].Direction = System.Data.ParameterDirection.Output;

               // cmd.Parameters[ " <at> byte" ].Value = (byte)0;  // THIS WORKS

               cmd.Parameters[ " <at> byte" ].Value = DBNull.Value;  // THIS FAILS (as does null, or omitting)

               cmd.ExecuteNonQuery();

               Console.WriteLine( cmd.Parameters[ " <at> byte" ].Value );

            }

         }

      }

 

:::Repro Store Proc:

 

create proc DoTest( <at> byte tinyint output)

as

set <at> byte = 238

 

:::Exception:

Unhandled Exception:

System.Data.SqlClient.SqlException: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 1 (" <at> byte"): Data type 0x26 has an invalid data length or metadata length.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Slide | 26 Mar 20:28 2015
Picon

NRE when using pointers on armhf

I am trying to compile and use the ZeroC Ice remoting library for armhf to run on my RaPi 2. The compilation goes fine, but when running the test suite I am getting a NullReferenceException on the pointer assignment in the following code:

fixed(byte* p = &_bytes[_position])
{
    *((float*)p) = _valBytes.floatVal; // exception here
}

This same code works on x86_64, so I am assuming there is something that is missing in the armhf implementation. 

Is there something I can do to debug what might be missing and provide a patch? I've never done work on the mono runtime itself.

Thanks,

slide

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
saurabhgulati159 | 26 Mar 16:45 2015
Picon

Steps to configure ruby on rails on windows

‎Hi,

Please anybody tell me the proper steps do that I can configure ruby on rails on windows 7 there is always a ssl error on starting server or gem please if anyone can take access of my system from teamviewer and install it then please let me it would be a great help


Regards 
Saurabh gulati

Sent from my BlackBerry 10 smartphone.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Gelin Yan | 26 Mar 11:01 2015
Picon

Is mono ready for backend deployment?

Hi All

   A few years ago, I tried to port one of our server from .net to mono. At the time. Mono 2.8 was just out. My server use socket (tcp almost) & thread pools heavily.

    I noticed several crash reports during the tests and some of them were related to mono's gc & threadpool, so finally I gave up.

   Now We are in 2015 and mono has improved quite a bit. I want to know whether it is ready for backend? I founded many successful cases with mono but most of them are about mobile development.  Could you share some experience on server side?

  Thanks.

Regards

gelin yan
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Alexander Köplinger | 24 Mar 00:47 2015

Overflowed double->int casts on ARM in MS referencesource

I just noticed this commit by <at> spouliot: https://github.com/mono/mono/commit/298962b7ddd5e3af33c3177e8523cc36da4de553
 
In my opinion, this isn't the right approach, we should rather fix the cases where a cast would overflow in MS referencesource code rather than changing the tests.
 
I sent a PR a week or so ago that fixes the particular DateTime tests on ARM by explictly checking if the value fits into long, which I think is better: https://github.com/mono/referencesource/pull/8
 
There are a couple more of these overflows in MS code that make tests fail and I think we should discuss what the best approach is. What are your thoughts?
 
-- Alex
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Greg Young | 21 Mar 01:17 2015
Picon

Profiler Name

Am I going totally nuts or is there a max length on profiler name of about 8?

Just wasted a lot of time about why it couldn't find my renamed profiler.

Renamed it eventually to foo and the same .so is now found and works.

If so this could probably be worth a doc.

Cheers,

Greg

--

-- 
Studying for the Turing test
Miguel de Icaza | 19 Mar 20:40 2015

Some MSBuild porting progress

Hey guys,

I used the work from Alex to get started, and did some work on my own.  

I posted all the patches to github.com/mono/msbuild

When using it to bootstrap building itself, it is not breaking at invoking NuGet.

I am out of the office until next week, so I think this is as far I will get.

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

Gmane