I search for an equivalent of the IShouldInitialize interface in ABP.IO framework.
In ASP.NET Boilerplate, the interface marked the framework to run an Initialize method: https://aspnetboilerplate.com/Pages/Documents/Dependency-Injection#ishouldinitialize-interface
But I don't find an equivalent in ABP.IO. Does it exists?
Thanks in advance.
Related
We have a commercial library that I am working to port to .NET Core. There are a couple of calls in it I want to retain to use only if running in .NET standard. (For the curious, one set is to read a file on a Windows server that requires credentials to access.)
Is there:
A call that will tell me if I am running under .NET Standard vs. .NET Core.
Is there a way to have a class that is only going to be instantiated/called if running under standard, but the DLL will still load fine under Core?
Also asked on MSDN
Since what you describe, having a single nuget package and being able to specify different behaviours or dependencies depending on the framework the nuget package is installed into, can only be reached through Multi Targeting I will assume you are doing that or will be doing it.
Once you have specified target frameworks, you have pre-defined variables to use in precompile blocks:
#if NETFRAMEWORK
// use full framework class here. You were installed into a full framework app or library
#elif NETCOREAPP
// use .NET Core class here. You were installed into a .NET Core app or library
#else NETSTANDARD
// uh... okay... you were installed into another .NET Standard library,
// we still have no idea where *that* might be installed... help?
// Maybe make it configurable after all?
#endif
.NET Standard is not a runtime, it is a set of APIs that a runtime must implement in order to be compatible. So basically this allows people to have a library target .NET Standard and have one code-base that will run in all supported runtimes because it is guaranteed that those runtimes will have an implementation for those APIs.
.NET Standard doesn't have implementation at all, it just defines a set contract of APIs which is used at compile time, but at runtime the APIs used will be the ones in the runtime the consumer decided to target their application for.
A better runtime detection would be to use RuntimeInformation.FrameworkDescriptor APIs. We do that for our framework tests to know what we're running our tests on: https://github.com/dotnet/runtime/blob/master/src/libraries/Common/tests/CoreFx.Private.TestUtilities/System/PlatformDetection.cs#L21
You could also achieve this via reflection by doing something like: typeof(string).Assembly... if the assembly is System.Private.CoreLib you're on .NET Core, if it is mscorlib, you're in .NET Framework.
I have an ASP.NET MVC 5 project which works well and it also references a .NET Framework 4.7.2 Class library which produces some CrystalReports. CrystalReports does not support .NET Core, so the class library will stay with full .NET Framework.
Now, if I upgrade the ASP.NET MVC 5 to ASP.NET Core 2 (or 3), will I be able to reference the class library and possibly generate those CrystalReports?
.NET Core doesn't support inclusion of .NET Framework libraries. Period. However, .NET Core supports .NET Standard, and since .NET Framework also implements .NET Standard, Microsoft made a special exception in the compiler to allow you include .NET Framework libraries, with the caveat that they may not actually function at all or totally. You get a warning to this effect when you include a .NET Framework library in a .NET Core project, and it's on you to ensure that the library works correctly end-to-end.
The largest majority of .NET Framework libraries do work, as long as they don't utilize .NET Framework-specific APIs (most notably Windows-specific APIs). If they do, then they will not work.
Here, it seems this library does utilize Windows-specific APIs, meaning it is incompatible with .NET Core. In such a situation, you can still create an ASP.NET Core project, but you must target .NET Framework, not .NET Core. That is, until ASP.NET Core 3.0, which cannot target .NET Framework. ASP.NET Core 3.0+ depends on .NET Standard 2.1, which no version of .NET Framework supports or ever will.
As such, if you need to use a .NET Framework library that is not 100% .NET Standard 2.0 compliant, you must target .NET Framework, and if you must target .NET Framework, you are then version-locked at 2.2 of ASP.NET Core.
UPDATE
This answer is a little old now, but just in case it might still be helpful, the way I've dealt with this kind of thing personally is to create a very small and simple API. Basically, you create a ASP.NET Core 2.1 (LTS) app targeting .NET Framework, and all this app does is interact with the .NET Framework library. Here that would mean creating the report. Then, you're free to create your actual app as an ASP.NET Core 3.1+ app targeting .NET Core, and you just call out to the API to get the data, report, whatever you need. It's sort of like a lightweight microservice approach.
Chris has already provided an excellent and accurate answer but I'll try to add a bit more color by sharing the results of an experiment I did.
Experiment: I have a web application targerting .Net Core 3.1. It calls a library that targets the Full Framework. In that library I specifically make a call to a Full Framework API that is not available in .Net Core 3.1, in this case that type is SHA512Cng.
My library code is:
/// <summary>
/// Returns a base64 encoded Sha512 hash of the text specified.
/// Uses the SHA512Cng implementation to do the hashing.
/// </summary>
/// <param name="text"></param>
/// <returns></returns>
public static string Sha512Hash(string text) {
using (SHA512Cng sha512Cng = new SHA512Cng()) {
byte[] bytes = Encoding.ASCII.GetBytes(text);
byte[] hashButes = sha512Cng.ComputeHash(bytes);
return Convert.ToBase64String(hashButes);
}
}
In the home controller of my web application I make a call to use that Library method like so:
public IActionResult Index() {
string hash = App.Lib.Sha512Hash("hello world");
return View();
}
Pretty simple experiment. This code is running on a windows machine that has the full framework installed. If I call this library from a website targeting the Full Framework it works perfectly.
When I call this method in the Library from a .Net Core 3.1 website, what happens? That's the questions I wanted this experiment to answer.
And the answer is...
It throws the following exception:
System.TypeLoadException: 'Could not load type 'System.Security.Cryptography.SHA512Cng' from assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.'
Screenshot:
So the takeaway is this: It really doesn't matter whether your code is running on a box with the Full Framework or not. If you reference a Full Framework Library from a website targeting Asp.Net Core 3 and make a call into a method that references a type that is incompatible with Asp.Net Core 3, then it's gonna throw.
I have a new Asp.Net Core MVC website. Asp.Net core only targets full .net 4.6.1 framework.
I have added another project to the solution, which is windows (not Asp.Net core) class library. This class library was developed before 2 years but recently converted to target .net framework 4.6.1. So I thought to re-use it. I was able to bring the reference in with Asp.Net core mvc site. However, I like to inject configuration (IOption) to this class library. I tried searching around but I could not find any help. I find a few posts where there was a discussion around adding a startup.cs in class library and retrieving the configuration. However, it was not quiet clear from the discussion, which type of class library they were discussing about. I think I could implement the same with class libraries build with .NET Core. However, how I can achieve the same implementation with older libraries I have.
I really appreciate any help on this. I like to access IOption service in the class library developed earlier.
I have heard that in the next version of ASP.NET (ASP.NET vnext) there will be dependency injection built into the framework.
Does anyone know more about this?
Will it be unity or a new framework?
Where can I find more information about this?
ASP.NET vNext will have built-in support for dependency injection. It is very basic support that currently supports only constructor injection.
The source repo for ASP.NET vNext's dependency injection logic contains sample implementations of how to wire up several community-built dependency injection systems, including Autofac, Ninject, StructureMap, Unity, and Castle Windsor. However, those are just samples and are not all complete or fully functional.
The idea is that for basic scenarios a developer can use the built-in DI, whereas people with more advanced requirements or if they already have a "favorite" DI system can plug that in instead and get richer features.
It will contain common abstractions for Autofac, Ninject, StructureMap, Unity, Windsor as seen here Dependency Injection github If you see in the Project.Json it has dependencies on these specific frameworks.
Here is instruction how to use Autofac with ASP.NET 5
This blog explains the details on hov to wire up your own container: http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
I heard there is a port of spring framework to .Net framework which is called spring.net.
Anyone can compare those two frameworks? If design the system, which one is prefered or both can be used.
Spring is for Java, Spring.NET is a .NET port of the Java framework.
See the overview page for a summary of the modules it implements.
You can't use both since they are written for different platforms. If you're designing the system and have the freedom to choose which platform you're implementing in, you can choose either Spring for a Java implementation or Spring.NET for a .NET implementation.
They are slowly getting a bit different, especially with the support for .NET specific things, such as WCF.
If you're going to decide to implement in .NET/Java I would take more into account than simple Spring/Spring.NET.
Spring is the original Java version and Spring.NET is a .NET version. Spring is better, as the .NET port is not as good as the original. For .NET, you are better of with Castle Windsor. The best thing is to use none of the dependency injection containers because dependency injection is not a good design pattern to follow. Neither is MVC. Java has many differences from .NET. .NET has advantage of Web Forms over Java. If you are using .NET, use the best UI platform which is Web Forms. If you are using Java use JSF.