Has anyone found a smart way to use NServiceBus, without having to implements that useless IMessage marker interface for all messages?
Especially, when using DomainEvents, I would absolutely hate to couple my domains to a specific servce bus implementation.
I just noticed that Udi is adding an Unobtrusive Mode to NServiceBus 3.0. It appears
that will address the issue. There's even a sample writeup, but you would have to pull the latest off github at this point (Feb 2012). If you're willing to put up with some potential instability to get pure POCO messages, you might give it a try.
The IMessage interface is needed so that NServiceBus can automatically register those types in the serializer. When using domain events, it isn't recommended to publish them directly on the bus - instead, a domain event handler would translate them to service-level events (which inherit IMessage).
You might be able to create your own interfaces implementing the NSB marker interface and then ILMerge the NSB dependencies into your own DLL. This should allow you to only require references to your own Dll and no external references to NSB.
Its what NSB does for its own dependencies so you should be able to extend the idea, be sure to check out the pitfalls of this approach though - Udi blogged about it recently
http://www.udidahan.com/2010/08/01/cautiously-merging-il/
Six months later, still nothing about this issue (fix/improve) ??
Summary of possible solutions:
1) ILMerge or..
2) Custom Dispatcher for custom wrapped messages.
All this because of the IMessage marker interface.
Related
Do the Wasm/WASI developers ever plan on implementing processes that can communicate with each other through message passing in the Wasm/WASI runtimes (without going through the JS runtime)?
Old question:
Will the WebAssembly runtime be implementing message passing between modules, or are modules going to remain stateless? Or is that something WASI processes will have eventually?
Basically what I'm asking is: Will WebAssembly/WASI runtime ever have processes that can pass messages between each other? I'm guessing that's years away, but maybe it's not even on the agenda?
Wasm itself is addressing this largely via the Interface Types proposal. Learn more here: https://hacks.mozilla.org/2019/08/webassembly-interface-types/
I have been using NNG (C++) - now I need to write a C# plugin to read the NNG NanoMSG messages. But I am moving from pub/sub to a bus/mesh protocol. e.g.
https://nanomsg.org/gettingstarted/bus.html
Does nnanomsg support that?
What switches on the socket (options do I need) e.g. NN_BUS? NN_SOL_SOCKET?
The last PR merged included a Bus example. That said, I haven't used the Bus protocol.
If you're using nng, there's also a C# wrapper for that called csnng. I believe it doesn't include the nanomsg "compat" API, but it includes the nng bus protocol.
Not that it's a substantial amount of work, but I forked both NNanomsg and csnng to make .Net Standard libraries.
Don't know why the question should be marked negative. Although no one answered, I went implemented it with: https://github.com/mhowlett/NNanomsg
and the answers to the questions are:
Yes NNanomsg works fine with C++ NNG
Yes it has no problem with BUS protocols, and there are examples in the github.
In our web project we are using Ninject. Now we are adding plugins to our application. We want plugins to be able to add their own bindings. Ninject modules seems like a logical solution to this problem.
However, I don't see any guidance on how to avoid the following problem. What if a plugin adds a binding to an interface that already had a binding. Now the DependencyResolver will throw an exception when trying to resolve that interface.
I'm trying to make a change to our DependencyResolver that doesn't require rewriting all of the binding statements we've already written in the main application. I don't want a plugin to be able to break my main application. If a plugin needs to apply constraints to make it's bindings work then it is its responsibility.
So here's what I want.
A plugin would not be able to break the core app or another plugin because it added a binding.
It should not be necessary for any change to be made to core application or another plugin when I want to add a new plugin with its own bindings
Where there are multiple instances to choose from it should do the "logical" thing. The core app should get the instance it always would have gotten in the absence of the new plugins. The plugin should get the instance it specifically bound.
It seems like I should be able to override the resolving methods of StandardKernel so that it can implement these rules. It seems like knowing what module a binding was a part of would help resolving. But I can't find module or module name as part of the context, request, bindinginfo, etc.
Any thoughts on how to resolve this issue. I don't see that Ninject seems to answer what seems like a very obvious need for a modular system. A new module shouldn't be able to break an app. (It should only be able to "break" itself.)
You should have a look at Ninject.Extensions.ChildKernel. You could create a ChildKernel per plug-in and then load the plugins' module in their own ChildKernel.
This means that a plugin cannot rely on the bindings of another plugin, but a plugin may rely on the bindings of the Parent Kernel (root / application kernel). So you can provide certain types/services to the plugins.
By the way, if the implementation of Ninject.Extensions.ChildKernel does not match your needs, you might very well choose to implement your own extension. It's not that much code (see ChildKernel source)
This is a pretty fundamental question when using NHibernate in a web application, but I don't see any agreed best practice when searching the web. I've seen it done in lots of different places:
Created and disposed in the Repository method - This just seems silly to me, since when you get the object it's already detached.
At the beginning and end of the Controller Action - This seems better, but annoying to have to do it for each action.
At the Application level, in global.asax beginrequest and endrequest - This seems the best idea, but again, I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
Maybe there are other approaches?
Can IoC containers help in some way here?
Maybe you know of a good resource on the web regarding this?
And - what method do you use?
Thanks
Session per Request is probably the most used approach.
I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
In IIS 7 You can have access to the Session state in the Init event of Global.asax. That's why sharp arch uses beginrequest.
As for session management I agree with you - Global.asax is the best place for it. Event if you want to have a clean separation between layers and remove DAL settings from UI you can use HttpModule for it.
Also you can have a look at ayende's blog. It explains his way of session management
I have a simple business workflow with the following conditions
Users need to change the workflow itself using a desinger
The workflow is a long rinning workflow, so it will be serialized
Is there a way to automate the task of versioning different workflow assemblies?
The versioning of different workflow assemblies is not a trivial task and has a lot of complications. Here you can find a series of posts that deal exactly with this.
You can rehost the WF designer in your own application to let the end users change workflows. As you are hosting the designer you pretty much control what they can do. For example you can prevent them from removing or disabling activities and only allow them to add specific new activities in predefined area's of the workflow. The best approach is to save these workflows as XOML files and start them as such. This does mean you cannot add code to the workflow itself but you are free to define your workflow base class derived from SequentialWorkflowActivity (or the state equivalent) and use that as the workflow base class. This allows you to add code and properties. For example you can still add a CodeActivity but you need to link to code in the base class.
Workflow serialization, or dehydration as it is called, is used with running workflows to persist them to disk. This uses standard .NET binary serialization and can be a but tricky due to the long running nature of workflows. But no big deal once you know what to look for. See http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx for the start of a series of blog posts.
Not sure if you need it but there is also the capability to change already executing workflows. This uses the WorkflowChanges object. See here http://wiki.windowsworkflowfoundation.eu/default.aspx/WF/RuntimeModificationOfWorkflows.html for more details.
Here is another article on workflow versioning:
http://www.adefwebserver.com/DotNetNukeHELP/Workflow/VacationRequest3.htm
Basically you can version workflows that use assemblies if:
Any assembly used with workflows
must be strong named.
If a assembly
uses an interface it also must be strong
named and placed in a separate
assembly.
An entry in the web.config
can instruct asp.net where to find
the proper assembly.