I need to integrate a .net2.0 app with nservicebus. Actually, I just need that this .net2.0 sends a message to a nservicebus queue.
Should I just create it by myself?
Theres any trick I should watch out, so when I upgrade to, lets say, nservicebus4 it wont break ?
using .net 2.0 will be a problem with trying to reference nservicebus. i don't think there is any straightforward way to reference nservicebus from a 2.0 application (outside of using a very old version, which would have problems too).
the shortest path would probably be to upgrade the framework version to 4.0. why not just do this? if you're talking about making changes and sending messages, you must have access to the source code and the ability to change it.
next after that might be to serialize a message yourself and send it with system.messaging. i think this is what you mean by "create it by myself." you'd definitely want to test that your messages still work if updating to another version of nservicebus on the handling side. udi is insistent on backward compatibility in updating versions of software, so i'd expect nservicebus would exhibit this probably and that your messages would still work, but you would want to make sure.
To "integrate" an app with NServiceBus simply include binary references to NServiceBus.dll, NServiceBus.Core.dll, and NServiceBus.Host.exe in your solution.
Try downloading the samples.
Related
Currently, I am working with SAP Business One SDK. I took some project from another team. This project is a SOAP web service. It has been written in ASPX technology, anyway another team used standard DI API library. This is the main problem with this solution because it causes a lot of problems with memory leaks.
In source code after every operation when DI API is called I try to use Garbage Collector, but unfortunately, it is not enough.
The web service is hosted on IIS and I had to set an option that for some time restart it. I know it is not the best solution, but it works. Obviously, that way generates many problems.
I have a question about it. Does any reasonable solution exist? Or I will have to rewrite source code using DI Server?
I have read a lot about this, I found some articles on the Internet. Please do not put any links in comments, because I am quite sure that I have read them.
Every time you use a DI API object you have to release it. Otherwise, it will stay in memory and it will cause the memory leak you mentioned.
The correct way to release them is to use ReleaseComObject. Remember that if the object is null you will get an exception so check it first.
if (oDocuments != null)
System.Runtime.InteropServices.Marshal.ReleaseComObject(oDocuments);
We're using NserviceBus as our messaging infrastructure with RabbitMQ as the transport.
I'm trying to upgrade to NServiceBus 6.0 from 5.* version. In 5.0, we could defer events using "Bus.Defer()". But it seems like in 6.0 we can defer only messages but not events ??
If I use below code with message being an "event", I get an error saying that events should be published.
var sendOptions = new SendOptions();
sendOptions.DoNotDeliverBefore(DateTimeOffset.Now.AddMinutes(30));
sendOptions.RouteToThisEndpoint();
return context.Send(message, sendOptions);
but context.Publish(message, new PublishOptions()) method takes in "PublishOptions" which does not have an option to defer.
Am I missing something here ? Appreciate if someone could help.
Some changes are not immediately effective, so we will have to defer some of those events.
The publisher should not be constrained by any of the subscribers.
Is it correct to assume that Product Authoring system publishes ProductDataUpdate events regardless of when the actual effective date will take place? In such case, you are already notified about a decision that was made. What are you, as a subscriber, going to do with it is a different thing and entirely internal.
You could send a command, for the sake of this discussion call it UpdateProductCost, that would be a delayed message if EffectiveDate is in the future. Otherwise, it's an immediate command.
I've got an answer in another forum and I think it is the most relevant, So posting it here so that it could help someone in future. Thanks to Daniel Marbach
https://groups.google.com/forum/#!topic/particularsoftware/ivy1wdsycT8
Bus.Defer in v5 was internally always doing a send operation. It seems the difference to v6 is that it automatically disabled the messaging best practices. You can achieve the same by calling
var sendOptions = new SendOptions();
sendOptions.DoNotDeliverBefore(DateTimeOffset.Now.AddMinutes(30));
sendOptions.RouteToThisEndpoint();
sendOptions.DoNotEnforceBestPractices();
return context.Send(message, sendOptions);
https://docs.particular.net/nservicebus/messaging/best-practice-enforcement
I am doing some work using the NCQRS frameworks and NServiceBus 3.3.4. I have been struggling with getting some subscriptions to fire and as far as I can tell all my config is 100% correct.
After some digging I noticed that the MessageType name saved in the subscription document in Raven DB looks a bit odd. The NCQRS framework wraps the domain event in a generic typed named EventMessage'1. Now when that message is saved in the scubscription store it seems to chop off part of the name, see below:
Ncqrs.Nsb.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Version=1.0.0.0
Where I would expect the name to be more along the lines of this:
Ncqrs.Nsb.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Version=1.0.0.0]]
At the very least.
Could this be a bug or am I doing something wrong? My subscriptions in the app.config appear as follows:
<add Messages="Ncqrs.NServiceBus.EventMessage`1[[Platform.Events.Category.CategoryRemoved, Platform.Events]], Ncqrs.NServiceBus" Endpoint="core.platform.domain" />
It's making me crazy!
This is not a bug, NServiceBus won't support this since we want to push you into using more explicit message contracts. Perhaps there is a way to configure NCQRS not to require that "EventMessage" thingy?
I checked out the latest SVN trunk of qooxdoo and now i have the following problems:
Some events seems that they are not comming through
Virtual Lists are not filled anymore (the _createWidget() method of the extension from qx.ui.virtual.cell.AbstractWidget is not called)
My original version was QX 1.0.1-pre and the problems appeared also when i tried to migrate to 1.2
Just to get the obvious stuff out of the way, did you follow the steps of the migration guide and make any necessary changes outlined in migration.log?
Aside from that, the virtual widgets are still experimental and no migration path is provided, meaning you'll have to go over your code and check if the parts of the ui.virtual API you're using have changed since 1.0.1.
For the missing events, please provide some more information: What events are you listening for?
The problem with the event seems to be a bug in Qooxdoo
Hoepfully someone can shed some light on a problem - I am trying to listen to\intercept all windows messages generated by an application and dispose of certain types, for example Notify or Gesture messages.
I have been reading articals on how to do this using the Microsoft.WindowsCE.Forms.MessageWindow and creating a class which inherits this, overrides the WndProc method but I have been unalbe to get this start listening\watching the message queue automatically when the application starts.
I know it is possible to do this with the OpenNetCF framework and the Application2 namespace however I would prefer not to use 3rd party software at the moment - no offence to the OpenNetCF guys.
Hopefully this makes sense. Also, i am using C#2.0 and Windows Mobile 6.5.
Thanks for your help,
Morris
The solution, then, is pretty simple - all you have to do is spend your time duplicating what the Smart Device Framework code is doing.
You need to create your own message pump via P/Invokes to GetMessage, TranslateMessage and DispatchMessage (it will look just like it does in C). Use this pump instead of calling Application.Run (so there can be no calls to Application.Run in your application).
Inside that new message pump insert your filtering logic.