So, after thinking about this further. The question I have is not really
about CoreCLR.
What I want to know is, the libraries that Microsoft are making available
via their nuget (myget at the moment), are these going to be tested again
.net, mono and CoreCLR? I.e will the libraries be cross
As I follow the github discussions in some of the asp.net vnext
subprojects, I see them testing on Mono (in MacOS X) as part of the
development process, but yet some things are lagging a bit... :)
On Wed Nov 05 2014 at 9:43:28 AM Martin Thwaites monofo...@my2cents.co.uk
wrote:
So, after
Well the issue with the NuGet-based BCL libraries like System.Console is that
the actual implementation still depends on Windows internals, e.g. a very quick
peak with a decompiler on the new System.Console NuGet library reveals dozens
of DllImport(api-ms-win-core-file-l1-1-0.dll) and
Right, this kind of assembly support is something that we should adopt at
some point, but it will require some major changes to do this.
Alex is right, for now this should be considered equivalent to the full
.net stack, not the split version of it.
Btw, it seems from the live webcasts that (a)
The OSX code I'm using will need to reference MonoPosixHelper. Poking about on
the 'net, I see that there should be something called libMonoPosixHelper.dylib,
and that Mono should map that onto MonoPosixHelper.dll for me.
However, I cannot find this libMonoPosixHelper.dylib anywhere. It was not
On Nov 5, 2014, at 10:52 AM, Jonathan Pryor jonpr...@vt.edu wrote:
Why do you need to reference libMonoPosixHelper.dylib? It has NO STABLE ABI;
it is intended for use only from Mono.Posix.dll.
It's not me, it's being called from Mono's WindowBase, specifically this line
of code...
[DllImport
On Nov 5, 2014, at 9:15 AM, Maury Markowitz maury.markow...@gmail.com wrote:
The OSX code I'm using will need to reference MonoPosixHelper.
Why do you need to reference libMonoPosixHelper.dylib? It has NO STABLE ABI; it
is intended for use only from Mono.Posix.dll.
However, I cannot find this
On Nov 5, 2014, at 11:19 AM, Maury Markowitz maury.markow...@gmail.com wrote:
unzOpen2 is part of miniunzip, itself part of zlib. The zlib code appears to
be in the MPH project essentially/completely unchanged. Of course I also have
libz in /usr/lib on every device I'm targeting.
On Nov 5, 2014, at 1:09 PM, Jonathan Pryor jonpr...@vt.edu wrote:
Jon, thank you so much for your help here, I was despairing of ever getting
this to work and now I feel I may have at least the possibility.
libMonoPosixHelper.dylib has a copy of minzip for use in
System.IO.Packaging/etc.