I have created a sample project in .NET Core 3 using NuGet package Microsoft.Extensions.Caching.StackExchangeRedis for distributed caching. Everything is working fine but I am not sure what would happen if multiple clients asynchronously and concurrently used some particular resource.
I am not able to find any new articles/solutions regarding the concurrent access and therefore using some mechanism for locking. There are many old articles but nothing that has been posted lately so I am not sure to what extend those solutions work years after their release.
Are locks necessary for asynchronous access and concurrent use of resources in .NET Core using Microsoft.Extensions.Caching.StackExchangeRedis package? If that's the case - some help (code/articles/links) would be much appreciated.
Related
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 have been very happily using Ninject for a long time now, and I really like it, but I am faced with a difficult choice since the release of ASP.NET Core and MVC Core.
Basically, out of the gate, Microsoft has revealed their own dependency injection system; Which is one that to my knowledge has gotten a lot of criticism. But my bigger problem lies with how it affects other libraries.
From another question I asked and other resources online, it seems that Ninject does not work out of the box with MVC Core. Though there is a "solution" given in the form of a verbose library Microsoft.Framework.DependencyInjection.Ninject and Ninject. This is even trickier because that library requires adding https://www.myget.org/F/aspnetmaster/ to your list of NuGet feeds.
I have done some digging and found where this library is hosted; It looks fine, it seems to work okay from what I can tell, but there are a few things that trouble me.
The library does not really appear to be headed by the Ninject creators
The library is buried pretty deep in an obscure repository
The actual Ninject resources online never mention it
So basically, I am very concerned that this is some kind of band-aide, and that support for Ninject (and even other container libraries) is dying out. Is there some hidden information that I'm just not discovering?
There is a discussion going on between maintainers of the existing DI libraries, whether or not to build, maintain and support an adapter for the new ASP.NET built-in DI system. The Autofac maintainers have confirmed that they will create and support an adapter, while the Ninject team has been silent, and other teams such as the Simple Injector team (that includes me) have explained that they won't support an adapter.
Personally, I think that the ASP.NET Core built-in DI library is a nice and clean DI library, but it is limited to simple applications. As I explained here, many features that are required for developing maintainable applications built around the SOLID principles are not supported. However, just like the Unity DI library did a couple of years ago, I think that this built-in container might actually trigger developers to start using dependency injection, which is a win for our industry.
These limitations make the built-in container especially suited to configure and extend the ASP.NET system itself. To build large maintainable applications, you will need to use a different DI library. This of course is fine; you will have to pick the right tools for the job.
Unfortunately, up until now, the ASP.NET team has communicated publicly that using a different DI library, means you will have to write/use an adapter. This unfortunately is the wrong message IMO, because most DI libraries are incompatible with the API presented by the built-in container (as I explained here and here in detail). Only Autofac seems reasonably in sync, which explains why the Autofac team choose to maintain an adapter. But do note that even Autofac has proven to be incompatible with the abstraction that Microsoft defined, and they (just like StructureMap) had to make big changes to their product to even be able to comply with the abstraction. And the Autofac maintainers are severely frustrated about the whole process and the abstraction in general. And as I explained here, even the ASP.NET provided adapter implementation of Ninject is broken.
This message by the ASP.NET team to use an adapter is IMO a big error, because this stifles innovation (while the DI library itself doesn't; it's just another DI library). The ASP.NET team is promoting a model where both your application components and the ASP.NET system (and all other sub systems that will plugin in the future) will be registered in your custom container. It is much more reasonable and practical to keep your application configuration separate from the configuration of the ASP.NET system (as explained here).
Because of this, I find the use of an adapter for any container rather useless. As I shown here it is really easy to plugin your own DI container, while keeping it completely separate from ASP.NET's registrations. This means that you don't need support for Ninject to be able to effectively use Ninject on an ASP.NET Core project. The only thing Ninject needs to do is to create a version that is compatible with .NET Core (in case your product needs to run on that new platform).
UPDATE: "Ninject 3.3.0 was released September 26th 2017 and now targets .NET Standard 2.0 and thus also runs on .NET Core 2.0." source
So in a nutshell, I'm not sure that support 'is dying out', although some DI maintainers (such as the Simple Injector team, and probably Castle Windsor and Ninject as well) have chosen not to build, maintain and support an adapter implementation for ASP.NET Core, because it is not needed, and is only in the way.
UPDATE November 2016
I've been discussing some improvements to ASP.NET Core with Microsoft to make it easier to plugin a container that don't have an adapter (take a look at my example repository and especially to the Startup.cs of the Ninject sample project), but until now Microsoft seems to stall progress because (as Fowler states hisself) their "bias towards conforming containers [is] clouding [their] vision".
The library does not really appear to be headed by the Ninject
creators
That library, and it would seem these also, look to be Microsoft created samples of Dependency Injection providers that were removed in beta7. Note that the link to DI in MVC 6 referenced by your original question says the following;
These DI container adaptors are temporary and are there for reference;
we expect that they will eventually be removed and replaced by the
respective container owners.
As they should be. Microsoft should not be responsible for maintaining 3rd party providers.
The library is buried pretty deep in an obscure repository
If you are not aware, ASP.NET 5 is still in development. Beta 7 is available on nuget as a pre-release, but there are other sources as well including;
https://github.com/aspnet/ (source code)
https://www.myget.org/gallery/aspnetvnext (nuget dev branch builds of the above)
https://www.myget.org/gallery/aspnetmaster (nuget master branch builds of the above [same as your question])
These sources are maintained by Microsoft.
The actual Ninject resources online never mention it
As with any new development, 3rd party library providers must themselves determine when (if at all) they will provide implementations of their products that support the new codebase. For some, it will be seen as most efficient to wait until the new framework is officially released, as API breaking changes are still highly likely to occur until that point. Whether support will be implemented at all is of course up to the providers resources, and/or in the case of open source the community.
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'm just starting with distributed application development. I need to create (all by myself) an enterprise application for document management. That application will run on an intranet (within the firewall, no internet access is required now, BUT is probably that will be later).
The application needs to manage images that will be stored within MySQL Server (as blobs) and those images will be then recovered by the app and eventually one or more of them will be converted to PDF.
Performance is the most important non-functional requirement.
I have a couple of doubts.
What do you suggest to use, .NET Remoting or WCF over TCP-IP (I think second one is the best for the moment I need to expose the business logic over internet, changing the protocol).
Where do you suggest to make the transformation of the images to pdf files, I'm using iText. (I have thought to have the business logic stored within the IIS and exposed via WCF, and that business logic to be responsible of getting the images and transforming them to PDF, that because the IIS and the MySQL Server are the same physical machine). I ask about where to do the transformation because the app must be accessible from multiple devices, and for example, for mobile devices, the pdf maybe is not necessary.
Thank you very much in advance.
WCF, only consider remoting if WCF presents some issue such as performance in your use case. You have many many more scaling and customisation options available under WCF.
Depends. If sending the images over the net presents an issue then it may have to be done locally. However as in (1) your existing suggestion seems ok.
See .Net Remoting vs. WCF for a similar question.
Definitely remoting if this is an option
Transformation - same box that the service is; since the service is going to funnel the images anyway - this is the best place. I would not put it on DB server, to better distribute the load and to separate non-db load from db specific load.
In addition, look into .Net 4.0 RIA services. They allow you best combo of .Net Remoting and WCF
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.