Re: [Mono-dev] RSA and ECDH
> From: Sebastien Pouliot [mailto:sebastien.poul...@gmail.com] > > Please re-read the TLS RFC (any of them) and tell me where you need to > _generate_ an RSA keypair to establish an SSL/TLS connection ?!? It seems I had a misunderstanding - I know, as long as the server only needs to generate a new cert once a year, that the 30-ish seconds necessary to generate the new server cert is irrelevant (especially because it's done non-interactively offline.) I know the server is able to re-use its cert on many different connections. And I know that clients *can* have their own reusable certs, but usually don't. I *thought* that clients that don't have their own certs would need to generate a keypair each time they connected to a server, in order to then negotiate the session-specific symmetric key. But this seems to be false, as in testing a moment ago, I have a server with 3072 bit RSA private key in its self-signed cert, and the client only requires 1-2-ish seconds to create the SslStream and AuthenticateAsClient(). I'll have to look into it more, but for now I'm sleepy, and content to put it off to another day. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
No, this is not the same as launching exe files directly from the OS using binfmt-misc. If you launch an exe file *from Mono's implementation of Process.Start*, Mono will detect managed executables and run them with Mono automatically. https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L808 On 16 February 2014 09:00, Michael Franz wrote: > > On Sun, Feb 16, 2014 at 7:34 AM, "Andrés G. Aragoneses" > wrote: >> >> On 16/02/14 10:15, Michael Hutchinson wrote: >> > ... which automatically executes exe >> > files using Mono. >> >> Are you sure that statement applies to all distros? I read somewhere >> some time ago that the only distro so far that implemented the ability >> to run .exe files automatically by calling mono under the hood was >> Debian (and derivatives), by installing some system hook by default when >> mono packages are installed. >> >> Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work >> for him because he's using a custom mono install (instead of debian >> packages)? > > I am using CentOS 6.5 with a locally built Mono installation. > > I have read about how you can modify the kernel to understand launching Mono > applications - http://www.mono-project.com/Guide:Running_Mono_Applications - > this was probably after I ran into this problem. If this has become a > requirement to use Mono for development it should probably be documented > somewhere. > > >> >> >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
Hello guys, There's quite a few misconceptions in the above thread. There's a lot of places that could be/do better but misidentifying them is not helpful (and they are fairly googl'able assertions to be validated). On Sun, Feb 16, 2014 at 3:03 PM, Edward Ned Harvey (mono) < edward.harvey.m...@clevertrove.com> wrote: > > From: Ian Norton [mailto:inor...@gmail.com] > > > > Hi folks. > > Key generation can be hugely different on different platforms. > Essentially for > > RSA you need to generate two huge random integers and do primality checks > > on them. > > This is always going to be fairly nondeterministic in terms of time. > True words. As for Mono this is entirely done in managed code. It means it's always available anywhere you can run mono (without any additional dependencies), i.e. you got mono, you got crypto and SSL/TLS. It also means it's not optimized like it's generally is for most platforms (and yes, even in 2014, most platforms still use hand-written assembly code for this). OTOH Mono/.NET (and it's cryptographic stack) is easily extended so you're free to add/replace cryptographic code with native code (e.g. Xamarin.iOS does this using Apple's CommonCrypto and there are other examples in Mono's crimson git repository). > > What really matters for performance of TLS is the speed at which you can > do > > a decrypt using RSA. Good (but incomplete). Both encrypt and decrypt speeds are important - depending on which side of the SSL channel (i.e. client or server, both supported by Mono) you are. The use of client certificates also affect which operation is critical. > The best way to measure this is to generate one key. > > Start the stopwatch and do lots of signatures of about 20-60 bytes of > data. > Again true - but let me emphasis that the "generate one key" is _not_ important above. The important (true) part is that you start the watch dog after the key generation. > > I think you meant to respond to the list and not just me, so I included > your whole text above. And my response: > > This is true - by nature of the fact that you have to start with a random > number, and from there, perform a search for a prime. If you're lucky, you > could get a prime on the first random pick, and if you're unlucky, you > could be required to search for a long time before you find a prime. > Yup! > > But when the time required is *usually* 20-40 seconds, as opposed to > usually 1-2 sec... Proving a prime is not easy (nor fast) and it's easy to take shortcuts. We try to say away from them and ensure any key we generate is safe to use, now and in the future. OTOH all our BigInteger code is available. You can optimize it or the way you wish your prime numbers to be tested - they'll be yours after all ;-) > And this is a blocking operation, Wrong! > and it's necessary to establish an https connection (or anything else > using SSL/TLS) ... Please re-read the TLS RFC (any of them) and tell me where you need to _generate_ an RSA keypair to establish an SSL/TLS connection ?!? Now that does not make mono faster at generating key pairs - but it makes it unimportant for 99% of use cases I can dream of (including SSL/TLS). > That is well outside of the normal user tolerance. > A good thing it does not matter :-) > > Normally, all we need to do is generate a keypair, and then encrypt > something on par with 32-128 bytes, to perform an AES key exchange, and > then never care about the RSA key again. No, this is not how SSL/TLS works. Do you normally trash for physical keys after each use ? I don't. As for virtual keys I bet certificate sellers would be thrilled if this was the case ;-) Thankfully it's not something required for SSL/TLS. > So I humbly disagree that the speed of encryption / decryption is what > matters. and I disagree with your disagreement. You might state that mono key generation is slow and I'll agree (your data shows this); You might state that mono's SSL/TLS is slow and I'll agree (no data given but it's never been a secret, the implementation sits on a wholly managed code base); But if you state that SSL/TLS is slow because of the key generation then you'll not get my agreement (your assertion is wrong); > What matters is the total time to perform session key exchange (AES or > whatever algorithm was negotiated), which includes the time to generate the > RSA key. > Right (total) and wrong (key generation). Sebastien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NUnit shadow copy and multiple users issue
On Sun, Feb 16, 2014 at 12:34 AM, Michael Franz wrote: > Hi, > > I have been setting up my development environment on CentOS 6.5 and have > had some great success. My latest issue is temp directories and shadow > copies while running nunit. The issue is documented here and fixed in > NUnit 3.0 https://bugs.launchpad.net/nunit-3.0/+bug/719187 . Is there > any plan to upgrade the Mono version of NUnit? > > I might be wrong, but I have only been able to get the version of NUnit > that is embedded in Mono to work for me. Is there a way that I can upgrade > my local copy and have it still work? > > Or, is the best way to resolve this issue is to create a patch for the > shadow copy logic for the Mono version of NUnit? > > Michael > After looking into a fix for this, it seems that the easiest fix is to change the nunit-console-exe.config files (I found 4) and one App.config. I am not sure which ones actually need to be changed as I don't fully understand the build and install process. It actually took a lot of searching to find all of them. # modified: mcs/nunit24/ConsoleRunner/nunit-console-exe/App.config # modified: mcs/nunit24/ConsoleRunner/nunit-console-exe/nunit-console.exe.config # modified: mcs/nunit24/ConsoleRunner/nunit-console-exe/nunit-console.exe.config.net_2_0 # modified: mcs/nunit24/ConsoleRunner/nunit-console-exe/nunit-console.exe.config.net_3_5 # modified: mcs/tools/linker/Tests/Libs/nunit-console.exe.config The patch for all is the same, it creates a user specific temp directory for running unit tests. This works for my setup, as I run multiple users on the same machine. I am sure there are better ways to resolve this issue, this just seem like the easiest. - + What is the best way to proceed? I also looked to raise a bug for this in the Mono bug database, but not sure what component the NUnit code is under. Thoughts? Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
> From: Ian Norton [mailto:inor...@gmail.com] > > Hi folks. > Key generation can be hugely different on different platforms. Essentially for > RSA you need to generate two huge random integers and do primality checks > on them. > This is always going to be fairly nondeterministic in terms of time. > What really matters for performance of TLS is the speed at which you can do > a decrypt using RSA. The best way to measure this is to generate one key. > Start the stopwatch and do lots of signatures of about 20-60 bytes of data. I think you meant to respond to the list and not just me, so I included your whole text above. And my response: This is true - by nature of the fact that you have to start with a random number, and from there, perform a search for a prime. If you're lucky, you could get a prime on the first random pick, and if you're unlucky, you could be required to search for a long time before you find a prime. But when the time required is *usually* 20-40 seconds, as opposed to usually 1-2 sec... And this is a blocking operation, and it's necessary to establish an https connection (or anything else using SSL/TLS) ... That is well outside of the normal user tolerance. Normally, all we need to do is generate a keypair, and then encrypt something on par with 32-128 bytes, to perform an AES key exchange, and then never care about the RSA key again. So I humbly disagree that the speed of encryption / decryption is what matters. What matters is the total time to perform session key exchange (AES or whatever algorithm was negotiated), which includes the time to generate the RSA key. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
On 02/16/2014 11:33 AM, Edward Ned Harvey (mono) wrote: > Ideally, yeah, but realistically, behavior will deviate. (See my other > question, about the non-existence of ECDiffieHellman. Existence vs > Non-existence is a pretty big deviation.) ;-) The important thing is that > the API remain functionally equivalent. But they aren't functionally equivalent, the ctors do not function equivalently. It is only syntactically equivalent. This is, arguably, a bug. > Not long ago, I discovered that PKCS12.GetBytes() in MS behaves fine with a > blank password, while mono fails on blank password. And the hash algorithm > is basically restricted to SHA1, as deviation from SHA1 causes mono to fail a > lot. Which is fine, but the point is, deviations do exist. Some more > dramatic than others. Yep, agreed. I have found deviations as well. Doesn't mean they should exist. Especially if the reason is to make unit tests perform faster, as the below comment suggests was a main reason. You are no longer testing the same functionality as you would be if that unit test were running on .NET. > > This particular difference, generating key in constructor versus only when > necessary, as far as I'm concerned, is not a bug, and not an issue. Because > the API remains the same. On the other hand, the non-existent > ECDiffieHellman is a significant missing feature, and the non-acceptance of > blank password is a legitimate bug that nobody cares about. ;-)(Not > even me) > > In RSACryptoServiceProvider.cs constructor, there is this comment: > > // Here it's not clear if we need to generate a keypair > // (note: MS implementation generates a keypair in this case). > // However we: > // (a) often use this constructor to import an existing keypair. > // (b) take a LOT of time to generate the RSA keypair > // So we'll generate the keypair only when (and if) it's being > // used (or exported). This should save us a lot of time (at > // least in the unit tests). > According to this, behaviour deviation is not desired. http://www.mono-project.com/FAQ:_Technical#Compatibility However, this is a large deviation from your original question of speed (pun intended). It may be related though. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
> From: Brandon Perry [mailto:bperry.volat...@gmail.com] > Sent: Sunday, February 16, 2014 11:55 AM > > If this is the case, that sounds like a bug. Behaviour shouldn't deviate > across implementations like that AFAIK. Ideally, yeah, but realistically, behavior will deviate. (See my other question, about the non-existence of ECDiffieHellman. Existence vs Non-existence is a pretty big deviation.) ;-) The important thing is that the API remain functionally equivalent. Not long ago, I discovered that PKCS12.GetBytes() in MS behaves fine with a blank password, while mono fails on blank password. And the hash algorithm is basically restricted to SHA1, as deviation from SHA1 causes mono to fail a lot. Which is fine, but the point is, deviations do exist. Some more dramatic than others. This particular difference, generating key in constructor versus only when necessary, as far as I'm concerned, is not a bug, and not an issue. Because the API remains the same. On the other hand, the non-existent ECDiffieHellman is a significant missing feature, and the non-acceptance of blank password is a legitimate bug that nobody cares about. ;-)(Not even me) In RSACryptoServiceProvider.cs constructor, there is this comment: // Here it's not clear if we need to generate a keypair // (note: MS implementation generates a keypair in this case). // However we: // (a) often use this constructor to import an existing keypair. // (b) take a LOT of time to generate the RSA keypair // So we'll generate the keypair only when (and if) it's being // used (or exported). This should save us a lot of time (at // least in the unit tests). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
On 02/16/2014 10:45 AM, Edward Ned Harvey (mono) wrote: > Yeah, I thought of that - when I first did this a few months ago, I did as > you suggested, but then, I think, the mono implementation differs from the > .NET implementation - where I think .NET generates key in constructor, but > since key generation is so expensive, mono delays key generation until > something needs it, just *hoping* the RSA object will be disposed unused > (which is probably very rare, I'm guessing). Which is the reason that I do > the export of the key. It's the cheapest way I can see to force creation of > the key. If this is the case, that sounds like a bug. Behaviour shouldn't deviate across implementations like that AFAIK. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
> From: Brandon Perry [mailto:bperry.volat...@gmail.com] > > I wonder, you are instantiating the RSACryptoServiceProvider object > after storing the before ticks, how much of the time is simply > instantiating the object? Maybe move that ahead of before ticks if you > want to measure just the key generation. Yeah, I thought of that - when I first did this a few months ago, I did as you suggested, but then, I think, the mono implementation differs from the .NET implementation - where I think .NET generates key in constructor, but since key generation is so expensive, mono delays key generation until something needs it, just *hoping* the RSA object will be disposed unused (which is probably very rare, I'm guessing). Which is the reason that I do the export of the key. It's the cheapest way I can see to force creation of the key. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
I wonder, you are instantiating the RSACryptoServiceProvider object
after storing the before ticks, how much of the time is simply
instantiating the object? Maybe move that ahead of before ticks if you
want to measure just the key generation.
Just off-the-cuff thought.
On 02/16/2014 09:51 AM, Edward Ned Harvey (mono) wrote:
> Here are my RSA benchmark results:
>
> Conclusion is that RSA key generation is expensive no matter what, but it's
> 20x-40x worse on mono.
>
> .NET 4.0, Win 8.1 VM inside a Mac, Debug build, 3 trials average:
> 1024 27 ms
> 2048 80 ms
> 3072 673 ms
>
> .NET 4.0, Win 8.1 VM inside a Mac, Release build, 3 trials average:
> 1024 14 ms
> 2048 94 ms
> 3072 1,273 ms
>
> Mono 3.2.5 on Mac OSX, compiled by VS Debug, 3 trials average:
> 1024 505 ms
> 2048 4,718 ms
> 3072 42,972 ms
>
> Mono 3.2.5 on Mac OSX, compiled by VS Release, 3 trials average:
> 1024 883 ms
> 2048 8,310 ms
> 3072 40,284 ms
>
> Mono 3.2.5 on Mac OSX, compiled by xbuild Debug, 3 trials average:
> 1024 894 ms
> 2048 5,756 ms
> 3072 35,273 ms
>
> Mono 3.2.5 on Mac OSX, compiled by xbuild Release, 3 trials average:
> 1024 1,215 ms
> 2048 12,966 ms
> 3072 18,952 ms
>
> Code to generate these results:
>
> using System;
> using System.Collections.Generic;
> using System.Security.Cryptography;
>
> namespace FunWithRSAKeys
> {
> class Program
> {
> static void Main(string[] args)
> {
> const int numRuns = 3;
> long beforeTicks;
> long afterTicks;
> RSACryptoServiceProvider RSACSP;
> int[] keySizes = { 1024, 2048, 3072 };
> Dictionary results = new Dictionary double[]>();
> foreach (int keySize in keySizes)
> results[keySize] = new double[numRuns];
>
> for (int i = 0; i < numRuns; i++)
> {
> System.Console.WriteLine("-");
> foreach (int keySize in keySizes)
> {
> beforeTicks = DateTime.UtcNow.Ticks;
> RSACSP = new RSACryptoServiceProvider(keySize);
> RSACSP.ExportParameters(false); // Minimum effort to
> guarantee key will actually be generated
> afterTicks = DateTime.UtcNow.Ticks;
> double seconds = (double)(afterTicks - beforeTicks) /
> (double)TimeSpan.TicksPerSecond;
> results[keySize][i] = seconds;
> System.Console.WriteLine(keySize.ToString() + " " +
> seconds.ToString());
> }
> }
> System.Console.WriteLine("- Results");
> foreach(int keySize in keySizes)
> {
> System.Console.WriteLine(keySize.ToString() + " " +
> avg(results[keySize]).ToString());
> }
> System.Console.WriteLine("-");
> System.Threading.Thread.Sleep(int.MaxValue);
> }
> static double avg(double[] values)
> {
> double result = 0;
> foreach (double value in values)
> result += value / values.Length;
> return result;
> }
> }
> }
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RSA and ECDH
Here are my RSA benchmark results:
Conclusion is that RSA key generation is expensive no matter what, but it's
20x-40x worse on mono.
.NET 4.0, Win 8.1 VM inside a Mac, Debug build, 3 trials average:
102427 ms
204880 ms
3072673 ms
.NET 4.0, Win 8.1 VM inside a Mac, Release build, 3 trials average:
102414 ms
204894 ms
30721,273 ms
Mono 3.2.5 on Mac OSX, compiled by VS Debug, 3 trials average:
1024505 ms
20484,718 ms
307242,972 ms
Mono 3.2.5 on Mac OSX, compiled by VS Release, 3 trials average:
1024883 ms
20488,310 ms
307240,284 ms
Mono 3.2.5 on Mac OSX, compiled by xbuild Debug, 3 trials average:
1024894 ms
20485,756 ms
307235,273 ms
Mono 3.2.5 on Mac OSX, compiled by xbuild Release, 3 trials average:
10241,215 ms
204812,966 ms
307218,952 ms
Code to generate these results:
using System;
using System.Collections.Generic;
using System.Security.Cryptography;
namespace FunWithRSAKeys
{
class Program
{
static void Main(string[] args)
{
const int numRuns = 3;
long beforeTicks;
long afterTicks;
RSACryptoServiceProvider RSACSP;
int[] keySizes = { 1024, 2048, 3072 };
Dictionary results = new Dictionary();
foreach (int keySize in keySizes)
results[keySize] = new double[numRuns];
for (int i = 0; i < numRuns; i++)
{
System.Console.WriteLine("-");
foreach (int keySize in keySizes)
{
beforeTicks = DateTime.UtcNow.Ticks;
RSACSP = new RSACryptoServiceProvider(keySize);
RSACSP.ExportParameters(false); // Minimum effort to
guarantee key will actually be generated
afterTicks = DateTime.UtcNow.Ticks;
double seconds = (double)(afterTicks - beforeTicks) /
(double)TimeSpan.TicksPerSecond;
results[keySize][i] = seconds;
System.Console.WriteLine(keySize.ToString() + " " +
seconds.ToString());
}
}
System.Console.WriteLine("- Results");
foreach(int keySize in keySizes)
{
System.Console.WriteLine(keySize.ToString() + " " +
avg(results[keySize]).ToString());
}
System.Console.WriteLine("-");
System.Threading.Thread.Sleep(int.MaxValue);
}
static double avg(double[] values)
{
double result = 0;
foreach (double value in values)
result += value / values.Length;
return result;
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] RSA and ECDH
I benchmarked RSA key generation, .Net versus Mono, and also RSA vs ECDiffieHellman. A couple of things - For RSA keys, Mono was way slower. Like way crazy, super way slower. See results below, but something like 40x slower. Second, ECDiffieHellman is way faster than RSA, by approx 100x. But it seems, ECDiffieHellman is not available in mono. I haven't looked to explicitly confirm, but I believe SslStream must use RSA internally. This would make mono very undesirable for serving any kind of SSL communications channels. So my two questions are: Does anyone know why there is no ECDH in mono? Maybe just nobody found a compatible open source implementation to use? And does anyone know why RSA is so slow? Maybe it's just a slow implementation, and it also suffers because a better and compatible open source implementation hasn't been identified? I'll post more details in another email momentarily. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Getting started on mono sources
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- > boun...@lists.ximian.com] On Behalf Of Frankie Fisher > > Xamarin studio? That would be great. Do you know of any way to make mono build on Xamarin Studio? Even if it was just one assembly, that would be great - So far I have not succeeded in doing this with Xamarin Studio or Visual Studio. I saw there were .sln files created for VS 2005, but I don't have anything older than 2010, and it doesn't build. So far, the best I'm able to do is sprinkle System.Console.WriteLine (or Debug.WriteLine or whatever) into the mono source, and then build, link something against it, and run. If there aren't any great ways to get a GUI debugger running - What about a text based debugger? Anybody? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On Sun, Feb 16, 2014 at 7:34 AM, "Andrés G. Aragoneses" wrote: > On 16/02/14 10:15, Michael Hutchinson wrote: > > ... which automatically executes exe > > files using Mono. > > Are you sure that statement applies to all distros? I read somewhere > some time ago that the only distro so far that implemented the ability > to run .exe files automatically by calling mono under the hood was > Debian (and derivatives), by installing some system hook by default when > mono packages are installed. > > Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work > for him because he's using a custom mono install (instead of debian > packages)? > I am using CentOS 6.5 with a locally built Mono installation. I have read about how you can modify the kernel to understand launching Mono applications - http://www.mono-project.com/Guide:Running_Mono_Applications - this was probably after I ran into this problem. If this has become a requirement to use Mono for development it should probably be documented somewhere. > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On 16/02/14 10:15, Michael Hutchinson wrote: > ... which automatically executes exe > files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
Yes, but xbuild uses Process.Start, which automatically executes exe files using Mono. Not sure why that's failing on your machine. On 15 February 2014 22:13, Michael Franz wrote: > On Sat, Feb 15, 2014 at 10:02 PM, Michael Hutchinson > wrote: >> >> AFAIK something's wrong with the installation if >> $prefix/lib/mono/4.5/mcs.exe is missing. >> >> What does your $prefix/bin/mcs point to? >> > > It points to a binary that does not run on its own. > bash-4.1$ ./lib/mono/4.5/mcs.exe --version > bash: ./lib/mono/4.5/mcs.exe: cannot execute binary file > > but, if I run it with mono it will work. > bash-4.1$ bin/mono ./lib/mono/4.5/mcs.exe --version > Mono C# compiler version 3.2.7.0 > > Prior to the change, it was the mcs wrapper that was being executed, after > the change, it is trying to run the .NET binary directly. The contents of > mcs is: > #!/bin/sh > exec /opt/local/JenkinsBuilds/bin/mono $MONO_OPTIONS > /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe "$@" > > > >> On 15 February 2014 10:51, Michael Franz wrote: >> > On Sat, Feb 15, 2014 at 9:46 AM, Michael Franz >> > wrote: >> >> >> >> Hi, >> >> >> >> I see there have been a few changes to xbuild since February 10th, >> >> 2014. >> >> February 10th is the last time I was able to build my local C# project >> >> using >> >> mono head. This is a simple project that I have just started and am >> >> planing >> >> to build on both mono and .NET. The issue seems to be that xbuild has >> >> changed how it finds mcs. /opt/local/JenkinsBuilds/bin/mcs -> >> >> /opt/local/JenkinsBuilds/lib/mono/4.5/mcs.exe - see below. >> >> >> >> My locally build mono install is in /opt/local/JenkinsBuilds and my >> >> builds >> >> are all run via Jenkins. >> >> >> >> The build process is: >> >> - use premake5 to generate Visual Studio 2012 project files (note I am >> >> using .net 4.5 specific features) >> >> - use xbuild to build >> >> - use mono version of nunit to test >> >> >> >> The working build out put was like this: >> >> >> >> + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln >> >> XBuild Engine Version 12.0 >> >> Mono, Version 3.2.7.0 >> >> Copyright (C) 2005-2013 Various Mono authors >> >> >> >> Build started 2/10/2014 9:56:00 PM. >> >> __ >> >> Project "/var/lib/jenkins/jobs/CI/workspace/QTS.sln" (default >> >> target(s)): >> >> Target ValidateSolutionConfiguration: >> >> Building solution configuration "Debug|Any CPU". >> >> Target Build: >> >> Project >> >> "/var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj" (default >> >> target(s)): >> >> Target PrepareForBuild: >> >> Configuration: Debug Platform: AnyCPU >> >> Target GenerateSatelliteAssemblies: >> >> No input files were specified for target >> >> GenerateSatelliteAssemblies, >> >> skipping. >> >> Target GenerateTargetFrameworkMonikerAttribute: >> >> Skipping target >> >> "GenerateTargetFrameworkMonikerAttribute" because its >> >> outputs are up-to-date. >> >> Target CoreCompile: >> >> Tool /opt/local/JenkinsBuilds/bin/mcs >> >> execution started with >> >> arguments: /noconfig /debug:full /debug+ /optimize- >> >> /out:obj/Debug/QTS.dll >> >> Properties/AssemblyInfo.cs >> >> Utilities/Measurements/PerformanceStatistics.cs >> >> /target:library /define:"DEBUG;TRACE" /platform:AnyCPU >> >> /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.dll >> >> /reference:/opt/local/JenkinsBuilds/lib/mono/4.5/System.Core.dll >> >> /warn:4 >> >> >> >> >> >> The broken build is now producing: >> >> >> >> + /opt/local/JenkinsBuilds/bin/xbuild QTS.sln >> >> XBuild Engine Version 12.0 >> >> Mono, Version 3.2.7.0 >> >> Copyright (C) 2005-2013 Various Mono authors >> >> >> >> Build started 2/15/2014 8:50:52 AM. >> >> __ >> >> Project "/var/lib/jenkins/jobs/CI/workspace/QTS.sln" (default >> >> target(s)): >> >> Target ValidateSolutionConfiguration: >> >> Building solution configuration "Debug|Any CPU". >> >> Target Build: >> >> Project >> >> "/var/lib/jenkins/jobs/CI/workspace/QTS/QTS.csproj" (default >> >> target(s)): >> >> Target PrepareForBuild: >> >> Configuration: Debug Platform: AnyCPU >> >> Created directory "bin/Debug/" >> >> Created directory "obj/Debug/" >> >> Target CopyFilesMarkedCopyLocal: >> >> Copying file from >> >> '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll' >> >> to '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Debug/mscorlib.dll' >> >> Copying file from >> >> '/opt/local/JenkinsBuilds/lib/mono/4.5/mscorlib.dll.mdb' to >> >> '/var/lib/jenkins/jobs/CI/workspace/QTS/bin/Deb
Re: [Mono-dev] Getting started on mono sources
On 15/02/2014 23:46, Edward Ned Harvey (mono) wrote: >> From: Brandon Perry [mailto:bperry.volat...@gmail.com] >> Sent: Saturday, February 15, 2014 5:34 PM >> >> While I am not positive on this at all, it may be easier to just use >> make in a cygwin env. > So, whether mac, linux, unix, or windows, the easiest way to build is clearly > to use make. But for debugging purposes, and development of mono itself, > aren't people using IDE's of some kind? Debugging would seem very cumbersome > to me, without the IDE... Ability to step through code, examine runtime > variables, etc... > Xamarin studio? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
