Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Greg Young]

Use conditional compilation.

On Tuesday, September 1, 2015, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> I've always used separate project files on windows and linux, in order to
> include different compiler symbols, in order to make projects build with
> different dependencies. I've been chastised here for doing it, so I'd like
> to find a better way. (Miguel and others tore apart a pull request, saying
> I should never check __MONO__, if I need behavior to be different on
> windows and non-windows, I need to use a runtime check. The problem is, as
> described below, the runtime check can't build or run on windows, so I'd
> like to figure out how it should be done).
>
> Right now, I have a class, which is using Mono.Unix.Native, because of a
> method that does this:
> if (Type.GetType("Mono.Runtime") != null) {
> Syscall.chmod(...);
> }
>
> When built and run on mono, works great. The problem is building and
> running on windows. In order to make it build, I copied Mono.Posix.dll into
> the project and referenced it, with CopyLocal = False. This way,
> Mono.Posix.dll doesn't get copied to the build directory, which is good
> because it's already present on mono systems, and not needed on windows
> systems - the only reason for it to exist in the project is because windows
> can't build without it.
>
> So it builds. But unfortunately, it won't run on windows. It throws
> FileNotFoundException "Mono.Posix.dll" before evaluating the if-clause.
>
> The workaround I've found is to create a wrapper class MonoSpecific, so
> the if-clause and the Mono.Posix call are not in the same file. But this is
> clearly a hack. Is there a better way?
>
> Hello.cs:
> using System;
> namespace helloProject
> {
> static class Hello
> {
> static void ChangePermsIfNecessary()
> {
> if (Type.GetType("Mono.Runtime") != null) {
> MonoSpecific.DoChmod();
> }
> }
> }
> }
>
> MonoSpecific.cs:
> using System;
> using Mono.Unix.Native;
> namespace helloProject
> {
> static class MonoSpecific
> {
> static void DoChmod()
> {
> Syscall.chmod(...);
> }
> }
> }
>
> ___
> 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] Running .NET on (OpenSUSE) Linux (13.2) still crashes with thread overload...

[Atsushi Eno]

I have no idea what kind of issue you are talking about, but anyways 
mono 3.8.0 is too old. Try newer versions. There should be even packaged 
ones:

https://build.opensuse.org/search?utf8=%E2%9C%93_text=mono=Submit+Query_tracker=bnc==0=1=0=1=0=1=0=0_type_id=

Atsushi Eno

On 2015年09月02日 02:45, André Verwijs wrote:

OS:
Linux 3.16.7-24-desktop - openSUSE 13.2 (Harlequin) (x86_64)
KDE 4.14.9
Mono version 3.8.0 (tarball Fri Oct 10 15:00:11 UTC 2014)



when running Windows .NET code on (OpenSUSE)Linux (13.2)  still crashes
with thread overload.  tips on fixes or performance settings are
welcome



view stacktrace online here:
https://drive.google.com/file/d/0B4_TSVggahj8MDFOMVR1V2dUc3M/view?usp=drivesdk

___
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] Class built by mono throws FileNotFoundException when run on windows

[Alex J Lennon]

On 01/09/2015 21:04, Edward Ned Harvey (mono) wrote:
> I've always used separate project files on windows and linux, in order to 
> include different compiler symbols, in order to make projects build with 
> different dependencies. I've been chastised here for doing it, so I'd like to 
> find a better way. (Miguel and others tore apart a pull request, saying I 
> should never check __MONO__, if I need behavior to be different on windows 
> and non-windows, I need to use a runtime check. The problem is, as described 
> below, the runtime check can't build or run on windows, so I'd like to figure 
> out how it should be done).
>
> Right now, I have a class, which is using Mono.Unix.Native, because of a 
> method that does this: 
> if (Type.GetType("Mono.Runtime") != null) {
> Syscall.chmod(...);
> }
>
> When built and run on mono, works great. The problem is building and running 
> on windows. In order to make it build, I copied Mono.Posix.dll into the 
> project and referenced it, with CopyLocal = False. This way, Mono.Posix.dll 
> doesn't get copied to the build directory, which is good because it's already 
> present on mono systems, and not needed on windows systems - the only reason 
> for it to exist in the project is because windows can't build without it.
>
> So it builds. But unfortunately, it won't run on windows. It throws 
> FileNotFoundException "Mono.Posix.dll" before evaluating the if-clause.
>
> The workaround I've found is to create a wrapper class MonoSpecific, so the 
> if-clause and the Mono.Posix call are not in the same file. But this is 
> clearly a hack. Is there a better way?
>
> Hello.cs:
> using System;
> namespace helloProject
> {
> static class Hello
> {
> static void ChangePermsIfNecessary()
> {
> if (Type.GetType("Mono.Runtime") != null) {
> MonoSpecific.DoChmod();
> }
> }
> }
> }
>
> MonoSpecific.cs:
> using System;
> using Mono.Unix.Native;
> namespace helloProject
> {
> static class MonoSpecific
> {
> static void DoChmod()
> {
> Syscall.chmod(...);
> }
> }
> }

Ned - I use a runtime check, interface definitions, and a factory method
that loads the concrete implementations from specific BSP DLLS using
Activator.

I do this a few commercial apps we have which I need to run "out of the
box" on Windows and Embedded Linux platforms running Mono.

e.g. Check here is the same as yours

public class MonoHelper
{
public static bool IsRunningOnMono
{
get { return Type.GetType("Mono.Runtime") != null; }
}
...

Then a BSP interface and a factory method to create a specific class
from a specific DLL based on a naming convention. I have some platform
auto-detection logic around this elsewhere.

private static  IBSP _thisBSP;
private static readonly object _objLock = new object();
   
public static IBSP CreateBSP(string platform)
{
lock (_objLock)
{
if (_thisBSP == null)
{
_logger.Debug("Creating BSP for platform: " + platform);

try
{
var oh = Activator.CreateInstanceFrom(
   
Path.Combine(Directory.GetCurrentDirectory(), "MyApp.BSP." + platform +
".dll"),
 
"MyApp.BSP." + platform + ".BSP");
_thisBSP = (IBSP) oh.Unwrap();
} catch(Exception e)
{
_logger.Error("Can't create BSP: " + e.Message);
}

}
return _thisBSP;
}
}

So this'll use MyApp.BSP.Mono.dll or MyApp.BSP.Win32.dll or whatever and
instantiate a BSP object implementing IBSP

Then I tend to have a set of other interfaces exposed by that BSP class
and the concrete implementations can then
have the dependencies on the platform specific DLLs e.g. Mono.Posix.

public interface IBSP
{
ISignalHandler SignalHandler { get; }

IFuelGauge FuelGauge { get; }
   
ISecurityHandler SecurityHandler { get; }

ISystemInfo SystemInfo { get; }
}

public class BSP : IBSP
{
private Win32SignalHandler _signalHandler = new
Win32SignalHandler();
private Win32SecurityHandler _securityHandler = new
Win32SecurityHandler();
private Win32SystemInfo _systemInfo = new Win32SystemInfo();

public ISignalHandler SignalHandler
{
get { return _signalHandler;  }
}

public ISecurityHandler SecurityHandler
{
get { return _securityHandler; }
}

public ISystemInfo SystemInfo
{
get { return _systemInfo; }
  

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Edward Ned Harvey (mono)]

I like the advice I'm getting from Alex and Robert.

Alex, you said you're using
Path.Combine(Directory.GetCurrentDirectory(), "foobar.dll")

When I look around, it seems like this might be more reliable?
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "foobar.dll")

I'm doing pretty well now, but not done yet - I have a base factory class, in a 
factory assembly, that returns instances of derivative classes from specific 
assemblies at runtime. The new question is: My main project only needs to 
reference the factory assembly, and in fact the derivative assemblies must also 
reference the factory assembly, because they derive from the factory assembly. 
So by default, the derivative assemblies dll files don't get copied to the 
build dir of the main project. I cannot reference the derivative assemblies 
from the factory assembly, because of circular reference. But I can reference 
the derivative assemblies from the main project, which seems to have the effect 
of copying their DLL's to the build dir, as desired.

So is it safe for me to reference the derivative assemblies from the main 
project, even though the main project doesn't actually use anything from those 
assemblies? Or is it possible that the JIT compiler or something will someday 
be aggressive and cause crashing? (I think it's good - just want sanity check).

And is this a reliable way of getting the dll's to the target directory? Or 
will the compiler/linker/whatever sometimes exclude those dll's from the build 
process, because they're referenced but never used? (Again, I think it's good - 
just want sanity check).

Thanks.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Alex J Lennon]

On 02/09/2015 16:32, Edward Ned Harvey (mono) wrote:
> I like the advice I'm getting from Alex and Robert.
>
> Alex, you said you're using
>   Path.Combine(Directory.GetCurrentDirectory(), "foobar.dll")
>
> When I look around, it seems like this might be more reliable?
>   Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "foobar.dll")

Glad it was of some use. Interesting point. Yes what you suggest seems
more correct for the .NET Framework, as the current directory may of
course change.

This is probably a result of me spending too much time over the years
with .NET Compact Framework / Windows CE which as I recall doesn't have
AppDomain.CurrentDomain BaseDirectory. Nevertheless it might be better
for me to grab the base location of the entry executable or something...
Thanks!

> I'm doing pretty well now, but not done yet - I have a base factory class, in 
> a factory assembly, that returns instances of derivative classes from 
> specific assemblies at runtime. The new question is: My main project only 
> needs to reference the factory assembly, and in fact the derivative 
> assemblies must also reference the factory assembly, because they derive from 
> the factory assembly. So by default, the derivative assemblies dll files 
> don't get copied to the build dir of the main project. I cannot reference the 
> derivative assemblies from the factory assembly, because of circular 
> reference. But I can reference the derivative assemblies from the main 
> project, which seems to have the effect of copying their DLL's to the build 
> dir, as desired.
>
> So is it safe for me to reference the derivative assemblies from the main 
> project, even though the main project doesn't actually use anything from 
> those assemblies? Or is it possible that the JIT compiler or something will 
> someday be aggressive and cause crashing? (I think it's good - just want 
> sanity check).

That's pretty much what I do.

fwiw I tend to have a MyApp.Core assembly with a bunch of interface
definitions and helpers in, then have console and/or UI projects
depending on that Core project and the BSP layers also depending on
Core, so I avoid circularity. Then console or UI projects reference Core
to build and I manually add in references to the output executable
projects to reference the BSP projects. This works for deployment even
though as you say the toolchain isn't aware of the dynamic loading
dependencies on the BSP projects.

> And is this a reliable way of getting the dll's to the target directory? Or 
> will the compiler/linker/whatever sometimes exclude those dll's from the 
> build process, because they're referenced but never used? (Again, I think 
> it's good - just want sanity check).

Never seen it happen..  (but who knows...) The other thing I've had to
do sometimes when pushed, and it eliminates any potential compile/link
oddities, is to set library files into the main project as content to be
copied across, although less than ideal. Had to do this with SQLite
libraries for some reason that now escapes me.

Cheers,

Alex

ssarily represent those of the company.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Running .NET on (OpenSUSE) Linux (13.2) still crashes with thread overload...

[André Verwijs]

the issue you can see in stacktrace.. but i've installed 4.04 now.
I'll have to see how this version does...

Thanks
André



> on 02-09-15 at 09:57 Atsushi Eno wrote:

I have no idea what kind of issue you are talking about, but anyways
mono 3.8.0 is too old. Try newer versions. There should be even packaged
ones:
https://build.opensuse.org/search?utf8=%E2%9C%93_text=mono=Submit+Query_tracker=bnc==0=1=0=1=0=1=0=0_type_id=


Atsushi Eno

On 2015年09月02日 02:45, André Verwijs wrote:

OS:
Linux 3.16.7-24-desktop - openSUSE 13.2 (Harlequin) (x86_64)
KDE 4.14.9
Mono version 3.8.0 (tarball Fri Oct 10 15:00:11 UTC 2014)



when running Windows .NET code on (OpenSUSE)Linux (13.2)  still crashes
with thread overload.  tips on fixes or performance settings are
welcome



view stacktrace online here:
https://drive.google.com/file/d/0B4_TSVggahj8MDFOMVR1V2dUc3M/view?usp=drivesdk


___
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] Class built by mono throws FileNotFoundException when run on windows

[Greg Young]

Use conditional compilation.

On Tuesday, September 1, 2015, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> I've always used separate project files on windows and linux, in order to
> include different compiler symbols, in order to make projects build with
> different dependencies. I've been chastised here for doing it, so I'd like
> to find a better way. (Miguel and others tore apart a pull request, saying
> I should never check __MONO__, if I need behavior to be different on
> windows and non-windows, I need to use a runtime check. The problem is, as
> described below, the runtime check can't build or run on windows, so I'd
> like to figure out how it should be done).
>
> Right now, I have a class, which is using Mono.Unix.Native, because of a
> method that does this:
> if (Type.GetType("Mono.Runtime") != null) {
> Syscall.chmod(...);
> }
>
> When built and run on mono, works great. The problem is building and
> running on windows. In order to make it build, I copied Mono.Posix.dll into
> the project and referenced it, with CopyLocal = False. This way,
> Mono.Posix.dll doesn't get copied to the build directory, which is good
> because it's already present on mono systems, and not needed on windows
> systems - the only reason for it to exist in the project is because windows
> can't build without it.
>
> So it builds. But unfortunately, it won't run on windows. It throws
> FileNotFoundException "Mono.Posix.dll" before evaluating the if-clause.
>
> The workaround I've found is to create a wrapper class MonoSpecific, so
> the if-clause and the Mono.Posix call are not in the same file. But this is
> clearly a hack. Is there a better way?
>
> Hello.cs:
> using System;
> namespace helloProject
> {
> static class Hello
> {
> static void ChangePermsIfNecessary()
> {
> if (Type.GetType("Mono.Runtime") != null) {
> MonoSpecific.DoChmod();
> }
> }
> }
> }
>
> MonoSpecific.cs:
> using System;
> using Mono.Unix.Native;
> namespace helloProject
> {
> static class MonoSpecific
> {
> static void DoChmod()
> {
> Syscall.chmod(...);
> }
> }
> }
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Studying for the Turing test
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SslStream X509 certificate

[Edward Ned Harvey (mono)]

> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of lorenzo.delana
> 
> I'm struggling to find a way to run a SSL server on Linux using mono,
> I have a certificate with a private key installed using certmgr and I can
> see by listing that the certificate is in the store with Private Key: True

I assume you mean you have a real CA signed certificate, with an intermediate, 
right? You're not doing self-signed or anything like that - your cert is not 
signed directly by any CA. The point is you have an intermediate, that needs to 
be served by the server, right?

Mono's implementation of SSL/TLS and x509 has always been rather incomplete. In 
particular, there are a series of bugs or missing functionality that prevent a 
mono SslStream server from sending the intermediate to the client, which is a 
problem. The official fix is in progress, but still a long way off - Miguel 
wrote about it here: http://tirania.org/blog/archive/2015/Aug-27.html

For business purposes, I have had to hack it to work. Officially, you should 
probably pay for Eidos SSLBlackBox, but it's kind of expensive. Unofficially, 
you can get my hacked version at http://downloads.conceptblossom.com/mono/ and 
if you want to see my source changes ... Apparently I've deleted the github 
fork, so it'll be some effort, but I definitely have a local repo sitting 
around somewhere.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] SslStream X509 certificate

[lorenzo.delana]

I'm struggling to find a way to run a SSL server on Linux using mono,
I have a certificate with a private key installed using certmgr and I can
see by listing that the certificate is in the store with Private Key: True

The same client/server code on windows works if I install the certificate
key in Personal store but using mono I keep getting follow error when client
connects the sever

System.IO.IOException: The authentication or decryption has failed. --->
Mono.Security.Protocol.Tls.TlsException: Server certificate Private Key
unavailable.

An example client/server can be found at
https://msdn.microsoft.com/en-us/library/system.net.security.sslstream(v=vs.110).aspx

I also tried to inspect all certificates available in the store with follow
code

var types = new StoreName[]
{
 StoreName.Root,
 StoreName.TrustedPeople,
 StoreName.TrustedPublisher,
 StoreName.CertificateAuthority,
 StoreName.AuthRoot,
 StoreName.AddressBook,
 StoreName.Disallowed
};
foreach (var x in types)
{
var store = new
System.Security.Cryptography.X509Certificates.X509Store(x);

Console.WriteLine($"store
cnt={store.Certificates.Count}");
   
foreach (var y in store.Certificates)
{
Console.WriteLine($"CERT=[{y.FriendlyName}]");
}
} 

and results nothing for any store name used.

Some direction to solve this problem ?

thx



--
View this message in context: 
http://mono.1490590.n4.nabble.com/SslStream-X509-certificate-tp4666570.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SslStream X509 certificate

[lorenzo.delana]

You are right, mine is a real certificate and more I executed the server app
on my local server with the correspondent FQDN for which the certificate
itself is released.

Really nice the article from Miguel's blog, thanks for pointing me to that.

I'm afraid that your mono fork not available but as you said may you found
your working copy of that and hopefully you can build up a serial patch
which I interested to look for.

I also tried to run the mentioned server/client example using DNXCore5.0 (
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
) using follow references
"System.Net.Sockets": "4.1.0-beta-23217",
"System.Net.Primitives": "4.0.11-beta-23301",
"System.Net.Security": "4.0.0-beta-23220",
"System.Security.Cryptography.X509Certificates": "4.0.0-beta-23301",

but the results was exactly the same, in fact the net core relies on the
host framework that in Linux is mono, but at this point I think I'll look
for the next TLS implementation steps directly from the mono git updates.

Actually I'm figuring which IDE I can use to browse using intellisense the
source code of the mono ( may mono-develop? and if yes, which is the
solution file ? :)



--
View this message in context: 
http://mono.1490590.n4.nabble.com/SslStream-X509-certificate-tp4666570p4666574.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Edward Ned Harvey (mono)]

> From: Greg Young [mailto:gregoryyou...@gmail.com]
> 
> Use conditional compilation.

Unless I've somehow missed your point? You said that twice, so I want to make 
sure we're on the same page - You're talking about defining a compiler symbol, 
and then using [Conditonal] or #if, right? The end result would be different 
binaries for different platforms. But you can see in my original post, I got my 
ego bruised and I got taken down a notch by Miguel and others here for doing it 
- I am *specifically* looking to avoid conditional compilation. That was the 
point of the original question. The folks who maintain the mono source consider 
it incorrect enough to reject any pull request that does it, except for 
compiler code. I'm here to learn a new pattern that is better and more 
flexible, although not trivial to learn for the first time. That's exactly what 
I've gotten from Alex and Robert: Use a factory and two assemblies.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Robert Jordan]

On 01.09.2015 22:04, Edward Ned Harvey (mono) wrote:

The workaround I've found is to create a wrapper class MonoSpecific,
so the if-clause and the Mono.Posix call are not in the same file.
But this is clearly a hack. Is there a better way?


You're depending on undefined behavior. The workaround is only
working because the JIT compiler is lazily compiling methods,
and won't compile DoChmod() under Windows.

You should mark DoChmod() with

[MethodImpl(MethodImplOptions.NoInlining)]

Otherwise the issue might come back unexpectedly.

However, if .NET 5.0 would start to eagerly compile assemblies
(for whatever reason), the issue will come back as well.


A sane and easy solution is to deploy Mono.Posing on Windows side-by-
side with you app.

Even when running on Mono, Mono.Posix should be picked up
from the GAC. Your copy won't be loaded anyway.

The super-sane solution is to abstract these calls away using a
factory and 2 assemblies, one for Windows and one for Mono
which has Mono.Posix as a reference.

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Jonathan Pryor]

On Sep 2, 2015, at 9:25 AM, Robert Jordan  wrote:
> A sane and easy solution is to deploy Mono.Posing on Windows side-by-side 
> with you app.

Just do that — and distribute MonoPosixHelper.dll as well.

Parts of Mono.Posix.dll are supported on Windows, e.g. Mono.Unix.Native.Stdlib 
and Mono.Unix.Catalog (INTL.DLL wrapper). There should be no harm in 
distributing these files with your app, other than a size increase.

 - Jon

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list