I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).
Related
I'm starting a new project that'll require Mono and mod_mono to run under CentOS. There are two versions of Mono: the release which is 2.10.8, and the development branch, which is 3.0.7 as of today.
I'm wondering what would be the right version to start. Obviously the stable version would be my choice, but I'm not sure what Mono 3.0 adds that could be missing from 2.10. Note that the project will be ASP.NET 4.0, using MVC4.
What version would be recommended? The stable but older one (dates back from 19-Dec-2011!) or the more recent one?
Mono 2.10 supports ASP.NET MVC3, since you want to use MVC4, you'll have to use a later version.
More recent versions of Mono have solved a lot of issues in 2.10, including issues related to ASP.NET.
So you may want to go for a more recent version. I don't think stability will be an issue,
but you will have to perform proper tests to determine if the version you are using supports everything you are trying to do in your application.
Don't deploy to production without testing.
UPDATE: Correction, there is 'partial' MVC4 support in 2.10 and no support for async.
So while you might be able to use 2.10, your mileage may vary depending on what features your app uses
Some questions about Simple.Data and Mono:
Can I safely choose Simple.Data for a new project using Mono today?
There is the intention to maintain Mono compatibility in future versions?
The features are the same as the version for Windows?
Some testimony from someone who has already used in Mono?
Many thanks!
There will be a new official Mono build soon as part of the RC process. For now you should be able to clone the GitHub repo (http://github.com/markrendle/Simple.Data) and build the latest version.
Mono support is a requirement of the project, and will continue in all future versions.
Everything that works on Windows and MS.NET should work on Mono on OSX and Linux. If you find that something does not work, that is a bug and should be reported at http://github.com/markrendle/Simple.Data/Issues .
I have not personally got any projects using Simple.Data on Mono, so I can't offer a real testimony, but there are ~700 tests which all pass using Mono 2.10 on Mac OSX against a SQL Server DB.
I am looking for a good DNP3 library for .NET/VB applications.
Any recommendations?
Thanks,
The open-dnp3 project has recently added .NET bindings:
code.google.com/p/dnp3
Automatak maintains a fork of the opendnp3 library with .NET bindings:
http://automatak.com/opendnp3/
We have heard from users that opendnp3 significantly outperforms the TMW library for large master integrations.
Opendnp3 is Apache-licensed (free-to-use), but commercial support is available if you get stuck.
All I could find with a Google search was Trianble MicroWorks' .NET Protocol Components.
It looks like they're not exactly on top of the latest technology (it lists itself as .NET framework 2.0 compatible), but I wasn't able to find anything else that looked terribly promising.
I've managed to build the Automatak version of this library:
https://github.com/automatak/dnp3
and use the .NET bindings with C#, though they would work equally well with VB.
OpenDNP3 from automak is available in Nuget, but you should install 32bit openssl application to able to load it.It installs two required .dll files.
Been searching but the only thing I found was http://evain.net/blog/articles/2009/07/30/rebasing-system-reactive-to-the-net-clr which I got to work, but it feels like there should be a simpler way, specially since rx was first release back in mid 09.
You can now download it for .NET 3.5SP1 and .NET 4, so I wouldn't be at al surprised if it just worked against recent releases of Mono - no Silverlight doohickies required at all.
Having said that, I haven't tried it at all against Mono :)
Last time I tried, it did not work since one of the assemblies referenced either a native win32 dll or some framework dll not implemented by mono. However, there has been at least one release of Rx since I tried.
Yes, although I haven't tried it myself.
You can find mono-reactive at https://github.com/atsushieno/mono-reactive.
I've been playing around with it for a while and I've found that the .NET 3.5 SP1 binaries from Microsoft work on Mono 2.6.x. However, as of yet I haven't been able to get the .NET 4 binaries to work. It seems they expect IObserver/IObservable (possibly other stuff?) to be present in mscorlib.dll, which is not the case in Mono 2.6.x. Unfortunately this means no covariant/contravariant versions of IObservable/IObserver under 2.6.x.
Haven't yet dug through Mono's svn to see if I could get it working that way.
If you'll look at .gitmodules of mono repository you'll find reference to external RX repository which I expect will be the part of future mono distributions (Mono 3.0.1 doesn't contain it yet).
Hopefully this is a silly question and there's really a simple solution somewhere out there but...
Has anybody successfully gotten DbLinq to play nicely with Mono 2.4 on Mac OS X 10.5?
I've got my SQLite database ready but for the life of me, I can't find sqlmetal to generate my objects.
I'm guessing I might have to download a previous version of Mono that included sqlmetal, build and install it, and then just use the code generated from that version on Mono 2.4...but I'm hoping to avoid it at all costs.
I'd avoid using DBLinq for production code... many of Linq-To-SQL's features aren't implemented, and walking through the source code shows a low level of maturity... many of the methods are not implemented or marked as "unterminated".
...you've been warned!
Using the pre-compiled binary in this case just doesn't work.
To get a properly generated DbLinq data layer, you have to use the sqlmetal tool included with Mono (but, apparently, not with the pre-compiled binaries for OS X). You have to pull down the Mono trunk (along with all the dependencies) and build Mono from the source.
Once you build and install Mono from source, you should have the sqlmetal tool. Once you generate your code, it's as easy as including the generated *.cs file and importing Mono.Data.Sqlite.
Mono 2.6 will include for the first time a preview of DbLinq with Mono. You can take it out for a spin today if you install DbLinq on your own side-by-side with your current Mono setup.