Hi Daniel, I know the same assembly is */supposed/* to run on .NET and Mono, be it on Windows/Linux/OSX and that might happen most of the time. I didn't try to run the same assembly on different Operating Systems. I compiled the source code that runs on .NET using Xamarin Studio targetting for Mono. These two very small experiences worked like a preview of problems concerning compatibility of .NET and Mono API implementation: 1) I ran a very simple Windows Forms exe on .NET and Mono on Windows. It ran on Mono indeed but it showed enough visual differences like controls not showing the correct colour. If this happens on very small and simple forms, what will happen on complex Windows Forms control libraries? 2) I ran a complex non UI library that uses a lot of reflection and the application crashed because of reflection. 3) According to what I read (namely How to target Mono framework from VS2015? <http://stackoverflow.com/questions/33028966/how-to-target-mono-framework-from-vs2015> ), there are compatibility issues even for ASP.NET.
So, everything runs? Yes it does, but there is no guarantee it won't crash or that it will behave the same way. Concerning your comments about detecting the OS at runtime, I don't question your approach, since you said it solved all your problems. But I might add some remarks: 1) My problems aren't OS related at all, since all the tests were made on a Windows OS. 2) Some years ago, NuGet didn't exist. It was invented to solve people's problems and make life easier, and indeed it does. Now it does exist and there are targets for monoandroid, monotouch, xamarinios, xamarinmac among a list a 12 Mono/Xamarin targets as you can see on the NuGet's list of Target Frameworks <https://docs.nuget.org/create/targetframeworks> . Unfortunately NuGet's attention is all on mobile platforms. So non-mobile Mono is off radars: non UI libraries, Windows Forms and ASP.NET were forgotten by NuGet. 3) If I can't solve it with NuGet targets, I will have to solve it by releasing Mono specific NuGet packages. Say the main library is called *Library* on NuGet. The Mono version will be called *Library-Mono*. I favour the use of conditional compiler directives like *#if MONO*. But I don't feel like filling the sources with platform dependent code - if/then/else blocks *that actually run* unlike conditional compiler directives where code never gets compiled. I really don't see the need or the point. After all, we have different executables for 32 and 64 bits, .NET, Android, Mac and these DLLs don't need to use this technique. It's enough to have different projects with linked source files, targeting different NuGet targets, and using conditional compiler directives. That's what me and lots and lots of people out there do. I understand Mono development isn't easy and that experienced Mono developers have find ways of doing this hard work. But Xamarin/Mono aquisition by Microsoft change a few things and will change even more in the near future. One of the things it should change is the development environment: NuGet targets, Visual Studio targets, ClickOnce targetting multiple OS, etc. I'm starting by asking the easier one to do: *NuGet target for Mono*. ----- --- Tiago Freitas Leal -- View this message in context: http://mono.1490590.n4.nabble.com/A-NuGet-target-for-Mono-is-needed-tp4668302p4668311.html Sent from the Mono - General mailing list archive at Nabble.com. _______________________________________________ Mono-list maillist - [email protected] http://lists.dot.net/mailman/listinfo/mono-list
