[meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

Hi all, Autif,

I've been working to support .NET development on Linux
over the past few days.

There is a Visual Studio plugin, MonoTools for Visual Studio
which provides support for local and remote debugging of
.NET applications with Mono.

This requires a remote stub to be running on the target
platform, monotools-server.

I've created a recipe to build monotools-server, which in
turn required me to pull in Openembedded Legacy recipes
for mono-xsp and gtk-sharp.

As it stands I'm now able to build an X enabled image for
the Raspberry Pi and remote-debug some simple Windows
Forms .NET applications within the Visual Studio IDE.

Recipes are hosted here in 'recipes-mono'

git@git.assembla.com:ciseco-eve.meta-eve.git

If there is interest in migrating these recipes into meta-mono
and  somebody will review them then I'll be pleased to make
whatever changes are needed to comply with relevant
Yocto policies.

Best Regards, (& Happy Holidays)

Alex

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Autif Khan]

On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
> Hi all, Autif,
>
> I've been working to support .NET development on Linux
> over the past few days.
>
> There is a Visual Studio plugin, MonoTools for Visual Studio
> which provides support for local and remote debugging of
> .NET applications with Mono.
>
> This requires a remote stub to be running on the target
> platform, monotools-server.
>
> I've created a recipe to build monotools-server, which in
> turn required me to pull in Openembedded Legacy recipes
> for mono-xsp and gtk-sharp.
>
> As it stands I'm now able to build an X enabled image for
> the Raspberry Pi and remote-debug some simple Windows
> Forms .NET applications within the Visual Studio IDE.
>
> Recipes are hosted here in 'recipes-mono'
>
> git@git.assembla.com:ciseco-eve.meta-eve.git
>
> If there is interest in migrating these recipes into meta-mono
> and  somebody will review them then I'll be pleased to make
> whatever changes are needed to comply with relevant
> Yocto policies.

Absolutely!

I am about to embark on a vacation returning to work on Jan 7.

More then - Unfortunately, I will not have time to look at this today
or until Jan 7.

Working hard - then playing hard :-)

I will dig into then when I return.

(Side note - we gave up on GTK# recipe and decided that Windows forms
are 'good enough' for us. This makes me glad :-)

>
> Best Regards, (& Happy Holidays)
>
> Alex
>
>

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Autif Khan]

On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist@gmail.com> wrote:
> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> Hi all, Autif,
>>
>> I've been working to support .NET development on Linux
>> over the past few days.
>>
>> There is a Visual Studio plugin, MonoTools for Visual Studio
>> which provides support for local and remote debugging of
>> .NET applications with Mono.
>>
>> This requires a remote stub to be running on the target
>> platform, monotools-server.
>>
>> I've created a recipe to build monotools-server, which in
>> turn required me to pull in Openembedded Legacy recipes
>> for mono-xsp and gtk-sharp.
>>
>> As it stands I'm now able to build an X enabled image for
>> the Raspberry Pi and remote-debug some simple Windows
>> Forms .NET applications within the Visual Studio IDE.
>>
>> Recipes are hosted here in 'recipes-mono'
>>
>> git@git.assembla.com:ciseco-eve.meta-eve.git

I could not "git clone" the repo.

Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.

If the license is different for monotools-server or mono-xsp or
gtk-sharp, you will likely have to submit a patch for README file too.

Even otherwise, section 4 in README needs to be updated. If you have
any tasks left - please add them to section 10.

The guidelines for the Yocto project are very similar to other FOSS
projects including the Linux kernel. They are outlined here:

https://wiki.yoctoproject.org/wiki/Contribution_Guidelines

I used the following as a guide when I have submitted my patches in
the past. This is for the Linux kernel, adapt as appropriate for
meta-mono.

http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/

Please submit separate patches for each of the recipes (presumably
there are no changes to the mono/libGDI+ recipes)

Please add me to the "To:" recipient (I filter a lot of PATCH related
traffic) - this should allow the emails to be caught by the filter
instead of archiving.

In case I do not respond within 72 hours, please email me with a
gentle reminder :-)

I have not had the opportunity to integrate patches just yet, please
bear with me in case I screw up.

Thanks again for contributing!

PS #1: If you do not want to go thru the hassle - please email me the
tar.gz as an attachment and I will check it in directly - a bad side
effect of this would be that you will not get any "git" credit for
this

PS #2: I am still on vacation, but had a few hours - the 72 hour clock
will start only after Monday :-)

And finally, PS #3:

http://marc.info/?l=linux-usb&m=135229956521385&w=2
http://marc.info/?l=linux-usb&m=135119051922403&w=2
http://marc.info/?l=linux-usb&m=134858043613838&w=2
http://marc.info/?l=linux-usb&m=134791970203982&w=2
... many others ...

Please refrain from top posting :-)

Autif

>> If there is interest in migrating these recipes into meta-mono
>> and  somebody will review them then I'll be pleased to make
>> whatever changes are needed to comply with relevant
>> Yocto policies.
>
> Absolutely!
>
> I am about to embark on a vacation returning to work on Jan 7.
>
> More then - Unfortunately, I will not have time to look at this today
> or until Jan 7.
>
> Working hard - then playing hard :-)
>
> I will dig into then when I return.
>
> (Side note - we gave up on GTK# recipe and decided that Windows forms
> are 'good enough' for us. This makes me glad :-)
>
>>
>> Best Regards, (& Happy Holidays)
>>
>> Alex
>>
>>

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

On 02/01/2013 20:27, Autif Khan wrote:
> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist@gmail.com> wrote:
>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> Hi all, Autif,
>>>
>>> I've been working to support .NET development on Linux
>>> over the past few days.
>>>
>>> There is a Visual Studio plugin, MonoTools for Visual Studio
>>> which provides support for local and remote debugging of
>>> .NET applications with Mono.
>>>
>>> This requires a remote stub to be running on the target
>>> platform, monotools-server.
>>>
>>> I've created a recipe to build monotools-server, which in
>>> turn required me to pull in Openembedded Legacy recipes
>>> for mono-xsp and gtk-sharp.
>>>
>>> As it stands I'm now able to build an X enabled image for
>>> the Raspberry Pi and remote-debug some simple Windows
>>> Forms .NET applications within the Visual Studio IDE.
>>>
>>> Recipes are hosted here in 'recipes-mono'
>>>
>>> git@git.assembla.com:ciseco-eve.meta-eve.git
> 
> I could not "git clone" the repo.

Apologies. I should have given you the public r/o link.

Originally I was trying to avoid modifying meta-mono, adding .bbappends
into my own meta-eve layer instead, but since my last post to you I
found I couldn't build against the current HEAD of Yocto due to some odd
file location issues which I couldn't overlay. (i.e. it didn't seem to
be able to pick up the patches where you had them - although was fine
with an older commit of the Yocto core).

As a result I've moved the original meta-mono patches that weren't being
picked up by bitbake and merged my additions into a fork of meta-mono
which is here:

git://git.assembla.com/ciseco-eve.meta-mono.git

I'm coming up the curve on Git, as I migrate from mainly Subversion use.
Can I issue a "pull request" to you or some such?

> Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.
> 
> If the license is different for monotools-server or mono-xsp or
> gtk-sharp, you will likely have to submit a patch for README file too.
> Even otherwise, section 4 in README needs to be updated. If you have
> any tasks left - please add them to section 10.
> 

Will double check this. I am waiting for feedback from the
monotools-server people on their license as there's nothing explicit in
their source.

> The guidelines for the Yocto project are very similar to other FOSS
> projects including the Linux kernel. They are outlined here:
> 
> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
> 
> I used the following as a guide when I have submitted my patches in
> the past. This is for the Linux kernel, adapt as appropriate for
> meta-mono.
> 
> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
> 
> Please submit separate patches for each of the recipes (presumably
> there are no changes to the mono/libGDI+ recipes)
> 
> Please add me to the "To:" recipient (I filter a lot of PATCH related
> traffic) - this should allow the emails to be caught by the filter
> instead of archiving.
> 
> In case I do not respond within 72 hours, please email me with a
> gentle reminder :-)
> 
> I have not had the opportunity to integrate patches just yet, please
> bear with me in case I screw up.
> 
> Thanks again for contributing!
> 
> PS #1: If you do not want to go thru the hassle - please email me the
> tar.gz as an attachment and I will check it in directly - a bad side
> effect of this would be that you will not get any "git" credit for
> this
> 
> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
> will start only after Monday :-)
> 
> And finally, PS #3:
> 
> http://marc.info/?l=linux-usb&m=135229956521385&w=2
> http://marc.info/?l=linux-usb&m=135119051922403&w=2
> http://marc.info/?l=linux-usb&m=134858043613838&w=2
> http://marc.info/?l=linux-usb&m=134791970203982&w=2
> ... many others ...
> 
> Please refrain from top posting :-)

Happy to try if that's the etiquette here - like this?

> Autif
> 
>>> If there is interest in migrating these recipes into meta-mono
>>> and  somebody will review them then I'll be pleased to make
>>> whatever changes are needed to comply with relevant
>>> Yocto policies.
>>
>> Absolutely!
>>
>> I am about to embark on a vacation returning to work on Jan 7.
>>
>> More then - Unfortunately, I will not have time to look at this today
>> or until Jan 7.
>>
>> Working hard - then playing hard :-)
>>
>> I will dig into then when I return.
>>
>> (Side note - we gave up on GTK# recipe and decided that Windows forms
>> are 'good enough' for us. This makes me glad :-)
>>
>>>
>>> Best Regards, (& Happy Holidays)
>>>
>>> Alex
>>>
>>>

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Autif Khan]

On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
> On 02/01/2013 20:27, Autif Khan wrote:
>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist@gmail.com> wrote:
>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>> Hi all, Autif,
>>>>
>>>> I've been working to support .NET development on Linux
>>>> over the past few days.
>>>>
>>>> There is a Visual Studio plugin, MonoTools for Visual Studio
>>>> which provides support for local and remote debugging of
>>>> .NET applications with Mono.
>>>>
>>>> This requires a remote stub to be running on the target
>>>> platform, monotools-server.
>>>>
>>>> I've created a recipe to build monotools-server, which in
>>>> turn required me to pull in Openembedded Legacy recipes
>>>> for mono-xsp and gtk-sharp.
>>>>
>>>> As it stands I'm now able to build an X enabled image for
>>>> the Raspberry Pi and remote-debug some simple Windows
>>>> Forms .NET applications within the Visual Studio IDE.
>>>>
>>>> Recipes are hosted here in 'recipes-mono'
>>>>
>>>> git@git.assembla.com:ciseco-eve.meta-eve.git
>>
>> I could not "git clone" the repo.
>
> Apologies. I should have given you the public r/o link.
>
> Originally I was trying to avoid modifying meta-mono, adding .bbappends
> into my own meta-eve layer instead, but since my last post to you I
> found I couldn't build against the current HEAD of Yocto due to some odd
> file location issues which I couldn't overlay. (i.e. it didn't seem to
> be able to pick up the patches where you had them - although was fine
> with an older commit of the Yocto core).
>
> As a result I've moved the original meta-mono patches that weren't being
> picked up by bitbake and merged my additions into a fork of meta-mono
> which is here:
>
> git://git.assembla.com/ciseco-eve.meta-mono.git

Got it.

I scanned thru the code and saw what you did to re-organize the
directory structure.

When I get back, I will see if I can build libGDI+ and mono with
denzil (I am stuck with denzil for reasons beyond my control, or until
I find a show stopping bug in denzil for our project - unlikely)

Meanwhile, I have no questions about changes for gk-sharp, mono,
mono-xsp and monotools-server.

Presumably, you will take care of the "TODO: This needs fixing
properly and needs to be revisited" in mono_<version>.bb - I
definitely do not want unstripped binaries on my distribution -
presumably, this was needed for some debugging and is not meant to be
checked into production.

I could not understand the purpose of
libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
could you please help me understand what prompted these seemingly non
trivial changes.

Everything else looks good.

> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
> Can I issue a "pull request" to you or some such?

Yes, a pull request should work.

>> Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.
>>
>> If the license is different for monotools-server or mono-xsp or
>> gtk-sharp, you will likely have to submit a patch for README file too.
>> Even otherwise, section 4 in README needs to be updated. If you have
>> any tasks left - please add them to section 10.
>>
>
> Will double check this. I am waiting for feedback from the
> monotools-server people on their license as there's nothing explicit in
> their source.

Will wait for that. Might affect the README

>> The guidelines for the Yocto project are very similar to other FOSS
>> projects including the Linux kernel. They are outlined here:
>>
>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>
>> I used the following as a guide when I have submitted my patches in
>> the past. This is for the Linux kernel, adapt as appropriate for
>> meta-mono.
>>
>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>
>> Please submit separate patches for each of the recipes (presumably
>> there are no changes to the mono/libGDI+ recipes)
>>
>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>> traffic) - this should allow the emails to be caught by the filter
>> instead of archiving.
>>
>> In case I do not respond within 72 hours, please email me with a
>> gentle reminder :-)
>>
>> I have not had the opportunity to integrate patches just yet, please
>> bear with me in case I screw up.
>>
>> Thanks again for contributing!
>>
>> PS #1: If you do not want to go thru the hassle - please email me the
>> tar.gz as an attachment and I will check it in directly - a bad side
>> effect of this would be that you will not get any "git" credit for
>> this
>>
>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
>> will start only after Monday :-)
>>
>> And finally, PS #3:
>>
>> http://marc.info/?l=linux-usb&m=135229956521385&w=2
>> http://marc.info/?l=linux-usb&m=135119051922403&w=2
>> http://marc.info/?l=linux-usb&m=134858043613838&w=2
>> http://marc.info/?l=linux-usb&m=134791970203982&w=2
>> ... many others ...
>>
>> Please refrain from top posting :-)
>
> Happy to try if that's the etiquette here - like this?
>
>> Autif
>>
>>>> If there is interest in migrating these recipes into meta-mono
>>>> and  somebody will review them then I'll be pleased to make
>>>> whatever changes are needed to comply with relevant
>>>> Yocto policies.
>>>
>>> Absolutely!
>>>
>>> I am about to embark on a vacation returning to work on Jan 7.
>>>
>>> More then - Unfortunately, I will not have time to look at this today
>>> or until Jan 7.
>>>
>>> Working hard - then playing hard :-)
>>>
>>> I will dig into then when I return.
>>>
>>> (Side note - we gave up on GTK# recipe and decided that Windows forms
>>> are 'good enough' for us. This makes me glad :-)
>>>
>>>>
>>>> Best Regards, (& Happy Holidays)
>>>>
>>>> Alex
>>>>
>>>>
>

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

On 03/01/2013 15:24, Autif Khan wrote:
> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
> <ajlennon@dynamicdevices.co.uk> wrote:
>> On 02/01/2013 20:27, Autif Khan wrote:
>>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist@gmail.com> wrote:
>>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>>> Hi all, Autif,
>>>>>
>>>>> I've been working to support .NET development on Linux
>>>>> over the past few days.
>>>>>
>>>>> There is a Visual Studio plugin, MonoTools for Visual Studio
>>>>> which provides support for local and remote debugging of
>>>>> .NET applications with Mono.
>>>>>
>>>>> This requires a remote stub to be running on the target
>>>>> platform, monotools-server.
>>>>>
>>>>> I've created a recipe to build monotools-server, which in
>>>>> turn required me to pull in Openembedded Legacy recipes
>>>>> for mono-xsp and gtk-sharp.
>>>>>
>>>>> As it stands I'm now able to build an X enabled image for
>>>>> the Raspberry Pi and remote-debug some simple Windows
>>>>> Forms .NET applications within the Visual Studio IDE.
>>>>>
>>>>> Recipes are hosted here in 'recipes-mono'
>>>>>
>>>>> git@git.assembla.com:ciseco-eve.meta-eve.git
>>>
>>> I could not "git clone" the repo.
>>
>> Apologies. I should have given you the public r/o link.
>>
>> Originally I was trying to avoid modifying meta-mono, adding .bbappends
>> into my own meta-eve layer instead, but since my last post to you I
>> found I couldn't build against the current HEAD of Yocto due to some odd
>> file location issues which I couldn't overlay. (i.e. it didn't seem to
>> be able to pick up the patches where you had them - although was fine
>> with an older commit of the Yocto core).
>>
>> As a result I've moved the original meta-mono patches that weren't being
>> picked up by bitbake and merged my additions into a fork of meta-mono
>> which is here:
>>
>> git://git.assembla.com/ciseco-eve.meta-mono.git
> 
> Got it.
> 
> I scanned thru the code and saw what you did to re-organize the
> directory structure.
> 
> When I get back, I will see if I can build libGDI+ and mono with
> denzil (I am stuck with denzil for reasons beyond my control, or until
> I find a show stopping bug in denzil for our project - unlikely)
> 
> Meanwhile, I have no questions about changes for gk-sharp, mono,
> mono-xsp and monotools-server.
> 

Good oh.

> Presumably, you will take care of the "TODO: This needs fixing
> properly and needs to be revisited" in mono_<version>.bb - I
> definitely do not want unstripped binaries on my distribution -
> presumably, this was needed for some debugging and is not meant to be
> checked into production.

Ah yes. I'd forgotten about that. I shall habe to revisit why that was
erroring.

> I could not understand the purpose of
> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
> could you please help me understand what prompted these seemingly non
> trivial changes.
>

Yes there seems to be a problem building libGDI against libpng15. It
seems a known issue:

https://github.com/mono/libgdiplus/pull/4

> Everything else looks good.
> 

Good oh

>> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
>> Can I issue a "pull request" to you or some such?
> 
> Yes, a pull request should work.
> 
>>> Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.
>>>
>>> If the license is different for monotools-server or mono-xsp or
>>> gtk-sharp, you will likely have to submit a patch for README file too.
>>> Even otherwise, section 4 in README needs to be updated. If you have
>>> any tasks left - please add them to section 10.
>>>
>>
>> Will double check this. I am waiting for feedback from the
>> monotools-server people on their license as there's nothing explicit in
>> their source.
> 
> Will wait for that. Might affect the README
> 

I'll give them another nudge once I've worked our what's going on with
the stripping, commit to my fork and then try to work out how to send
you a pull req.

>>> The guidelines for the Yocto project are very similar to other FOSS
>>> projects including the Linux kernel. They are outlined here:
>>>
>>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>>
>>> I used the following as a guide when I have submitted my patches in
>>> the past. This is for the Linux kernel, adapt as appropriate for
>>> meta-mono.
>>>
>>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>>
>>> Please submit separate patches for each of the recipes (presumably
>>> there are no changes to the mono/libGDI+ recipes)
>>>
>>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>>> traffic) - this should allow the emails to be caught by the filter
>>> instead of archiving.
>>>
>>> In case I do not respond within 72 hours, please email me with a
>>> gentle reminder :-)
>>>
>>> I have not had the opportunity to integrate patches just yet, please
>>> bear with me in case I screw up.
>>>
>>> Thanks again for contributing!
>>>
>>> PS #1: If you do not want to go thru the hassle - please email me the
>>> tar.gz as an attachment and I will check it in directly - a bad side
>>> effect of this would be that you will not get any "git" credit for
>>> this
>>>
>>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
>>> will start only after Monday :-)
>>>
>>> And finally, PS #3:
>>>
>>> http://marc.info/?l=linux-usb&m=135229956521385&w=2
>>> http://marc.info/?l=linux-usb&m=135119051922403&w=2
>>> http://marc.info/?l=linux-usb&m=134858043613838&w=2
>>> http://marc.info/?l=linux-usb&m=134791970203982&w=2
>>> ... many others ...
>>>
>>> Please refrain from top posting :-)
>>
>> Happy to try if that's the etiquette here - like this?
>>
>>> Autif
>>>
>>>>> If there is interest in migrating these recipes into meta-mono
>>>>> and  somebody will review them then I'll be pleased to make
>>>>> whatever changes are needed to comply with relevant
>>>>> Yocto policies.
>>>>
>>>> Absolutely!
>>>>
>>>> I am about to embark on a vacation returning to work on Jan 7.
>>>>
>>>> More then - Unfortunately, I will not have time to look at this today
>>>> or until Jan 7.
>>>>
>>>> Working hard - then playing hard :-)
>>>>
>>>> I will dig into then when I return.
>>>>
>>>> (Side note - we gave up on GTK# recipe and decided that Windows forms
>>>> are 'good enough' for us. This makes me glad :-)
>>>>
>>>>>
>>>>> Best Regards, (& Happy Holidays)
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Autif Khan]

On Thu, Jan 3, 2013 at 10:45 AM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk> wrote:
> On 03/01/2013 15:24, Autif Khan wrote:
>> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
>> <ajlennon@dynamicdevices.co.uk> wrote:
>>> On 02/01/2013 20:27, Autif Khan wrote:
>>>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist@gmail.com> wrote:
>>>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>>>>> <ajlennon@dynamicdevices.co.uk> wrote:
>>>>>> Hi all, Autif,
>>>>>>
>>>>>> I've been working to support .NET development on Linux
>>>>>> over the past few days.
>>>>>>
>>>>>> There is a Visual Studio plugin, MonoTools for Visual Studio
>>>>>> which provides support for local and remote debugging of
>>>>>> .NET applications with Mono.
>>>>>>
>>>>>> This requires a remote stub to be running on the target
>>>>>> platform, monotools-server.
>>>>>>
>>>>>> I've created a recipe to build monotools-server, which in
>>>>>> turn required me to pull in Openembedded Legacy recipes
>>>>>> for mono-xsp and gtk-sharp.
>>>>>>
>>>>>> As it stands I'm now able to build an X enabled image for
>>>>>> the Raspberry Pi and remote-debug some simple Windows
>>>>>> Forms .NET applications within the Visual Studio IDE.
>>>>>>
>>>>>> Recipes are hosted here in 'recipes-mono'
>>>>>>
>>>>>> git@git.assembla.com:ciseco-eve.meta-eve.git
>>>>
>>>> I could not "git clone" the repo.
>>>
>>> Apologies. I should have given you the public r/o link.
>>>
>>> Originally I was trying to avoid modifying meta-mono, adding .bbappends
>>> into my own meta-eve layer instead, but since my last post to you I
>>> found I couldn't build against the current HEAD of Yocto due to some odd
>>> file location issues which I couldn't overlay. (i.e. it didn't seem to
>>> be able to pick up the patches where you had them - although was fine
>>> with an older commit of the Yocto core).
>>>
>>> As a result I've moved the original meta-mono patches that weren't being
>>> picked up by bitbake and merged my additions into a fork of meta-mono
>>> which is here:
>>>
>>> git://git.assembla.com/ciseco-eve.meta-mono.git
>>
>> Got it.
>>
>> I scanned thru the code and saw what you did to re-organize the
>> directory structure.
>>
>> When I get back, I will see if I can build libGDI+ and mono with
>> denzil (I am stuck with denzil for reasons beyond my control, or until
>> I find a show stopping bug in denzil for our project - unlikely)
>>
>> Meanwhile, I have no questions about changes for gk-sharp, mono,
>> mono-xsp and monotools-server.
>>
>
> Good oh.
>
>> Presumably, you will take care of the "TODO: This needs fixing
>> properly and needs to be revisited" in mono_<version>.bb - I
>> definitely do not want unstripped binaries on my distribution -
>> presumably, this was needed for some debugging and is not meant to be
>> checked into production.
>
> Ah yes. I'd forgotten about that. I shall habe to revisit why that was
> erroring.
>
>> I could not understand the purpose of
>> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
>> could you please help me understand what prompted these seemingly non
>> trivial changes.
>>
>
> Yes there seems to be a problem building libGDI against libpng15. It
> seems a known issue:
>
> https://github.com/mono/libgdiplus/pull/4
>
>> Everything else looks good.
>>
>
> Good oh
>
>>> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
>>> Can I issue a "pull request" to you or some such?
>>
>> Yes, a pull request should work.
>>
>>>> Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.
>>>>
>>>> If the license is different for monotools-server or mono-xsp or
>>>> gtk-sharp, you will likely have to submit a patch for README file too.
>>>> Even otherwise, section 4 in README needs to be updated. If you have
>>>> any tasks left - please add them to section 10.
>>>>
>>>
>>> Will double check this. I am waiting for feedback from the
>>> monotools-server people on their license as there's nothing explicit in
>>> their source.
>>
>> Will wait for that. Might affect the README
>>
>
> I'll give them another nudge once I've worked our what's going on with
> the stripping, commit to my fork and then try to work out how to send
> you a pull req.
>
>>>> The guidelines for the Yocto project are very similar to other FOSS
>>>> projects including the Linux kernel. They are outlined here:
>>>>
>>>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>>>
>>>> I used the following as a guide when I have submitted my patches in
>>>> the past. This is for the Linux kernel, adapt as appropriate for
>>>> meta-mono.
>>>>
>>>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>>>
>>>> Please submit separate patches for each of the recipes (presumably
>>>> there are no changes to the mono/libGDI+ recipes)
>>>>
>>>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>>>> traffic) - this should allow the emails to be caught by the filter
>>>> instead of archiving.
>>>>
>>>> In case I do not respond within 72 hours, please email me with a
>>>> gentle reminder :-)
>>>>
>>>> I have not had the opportunity to integrate patches just yet, please
>>>> bear with me in case I screw up.
>>>>
>>>> Thanks again for contributing!
>>>>
>>>> PS #1: If you do not want to go thru the hassle - please email me the
>>>> tar.gz as an attachment and I will check it in directly - a bad side
>>>> effect of this would be that you will not get any "git" credit for
>>>> this
>>>>
>>>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
>>>> will start only after Monday :-)
>>>>
>>>> And finally, PS #3:
>>>>
>>>> http://marc.info/?l=linux-usb&m=135229956521385&w=2
>>>> http://marc.info/?l=linux-usb&m=135119051922403&w=2
>>>> http://marc.info/?l=linux-usb&m=134858043613838&w=2
>>>> http://marc.info/?l=linux-usb&m=134791970203982&w=2
>>>> ... many others ...
>>>>
>>>> Please refrain from top posting :-)
>>>
>>> Happy to try if that's the etiquette here - like this?
>>>
>>>> Autif
>>>>
>>>>>> If there is interest in migrating these recipes into meta-mono
>>>>>> and  somebody will review them then I'll be pleased to make
>>>>>> whatever changes are needed to comply with relevant
>>>>>> Yocto policies.
>>>>>
>>>>> Absolutely!
>>>>>
>>>>> I am about to embark on a vacation returning to work on Jan 7.
>>>>>
>>>>> More then - Unfortunately, I will not have time to look at this today
>>>>> or until Jan 7.
>>>>>
>>>>> Working hard - then playing hard :-)
>>>>>
>>>>> I will dig into then when I return.
>>>>>
>>>>> (Side note - we gave up on GTK# recipe and decided that Windows forms
>>>>> are 'good enough' for us. This makes me glad :-)
>>>>>
>>>>>>
>>>>>> Best Regards, (& Happy Holidays)
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>
>

Merged into master.

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Bruce]

Alex J Lennon <ajlennon@...> writes:

> 
> Hi all, Autif,
> 
> I've been working to support .NET development on Linux
> over the past few days.
> 
> There is a Visual Studio plugin, MonoTools for Visual Studio
> which provides support for local and remote debugging of
> .NET applications with Mono.
> 
> This requires a remote stub to be running on the target
> platform, monotools-server.
> 
> I've created a recipe to build monotools-server, which in
> turn required me to pull in Openembedded Legacy recipes
> for mono-xsp and gtk-sharp.
> 
> As it stands I'm now able to build an X enabled image for
> the Raspberry Pi and remote-debug some simple Windows
> Forms .NET applications within the Visual Studio IDE.
> 
> Recipes are hosted here in 'recipes-mono'
> 
> git@...:ciseco-eve.meta-eve.git
> 
> If there is interest in migrating these recipes into meta-mono
> and  somebody will review them then I'll be pleased to make
> whatever changes are needed to comply with relevant
> Yocto policies.
> 
> Best Regards, (& Happy Holidays)
> 
> Alex
> 
> 
Hello,

I stumbled on to this site and would like to know if you can tell me how to get 
monotools-server installed and how to run it on Raspberry Pi?

I tried following the instructions at this site:
http://mono-project.com/GettingStartedWithMonoVS

and got the Visual Studio side to work but can't figure out how to get 
monotools-server to run on Pi.  Specifically this part tripped me up:

    Download Servers for Linux and Mac to Run/Debug Remotely

    Linux:

    Use the openSUSE 1click from your existing Linux system:
              http://mono-project.com/files/2/2b/Monovs-1click.png

    Note: After installing on Linux, launch the "MonoTool GUI Server" from the 
application menu to start the server.

I tried clicking on the above link in Medora and it just hangs.  Is your version 
of Monotools-server available somewhere?  I would greatly appreciate any help 
you can offer.  Thanks,

Bruce

Re: [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

On 24/01/2013 19:15, Bruce wrote:
> Alex J Lennon <ajlennon@...> writes:
>
>> Hi all, Autif,
>>
>> I've been working to support .NET development on Linux
>> over the past few days.
>>
>> There is a Visual Studio plugin, MonoTools for Visual Studio
>> which provides support for local and remote debugging of
>> .NET applications with Mono.
>>
>> This requires a remote stub to be running on the target
>> platform, monotools-server.
>>
>> I've created a recipe to build monotools-server, which in
>> turn required me to pull in Openembedded Legacy recipes
>> for mono-xsp and gtk-sharp.
>>
>> As it stands I'm now able to build an X enabled image for
>> the Raspberry Pi and remote-debug some simple Windows
>> Forms .NET applications within the Visual Studio IDE.
>>
>> Recipes are hosted here in 'recipes-mono'
>>
>> git@...:ciseco-eve.meta-eve.git
>>
>> If there is interest in migrating these recipes into meta-mono
>> and  somebody will review them then I'll be pleased to make
>> whatever changes are needed to comply with relevant
>> Yocto policies.
>>
>> Best Regards, (& Happy Holidays)
>>
>> Alex
>>
>>
> Hello,
>
> I stumbled on to this site and would like to know if you can tell me how to get
> monotools-server installed and how to run it on Raspberry Pi?
>
> I tried following the instructions at this site:
> http://mono-project.com/GettingStartedWithMonoVS
>
> and got the Visual Studio side to work but can't figure out how to get
> monotools-server to run on Pi.  Specifically this part tripped me up:
>
>      Download Servers for Linux and Mac to Run/Debug Remotely
>
>      Linux:
>
>      Use the openSUSE 1click from your existing Linux system:
>                http://mono-project.com/files/2/2b/Monovs-1click.png
>
>      Note: After installing on Linux, launch the "MonoTool GUI Server" from the
> application menu to start the server.
>
> I tried clicking on the above link in Medora and it just hangs.  Is your version
> of Monotools-server available somewhere?  I would greatly appreciate any help
> you can offer.  Thanks,
>
> Bruce
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Hi Bruce,

You might try the instructions I left here. These images should have the 
monotools server in.
I did see a problem building GTK# the other day though which I still 
might need to look into:

https://www.assembla.com/spaces/ciseco-eve/wiki/Getting_Started

If you do look at this I'd be grateful if you feed back to me on how it 
goes for you.

NB. Another point is that the activation code request on the MonoTools 
site appears not to work.
        If you contact Xamarin directly they seem happy to give you a 
code though.

Cheers,

Alex