[Mono-list] I need a NuGet target for Mono

Tiago Freitas Leal tfreitasleal at gmail.com
Wed Aug 3 13:29:08 UTC 2016


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.


More information about the Mono-list mailing list