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.
Related
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 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
So we have developed an application that uses the .net 4.0 full(extended) libraries. Our workstations only have .Net 4.0 client on them. Our applications and infrastructure teams are wary about having us deploy .Net 4.0 full to all the workstations and wants to take some time to discuss and test.
Is there some way to deploy the extra .Net Extended dlls with our application so we can go around this?
No, you cannot supplement with just the dlls. All you can do is update to the full profile or find the features in your app that require the full profile and re-write them to avoid that requirement.
There's actually not that much difference between the two profiles. See the answers to this question for a more complete explanation:
Client Profile vs Full
That means that you may have an easier time than you think either re-writing the app to avoid the features, or convincing your staff to update the profile deployed to the workstations. It's likely just some advanced WCF features or a type provided with ASP.Net (like HttpUtility) that you're missing.
We are considering to change our present .net2 on IIS6 server to .net4 (or 4.5). Can someone help us with some basics about this?
After we install .net4 to our production IIS. Is every .net site defaulting to .net4?
we have had some dificulties with 64-bit version so we have forced IIS6 to run in 32-bit mode. Does update do something to this? After installing .net4, how can we force specific application pool to operate on .net2 mode and on 32.bit mode?
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
It's been a while since I've last used .NET, but here's my general suggestion.
First, Migrate to .NET 4! .NET 4 offers better security and new features. Consider that as your first option.
Second, in my experience, if you have multiple versions of framework installed on the server, you should be able to choose which version to operate that site.
Lastly, I'm not sure about 32/64 bit thing, but my suggestion is to simply fix it! Applications, especially heavy-load applications can operate better in 64-bit mode.
Make you application as future-proof as possible!
As for what problems you might run into, I really depends on what kind of APIs you're using, chances are, they will be a few deprecated methods, properties. Also, look at some new features, there might be new APIs worth trying, try that at a development server, it might increase overall user experience and even application performance.
Good luck!
Is every .net site defaulting to .net4?
When you add some website to IIS, it is assigned "DefaultAppPool" by default. So, it depends on what version of .NET framework set for your "DefaultAppPool". You can change application pool to target specific .NET framework.
After installing .net4, how can we force specific application pool to operate on .net2 mode
You can define more than one Application Pools in IIS targeting different .NET frameworks and then assign different Application Pools to different websites.
What problems there might come out on transforming .net2 sites directly to .net 4 sites? Or is there any?
I think it usually depends on your website; the libraries referenced, the patterns used, etc. No one can give you clear answer of it.
I know SysCache uses ASP caching under the hood, but since I'm not aware of the implementation of the ASP cache (and if it depends on anything IIS), I was wondering if SysCache would work in a non-web application (like a Windows Service)?
Activating it and using NHprofiler seems to show it is not.
No it doesn't, Syscache is an abstraction over asp.net cache. You have to use a different cache for the service.
EDIT:
I remember this blog post: http://www.hanselman.com/blog/UsingTheASPNETCacheOutsideOfASPNET.aspx
They say it should be usable outside a web-environment. It's just not recommended because microsoft maintains it to be usable in a web environment. That means that you can use it now, but you might have trouble when .Net 4 (or 5, 6, 7, ...) is released.