I am migrating a project from .Net framework 4.8 to .Net Core 3.1.
The problem is that this Basic256 algorithm is not compatible with Net Core
SecurityAlgorithmSuite.Basic256Sha256Rsa15
Do you know any equivalent libraries?
These security algorithms are used to ensure the security of the WCF message layer. As far as I know, the WCF server cannot be created in DotNet Core, and the WCF client based on DotNet Core is only a compatible solution, especially the message layer security has not been implemented, let alone these algorithms.
Please refer to the official repository and discussion.
https://github.com/dotnet/wcf
https://github.com/dotnet/wcf/issues?utf8=%E2%9C%93&q=SecurityAlgorithmSuite+
Feel free to let me know if there is anything I can help with.
Related
I am writing integrations tests for my .NET web applications right now. It is going well in general. I found clear documentation that explains how to do this. For example, I am using WebApplicationFactory with .NET Core to test my ASP .NET Core projects. I also wrote integration tests for my WCF applications. This is how I did it. In all these situations, I was able test without starting the applications and measure the code coverage in Visual Studio.
However, for my .NET Framework projects (MVC 5 en Web Api 2), it is not clear to me how to do similar integration tests for like I wrote for .NET Core and WCF. I found a test Framework but unfortunately that does not target recent versions Web Api and it has not been maintained for years. Moreover, it is also not stable when using MVC 5. So what to do now? I just need similar tests for my ASP .NET web applications too. How to make such tests?
My tests need to work on a machine with windows with .NET Framework. So I don't need any explanations for .NET Core.
The .NET framework equivalent to the WebApplicationFactory is the Owin Test server.
You have to install the NuGet package Microsoft.Owin.Testing
using (var server = TestServer.Create<OwinStartup>()){
using (var client = new HttpClient(server.Handler))
{
//Make API Calls here
}
}
There is a good example here https://blog.jcorioland.io/archives/2014/04/01/using-owin-to-test-your-web-api-controllers.html
I am reading an ebook about Docker and Microservices. It referred the .net core was lightweight compared with traditional .net standard.
I don't quite get the story behind it. Can someone give some explanation about this?
This is because .Net Core is optimized for microservices and dockers.
In short, .Net Core doesn't offer as many things as another classic implementation of .Net Standard, reducing its size which even allows for an app to be packaged with all dependencies (and so not needing any installation of .Net on the running machine). This is why I think it could be called lightweight.
See :
https://msdn.microsoft.com/en-us/magazine/mt842506.aspx
https://learn.microsoft.com/en-us/dotnet/standard/choosing-core-framework-server
About light weight of .net core app
I am reading an ebook about Docker and Microservices. It referred the
.net core was lightweight compared with traditional .net standard.
I think here you are referring to .net core is lightweight than .net frameworks as .net standard are just API specifications for implementing base class libraries by different frameworks.
Please refer to below link for more information:
https://www.infoq.com/news/2017/10/dotnet-core-standard-difference/
https://medium.com/wolox-driving-innovation/net-core-vs-net-framework-a694f1fbdb26
Now coming back to why .net core framework is lightweight .net 4.5 or other frameworks as it's modular. When you create or run an application you don't need to install all dependencies which you do not need unlike .net 4.5 or other frameworks where everything is installed.
Basically, .Net framework has been split into individual pieces implemented using CoreFX for .net core framework which makes .Net core lightweight.
Link for details - https://www.tutorialspoint.com/dotnet_core/dotnet_core_managed_extensibility_framework.htm
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225
This is a second attempt with better wording of the problem I'm facing.
I have a simple requirement to implement an application that will allow web applications and standalone services that will be claims-aware (using ADFS). Note that I am talking about windows services in addition to web applications.
Which enabling interoperable technologies should a developer pick?
For the life of me, I can't find a resource that says: to build a claims-aware application using the latest upcoming frameworks, install these packages.
From a framework point of view, I am talking about the following:
Microsoft.IdentityModel
Microsoft.Owin
System.IdentityModel
Microsoft.Asp.Net.Identity
Which should I be using? Alpha / Beta packages are fine.
Thank you,
Richard
in .net 4.5 IdentityModel is now part of the core libraries (so it no longer called Microsoft.IdentityModel).
So for your system you would need the following:
System.IdentityModel for the FederationAuthenticationModule (which intercepts and verifies your SAML token submission) and for the SessionAuthenticationModule (which serializes/deserializes your claims.)
To create the claims that you will send between your applciations you would use:
System.Security.Claims
as I mentioned these are both in .net 4.5.
Microsoft.IdentityModel is the one you are looking for.
Microsoft.IdentityModel.Claims for IClaimsIdentity interface.
Microsoft.IdentityModel.Web for WSFederationAuthenticationModule.
Yup - System.IdentityModel is the way to go.
Refer: What's New in Windows Identity Foundation 4.5.
If you are wondering what the difference between WIF 3.5 and 4.5 is, refer:
Guidelines for Migrating an Application Built Using WIF 3.5 to WIF 4.5
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.