There is NServiceBus handler run on .net 4.0. I need to start it from VS 2008 project with 3.5 runtime (more specifically from SSIS 2008). The message to be send to the handler is parameter-less. What I tried:
I can not use NServiceBus API because of different .net versions, just can not add reference to the newer runtime library.
My other idea was to use NServicebus Gateway, but it turned out to be too difficult to run (xml+jsonp+get protocol with bunch of params) and lack of documentation.
Then I tried to send MSMQ message, but it did not work as well, because NServiceBus requires it to has special caption and extension message area which I can not specify, and it would be not reliable enough even if I could.
Are any other ideas on how to run simple parameter-less handler?
You can use the 2.6 version of NServiceBus which supports .net 3.5 - available here: http://www.nservicebus.com/Downloads.aspx
Related
I read some article about NServiceBus and i want use it, but i dont know it fully supported the .NetCore or not, i googled about it (and found some information like This), but it could not help me much, any one can help me?
UPDATE: Starting from NServiceBus 7.0.1 they introduce support on .NET Standard 2.0 and thus can run on .NET Core 2.1+.
Building endpoints with .NET Core 3.1 explains how to configure it on .NET Core 3.1 and generic host.
Original answer:
NServiceBus package has no dependency on any NetStandard so it means it cannot run on Core CLR. You can use it in .NET Core projects only if you target Full .NET Framework, not .NET Core.
As of 24 April 2017 NServiceBus does not support .net core. The most current public status is this https://particular.net/blog/nservicebus-on-net-core-why-not
However I can say that internally to Particular significant effort is being put into getting .net standard support shipped.
I will add this question to the list of follow ups for after we ship
Update: Particular Software announced upcoming support for .NET Core 2.0 on their company blog here: https://particular.net/blog/nservicebus-on-net-core-its-time
I'm using NServiceBus in my application, and since NServiceBus 5 RavenDb is not the default persistence and is not installed with NServiceBus. So I downloaded RavenDB-Build-2952 and installed with Development option on setup.
When I tried running my project (which still uses NServiceBus 4) I got an error that the license for RavenDb is not valid for windows authentication. There are not special configuration in my NServiceBus code regarding persistence of RavenDb.
How can I make sure that RaveDb installation uses the NServiceBus license?
Are you sure this is an error, and not a warning?
I had this problem a few months ago, and even though this message appeared in the log, the system functioned without issue.
Try ignoring the error/warning (I'm assuming you're debugging), and see if persistence still functions as needed?
I would like to mimic the behaviour of a VB6-Active-X-Exe.
To do that, I have created a new project and set its settings to "COM Visible=True".
I can now add this .exe to my main application, and I can call it, call functions in that .exe, etc.
However, it is not really out of process, I think.
I would therefore like to investigate more about such an .exe's behaviour.
But I did not find any official documentation on it.
Can somebody tell me where to find more info?
Thank you!
Out-of-process COM servers (ActiveX EXE's) are not as easy to create with VB.NET as they were with VB6. When you reference a .NET executable (as a .NET assembly reference, not as a COM reference) from another .NET project, it always treats it as in in-process library. The .NET Framework has no direct equivalent to COM's out-of-process servers. Typically, in such scenarios, it is recommended that you create a WCF service, a web service, or use .NET remoting. WCF services are preferred since they use the most modern technology of the three.
However, since .NET supports COM interoperability, it is technically possible to create a .NET executable which can be registered as a out-of-process COM server. Then, when another .NET project references it via COM (rather than as a .NET assembly reference) it will run out-of-process. Microsoft provides an example of how to do that here.
However, if you don't need it to be COM (so that it can be used by non-.NET applications), I would recommend that you go the pure .NET WCF service route.
I have deployed a WCF service to Azure running in a web role. The Azure is stock standard (so runs .NET 4.0). I am getting the following error:
Type 'System.Threading.Tasks.Task' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
My class library targets .NET 4
I have references to the Async targeting pack
It runs on my local machine via the emulator. My local machine is Windows 8 with .NET 4.5.
It seems to be similar to:
http://forums.lhotka.net/forums/t/11585.aspx
Is this possible, or do I need to get .NET 4.5 on to Azure?
In case the Task is being returned for an Async implementation (which is new in WCF 4.5), this was not supported in .NET 4.0. .NET 4.0 Supports IAsyncResult based Async.
The following applies if the Task was being returned as data (and not for Async):
Does your service returns a Task? That would not be right because a task is some 'work being done' - not 'data' as such. Maybe you tested the process in-proc and therefore it worked?
System.Threading.Tasks.Task is present in .NET 4 too. As the error says, the way your service is written, it needs to serialize a task, which is not possible practically. You should take a look at your service contract and the data types being used again.
I work at a financial institution, in a team whick takes care of a "home-made" corporate component. This component was built using .NET 1.1, and the other teams use it a lot, specially along with the legacy systems (the ones which are still in .NET 1.1 too)!
Now we want to upgrade this component to .NET 4.0 so we can use some new features (in fact, we want to use Websphere MQ, and its .NET library was build over .NET 2.0). However, can't simply change the runtime of our component, because our internal clients can't afford with an upgrade to their systems.
So, we need to keep a .NET 1.1 component working as a proxy to some service built in .NET 4.0. This was where my question came from: how this interoperability can be made? My first answer was using .NET Remoting 4.0 to comunicate these two parts. Although we can use a WCF service exposed with a HTTP binding (the .NET 1.1 component uses it as it was a ASMX web service), .NET Remoting has proven its performance advantage over the previous solution, but it's a legacy framework (http://msdn.microsoft.com/en-us/library/kwdt6w2k.aspx).
What I'd like to know is if you guys have another idea to do this interop. Is there a way to call a WCF service exposed with the netTCP binding by a .NET 1.1 client?
Thanks a lot!
The real solution is to get over the problems that are forcing you to use unsupported software (.NET 1.1). Then you won't have to do horrible things like the following:
Create a .NET 4.0 class library.
Add a Service Reference to your WCF service.
Create classes and interfaces which can be used to call the WCF service.
Expose them as COM classes and interfaces
Have your .NET 1.1 code consume the COM object and make calls through it
Would be, "compare the amount of effort you just spent on trying to make obsolete unsupported code work vs. the amount of new, useful work you just did".
Note also that this technique quite rightly places .NET 1.1 in the same category as Classic ASP in terms of its ability to use modern software like WCF.
Finally, note that I haven't found a way to make the WCF client in this situation to use a config file. It was necessary to configure it in code.
Is there a reason why you can't port the component and have two versions (a 1.1 version and a 4.0) version? That would let the legacy apps continue to use the component, but your 4.0 stuff could use a newer version without all the complexity required in your proposed solution.
Different versions of .net assemblies can play nice with each other, you aren't forced to only have one version of the component.