I´m using Official .NET Bindings for ZeroMQ (x86) 2.2.5 and cannot figure out how to set this Socket Option. Can anyone please shed some light on me ?
CLRZMQ is obsolete, NetMQ(https://github.com/zeromq/netmq) is now the official stack for windows.
in NetMQ use socket.Options.Mandatory = true;
CLRZMQ is not obsolete (see zeromq.org). The key difference between the two is in the approach:
CLRZMQ is binding project which actually uses libzmq library in background (it's a .NET wrapper for libzmq library);
NetMQ is .NET-native port of ZeroMQ, meaning that it does not wrap existing libzmq but rewrites it in pure C#.
Which one to use? Well, there's no simple answer. Here are few important things to keep in mind while choosing:
When it comes to portability - NetMQ wins by far, especially due to the fact that there's .NET Core version of NetMQ. Deployment is also easier with NetMQ - there are no native libraries to worry about (x64 / x86, etc.).
On the other side the fact that NetMQ actually rewrites everything is bit scary for me - there's always risk that something is not precisely mirrored from the original code, and that it may cause incompatibility with other ZeroMQ nodes. There's also question how fast NetMQ will implement new features from the original library.
Performances. At the moment I don't know which library wins in performances, but this is definitely thing to consider while choosing. libzmq should be significantly faster than any managed code, but in communication between CLRZMQ and libzmq marshaling has to take place, so I really can't predict which library will win in speed.
Related
I have a Xamarin.Forms App based on .NET Standard 1.4 that uses protobuf-net to store objects in the database that will be sent to a WCF service at a later time.
On Android and UWP "managed" everything works fine but - after searching through repositories, articles and blogposts that can no longer be accessed, and also after trying to get the precompilation tool to work, but failing at that - I have one simple (probably not) question: How do I get protobuf-net to work in "restricted" environments like UWP/.NET Native and iOS/Xamarin?
Right now I don't have a great solution for this scenario. I know some people have made it work, but I'm not expert enough in UWP / Native / iOS to give you reliable "here's the path to success" instructions.
UWP / .NET Native and iOS share (as you know) a common issue: lack of full runtime emit. I understand why this is. It is just: tricky.
Historically, protobuf-net has tried to solve this problem via a build tool that repeated the existing IL-emit usually done at runtime - as a build-time tool. This was ugly and nasty, but it worked. Kind of. To hack around some platform restrictions, protobuf-net used some of the IKVM tooling to help with this, but as the .NET framework scene has continued to expand this is basically not viable. Plus: the IKVM tool is now abandoned and won't be being maintained.
In parallel with this, there is increasing impetus to investigate some newer concepts:
full async/await for asynchronous IO sources: note that this is extremely unfriendly to IL emit, but is almost embarrassingly easy to implement in C#
"pipelines" / "channels" / "streams 2" - whatever it is being called this week; but: the new allocation-free IO concept that is being used in Kestrel (I helped kick this ball around a little bit when it was in the early stages, so I'm familiar with what needs doing) - note that this also ties into async/await
and of course: how all of the above relates to pre-generation
Right now, I'm very much of the opinion that the best route forward is for the pre-gen scenario to switch to emitting C# via build-time tooling. I have repeatedly petitioned MS for improved automated C# emit based on Roslyn, but so far: no joy (vexingly: the asp.net stuff even had a fully working proof-of-concept, but it is shelved). So right now I'm thinking: we need to assume that isn't going to happen, and basically write it independently. This isn't necessarily as complex as it sounds (and: codegen of various forms is very familiar to me). The advantage of C# emit here is that I don't need to fight the intricacies of every framework - I just need to make it compile (well, and run, obviously).
So: what's holding me back? In theory: nothing. I just need to get this stuff written and deployed. In reality: life, time, etc. I am guilty of prioritising things that impact me daily, and the reality is that I'm not really a daily user of those platforms, which means I'm not feeling the pain that you're feeling. But: I hear you loud and clear, and I am trying to ramp up the v3 work that should address these points. I genuinely want to have a good story for those things - and my aim is that by moving to a C#-emit model (for pre-gen, at least): it helps me. And if it helps me I know it won't be the forgotten toy in the attic / basement that I know is there but which it is hard to find the motivation to go to the trouble of finding.
I recently posted a question on Using Delegates to simulate connected objects where I received a great answer on using the TPL DataFlow library to very easily and cleanly develop a solution to my application.
The problem is that I am stuck on .NET 3.5 or under for C#. I thought I might have been able to upgrade to .NET 4.5 be I cannot at this stage. As far as I've been able to determine I cannot retarget the Dataflow library to .NET 3.5 so my next solution is to look for a C++ alternative under a similar vein to that of TPL Dataflow - Its not the best scenario but I can compile C++ code to a DLL and import it to our C# application.
To summarize my requirements for a C++ library for this question:
I need to be able to connect nodes together in complex networks and pass units of a resource between them. Some of them will produce finite amounts of resource over time. Others will consume it at a specific rate.
You might consider using mono's version of TPL Dataflow and compiling it yourself for .Net 3.5.
I think the biggest problem you'll encounter when trying to compile that code is that it relies heavily on TPL, which is not normally available for .Net 3.5. But it seems a backported version is available in older versions of Rx, so using that could work.
(Also, parts of the mono's version of TDF was written by me and I didn't receive pretty much any feedback about it, so it's quite certain there are bugs in there.)
This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).
Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.
ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.
You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.
I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo
as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.
I love programming with .NET, especially C# 3.0, .NET 3.5 and WPF. But what I especially like is that with Mono .NET is really platform-independent.
Now I heard about the Olive Project in Mono. I couldn't find some kind of Beta.
Does it already work? Have any of you made any experiences with it?
Edit: I know about Moonlight. But I want a standalone WPF application. And because of Moonlight I hope WPF on Linux will become true.
You'll have better luck working with Moonlight, which targets the Silverlight API, which is a subset of full WPF.
edit: Sure, Silverlight isn't "intended" for the desktop, but there's no reason why you can't embed a silverlight engine in your application. It's been done before, such as for the Mac NY Times Reader
more edit: see Miguel's post on Standalone Silverlight Applications
Update: Since people keep upvoting this, I want to point out it is long since out of date. Mono got acquired by MS years ago, and their posture regarding open-source has changed, so consider this post obsolete. (As obsolete as the WPF framework itself, heh).
Mono is in a bit of an uncomfortable position when it comes to Microsoft APIs such as Winforms and WPF. A subset of the .Net technology is an ECMA standard, but free implementations of these APIs are probably on shakier legal ground. I believe this was a large factor in the covenant between Novell and Microsoft, which is good for Novell customers. But people who use Mono that aren't customers of Novell aren't protected. For this reason a lot of people in the F/OSS community look askance at Mono despite its technical merits.
For this reason, Gtk# will always be preferred, since it is truly Free. Many people consider it to be superior to Winforms anyway. As far as WPF is concerned, it will almost certainly be a low priority for Novell. They may implement it eventually, but I would expect Moonlight to be the closest you could get for the forseeable future.
Since posting this, Microsoft has extended their covenant to anybody who implements the ECMA 334 & 335 standards.
From the mono website
At this point, the Mono project does
not have plans to implement Windows
Presentation Foundation APIs as
part of the project.
Moonlight is an implementation of silverlight, which is a browser based flash like technology based on a subset of WPF.
In my opinion the choice to not implement WPF is monos biggest mistake. As WPF is fast becoming the default choice for new .net user interfaces. See this blog for more.
There is a library called Silverform SDK that aims to provide cross-platform WPF and Silverlight implementation.
The library is implemented in managed code and currently works with OpenTK and Unity3D as render backends. Major functionality, such as binding, layout, main controls and primitives, has already been implemented (check Unity web player demos here). Initially it has been focused on Unity3d render, while support for standalone Mono applications will be added as a separate build in the future.
Disclaimer: I am one of the developers of the library.
If you check Known bugs of this link(also includes steps needed to install .NET onto Ubuntu)or this you may find that some(may be buggy) version of WPF works on Wine as for now. I did not find any definite test done as for now, but worth to try to run WPF "Hello world".
UPDATE2:
I have run latest IlSpy on latest Wine for Ubuntu 16.04. With 32 bit version of dotnet45 and corefonts installed via winetricks with windows 7 compatibility.
For this time no crashes and all things work fine. Fonts look really good.
IlSpy is shown via WPF and for person who loves programming with .NET is essential tool - the decompiler.
I downloaded latest portable SharpDevelop(build using WPF) with no extra. It started. Failed to create WPF project. Created WinForms. After opening some cs files and evidencing some glitches, tried to type - and it crashed.
UPDATE
I followed steps and got latest ILSpy.exe running on Ubuntu 14.4.
Next items to note:
wine stated that dotnet40 is not supported by 64 configuration, changed to 32 bit
fonts are ugly, but readable
basic functional works fine - I can see decompiled code - which is good enough for some development, but View -> Search and View -> Options -> Display crash.
Conclusion:
WPF on Linux is possible. But need some way to tackle issues.
From the Olive home page:
Olive is unsupported, should be
considered as experimental software,
and since it implements a shifting API
there are no guarantees of any kind
about the stability of the API.
I doubt anyone would have used it in a real project.
Yes, it is possible using NoesisGUI a real-time multi-platform XAML implementation. There are a few games already released using this technology in Linux, like VoidExpanse
Disclosure: I am one of the developers of this product.
I heard a podcast interviewing miguel de icaza (the mono lead) maybe a few weeks ago, so that would have been maybe mid-december 2008, and he said that they had no WPF support at all yet.
Theoretically, a stripped version of WPF COULD be compiled against WinPR or LibWine to run on Linux.
Currently there is no such setup, so someone would need to make one. Hopefully this might change soon.
As of running against or in a full Wine environment, I think that is seriously overkill and will result in too much bloat to be worth making a very small number of additional programs work.
Has anyone used Mono, the open source .NET implementation on a large or medium sized project? I'm wondering if it's ready for real world, production environments. Is it stable, fast, compatible, ... enough to use? Does it take a lot of effort to port projects to the Mono runtime, or is it really, really compatible enough to just take of and run already written code for Microsoft's runtime?
I've used it for a number of internal and commercial projects with great success. My warnings:
Write lots of unit tests and make sure they ALL pass under Mono -- this will save you a lot of trouble.
Unless you absolutely have to, do NOT use their embedding API. It's damn easy to use, but it's ungodly easy to garbage collect valid memory or leak all of your memory.
Don't ever, ever, ever even come close to SVN and unless there's no choice, do not compile your own. Things change so often in SVN that it's highly likely you'll end up implementing something that doesn't work on a release version if your project is significantly large.
Don't try and figure out problems on your own for long, use the IRC channel. The people there are helpful and you'll save yourself days upon days -- don't make the same mistake I did.
Good luck!
Edit: The reason I say not to compile your own from source (release or SVN) is that it's easy to configure it differently than release binaries and hide bugs, for instance in the garbage collection.
Edit 2: Forgot to answer the second part to your question. In my case, I had no issues with porting code, but I wasn't using any MS-specific libraries (WinForms, ASP.NET, etc). If you're only using System.* stuff, you'll be fine; beyond that, you may run into issues. Mono 2.0 is quite solid, though.
I find Mono to be mostly binary compatible with MS. Hence I simply compile with MS, and run anywhere, like Java is meant to be!
The performance of Mono on Linux is getting very close to MS, as little as 2 times slower in some cases, vs 5-10 times slower when running Mono on Windows (but you should really stick to MS then).
I had some experience with Mono.
Pure .NET stuff (like business logic, controllers or algorithms) can be ported without any problems. Yet, weird things start showing up in the components that interact with operating system, UI, services or persistence. So be prepared for some debugging and hacking.
Things that might help:
Component-Driven Development - so that code is reused by Windows .NET and Mono, while differences are isolated and tested)
Continuous Integration running and checking everything against Mono and MS.NET, so that possible issues could be discovered as fast as possible (automated deployment and sanity checks are also recommended)
There are not a lot of UI component suites for shell development in Mono.
When a component vendor says that his code is "compatible with Mono", it is not same as "runs on Mono and is supported".
Although in the present, there are some companies going into production with Mono, I'd still wait before rushing in there due to:
Lack of decent and commercially supported UI component suites
Issues with efficient garbage collection
Not the best debugging experience (compare with the historical debugger in VS 2010)
PS: if there is a company offering fully managed cloud computing solution (not just a VM, but more like Hadoop equivalent for .NET), then I'll be forced to jump in despite these issues.
If you are doing ASP.NET 2.0 work, it works very well. Winforms may work, but it can cause display issues. If you want compatibility in a forms app, I would suggest GTK#, as it is crossplatform.
Like suggested, as long as you thouroughly test, I would agree to using it commercially if that is a viable option for you, unless it is winforms you need. In my opinion, i would stay away from it for now. And forget WPF as there is no support at this time, and there may never be (although they are working on moonlight, aka silverlight for linux)
I haven't used Mono myself but you may be interested to know that FogBugz uses Mono to provide Lucene.NET on Linux platforms. (I only know this because Joel mentioned it in passing in Stack Overflow Podcast #24.)
I've got a bunch of shell apps in production.
I agree with #cody-brocious, write a lot of unit tests. I found in the past that Regular Expressions didn't work exactly the same way as the windows CLR.
It's actually simplier than you think to get into, just compile and run. If you use NAnt on your projects its even easier to transition.
I typically install mono from the source releases and I haven't had any problems.
I've used it for encryption/decryption tools and it worked fine.
In the future, I would consider using Mono/C#, but I would not expect it to be 100% exactly like .Net on Windows.
Of course, you can, especially after Mono 2.0 has been released.
Mono 2.0, is ready for real projects.
You can check this