When I build the monodroid assemblies with the configure option
--with-monodroid=yes, the profile is built correctly in the master branch,
but when you make install, the monodroid profile assemblies are not copied
to the install prefix directory with the other profiles. Is this expected
behavior?
Yes, it's not copied because those assemblies are not very useful on the
desktop.
On Wed, May 29, 2013 at 11:40 AM, Jeremy Bell wrote:
> When I build the monodroid assemblies with the configure option
> --with-monodroid=yes, the profile is built correctly in the master branch,
> but when you ma
I'm not sure if this is the best way to fix the issue, but I've submitted a
pull request with a small fix:
https://github.com/mono/mono/pull/650
This is my first mono pull request, so please let me know if there are any
contrib guidelines I missed.
Regards,
Jeremy
On Thu, May 23, 2013 at 2:25 P
So we have reproduced bugs even with suggestions given (and documented)
How do we move forward from this point? We have shown in the past that we
don't mind bounties but we are at a point of giving up and saying mono is
not acceptable as a server platform. The issues we have will affect anyone
who
Hmm, is there a separate install target that does install them? It's easy
enough to copy the directory in a build script after make install, but
that's a little brittle. Better that the build system handle that, I think.
On Wed, May 29, 2013 at 11:58 AM, Rodrigo Kumpera wrote:
> Yes, it's not c
There are no install target as those assemblies are not consumed in a
standard way, it's very useful to have them on either the GAC or a profile
directory.
What we do at Xamarin is to have them consumed as part of our product
build, mostly due to historical reasons.
If you're using Xamarin.Androi
Thanks Rodrigo. Copying sounds like the way to go.
As an aside, this is for an open source project and the intent is to use
the core mono runtime under the terms of the LGPL as stated in the
licensing documentation. If there is any code in the mono repository that
isn't dual licensed (in other wo
Hi Greg,
Please can you point me back to your bug reports and proposed fix(es),
I'll take a look to see if we can find a way to change it to avoid the
theoretical deadlock and submit a new patch, as this is also important
for my cloud projects.
As I need to have tcp servers running on Android dev
'I love this project, and want to see it succeed in more than just mobile.'
Very well said!
Rafael Teixeira
O..:.)
On Wed, May 29, 2013 at 1:52 PM, Jeremiah Gowdy
wrote:
> Has Xamarin considered offering professional support plans for the other
> major consumer of Mono, those of us who want
'I love this project, and want to see it succeed in more than just mobile.'
I share these sentiments! :)
At first glance, this seems like a big opportunity. There is likely to be a
lot of ASP.NET/WebAPI/socket based enterprise server software currently
running on IIS via MS-CLR where the company
> Has Xamarin considered offering professional support plans for the other
> major consumer of Mono, those of us who want to use C# to develop our
> service applications but would prefer to host them on Linux for obvious
> reasons?
>
Xamarin decided early to focus on our products, and not in prof
The runtime is a mixture of LGPL and MIT and the BCL is mixture of MIT/X11
and compatible licenses such as the Microsoft variant of MIT.
As the Debian guys found out there are some non-free files used to generate
some files, but the byproduct is fine. This is for the AMQP driver, I
believe. They a
Rafael,
If you search tcp in the archives here it should bring up everything
including discussions various patches etc there are about 4-5 threads
Greg
On Thursday, May 30, 2013, Rafael Teixeira wrote:
> Hi Greg,
>
> Please can you point me back to your bug reports and proposed fix(es),
> I'll
Hi,
This should be fixed now by 655afb183bd8abac0b60307645c9b43ff37b3082.
Could you try it out ?
Zoltan
On Wed, May 29, 2013 at 6:00 PM, Jeremy Bell wrote:
> I'm not sure if this is the best way to fix the issue, but I've submitted
> a pull request with a small fix:
> https://git
14 matches
Mail list logo
