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
Related
Using the tip found in this answer, I've been able to include general WCF support while converting my .NET Framework 4.8 assembly to .NET Standard 2.0. However, my code relies heavily on Service Discovery.
In a brute-force approach I tried these packages:
System.ServiceModel.Duplex
System.ServiceModel.Federation
System.ServiceModel.Http
System.ServiceModel.NetTcp
System.ServiceModel.Primitives
System.ServiceModel.Security
System.ServiceModel.Syndication
...but none of them contain the supporting namespaces/classes.
Will it be possible to include Service Discovery support in my .NET Standard 2.0 assembly?
Sadly DiscoveryClient is .Net framework only
so you can't convert everything to .net standard/.net core.
I am using NServiceBus as middelware for an asp.net core 3.0 API. I already configured the service in my API using NServiceBus version 7.2 because the documentation for that on the website of particular is amazing. Saddly I have a probleem because i got a licence for an older version of NServiceBus versions until version 7.1.x are valid.
my question is: is there a recomendition for configuring NServiceBus in asp.net core using Versions 7.1.x?
One option is to use an external container and configure the endpoint to use it. Take a look at the sample available in the README of the MSDependencyInjection container.
The same thing can be achieved, with very similar code using one of the supported IoC container: https://docs.particular.net/nservicebus/dependency-injection/#internally-managed-mode-using-a-third-party-container
I have an existing project basing on ASP.NET Core 2.0 running on full .NET framework. Microsoft doc of my case is here. The application is using Kestrel with libuv to serve incoming connections.
Theoretically, how does ASP.NET Core 2.1 improve/demote the performance of my case?
My project is running on full .NET Framework 4.7.2. It seems to me it will not benefited by the Performance Improvements in .NET Core 2.1. Right?
Also ASP.NET Core 2.1 release note mentioned.
Managed sockets replace libuv as Kestrel's default transport.
Does that make a lot of difference to the app running on full .NET framework?
You are correct. Since you are running on the .NET Framework, you are not affected by the performance improvements that were made with .NET Core 2.1. While the changes there are general changes that will eventually reach the .NET Framework as well (at least partially), we simply aren’t there yet.
If you want the best performance, then you should use .NET Core, which will always be the runtime where the most improvements will be made and where improvements will happen first.
However, that does not mean that the .NET Framework is slow or anything. Countless applications have been built on the .NET Framework in the past and that includes lots of really performance-critical things as well. Even Stack Overflow currently runs on the .NET Framework. So just because .NET Core can be faster, that does not make the .NET Framework bad. It’s perfectly fine to run on the full framework.
That being said, ASP.NET Core 2.1 of course also includes changes that may affect the performance. While most of the announced speed improvements come from the .NET Core 2.1 changes, it wouldn’t be surprising if there are other changes that will also show noticeable improvements. The Sockets transport layer is one of those.
Regardless of performance improvements, you should upgrade from 2.0 to 2.1 anyway. .NET Core 2.0 and ASP.NET Core 2.0 will reach EOL on October 1st 2018. So by that time, you should have upgraded if you want support from Microsoft.
I want to use Azure DocumentDb in my ASP.NET 5 project and it seems that DocumentDb .NET SDK doesn't work with DNX yet. Is it so? And if Yes maybe there is a workaround here?
You can get ASP.NET 5 to target the full .NET Framework as opposed to Core. The biggest advantage of targeting Core is that it would allow you to run outside of Windows, but if this is not a requirement for you then the full framework should be fine.
I don't know the status of work on supporting DNX, but assuming that's not going to come in time, I can think of several ways to work around it:
Hit the DocumentDB REST API directly
Run edge.js in process inside .NET and use the node.js SDK although there seems to be some question about what platforms are supported by edge.js.
Use node.js instead of .NET. My experience helping .NET developers ramp up on DocumentDB has convinced me that the JavaScript-centric design of DocumentDB means, it's much easier to use from node.js than it is from .NET, IMHO. Many of the .NET problems come from the difference between strongly typed .NET and highly dynamic JavaScript. Stored procedures are written in JavaScript not .NET.
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.