We are maintaining an internal organizational administration system written (sadly) in ASP.NET 3.5. We have recently been asked to add password management capabilities to the system, which seemed like a perfect fit for the password management features of ASP.NET Identity.
My question is, can we use ASP.NET Identity in our system, having it being written in ASP.NET 3.5?
If so, what is required to do it?
If not, are there any alternatives? We only need the password-related stuff, like length, special characters, prevent reuse of previous, say, 3 password etc.
Cheers,
ashilon
ASP.NET Identity framework is collection of nuget packages (DLL's) and the Runtime Version (minimum supporting .NET Framework) is v4.0.30319.
So that you could not be able to use ASP.NET identity framework on ASP.NET 3.5 which is .NET Framework 3.5.
Following packages using Runtime Version v4.0.30319
Microsoft.AspNet.Identity.Core
Microsoft.AspNet.Identity.EntityFramework
Microsoft.AspNet.Identity.Owin
You could upgrade your project to support .NET Framework 4.0 or above and then you could be able to use asp.net identity framework.
Related
At work, we have an Old application developed with the following technologies:
Visual Studio 2010 Ultimate
.NET Framework 4
C# 4.0
ASP.NET WebForms
With our application we are Highly concerned with issues like:
-security,
-links,
-and users sessions.
We have some new software requirements features which in turn means that we have to add to the existing application.
We would like to use newer Microsoft .NET technologies for the new features.
However, we are concerned about compatibility problems. We have Visual Studio 2019, and we would like to develop the new features using Visual Studio 2019.
But, how far can we go before we have compatibility problems, and face other kinds of limitations?
Is it possible to successfully bridge the Old application with newer technologies like:
-.NET Core Web API
-.NET Core MVC
-.NET Core Razor Pages?
Again, we can Not compromise on the following:
-security
-links
-and users sessions
Yes, you can use both .net framework application and .net core application inside single hosted application. Same thing i have done in one of my project. old project was in .net framework 4.5 and we wanted to build new features in .net core with web api.
We did and integrate both application inside a single application which is hosted on IIS server.
In term of security and sessions , .net core provide more control over these things.
Let me know if you need more help of info.
We currently have a web api targeting .NET 4 framework which is hosted within IIS using an application pool which is using .NET 4 CLR.
We are investigating migrating the web api from .NET 4 to .NET Core 2.1 (for performance improvements). The web api has other DLL references which have been built using .NET 4 framework. I have a simple proof of concept up and running using .NET Core 2.1 and the references which had been built using .NET 4 framework appear to have imported fine as I can reference them and the project builds.
If I have the new .NET Core 2.1 web api referencing the 3rd party DLLs using .NET framework 4 which is then going to be hosted in IIS using the CLR 4... how would we see any performance increase? If everything is being run using the CLR 4, is that not the bottleneck for performance? Or is it the binaries that the CLR reads being more performant where you will see better performance?
Any guidance would be greatly appreciated as I'm very confused at the moment!
Thanks
It depends on how you're handling things. .NET Core 2.0+ fully supports .NET Standard 2.0, which has an API footprint large enough to cover most .NET Framework functionality. As a result, the compiler will let you add a .NET Framework library reference to a project that's actually targeting .NET Core 2.0+. There's no guarantee that the library will actually work (and you get a warning to that effect), but unless it's using Windows-specific APIs, there's a very good chance it will function fine.
Assuming this is the case with your .NET Framework libraries and you're actually targeting something like .NET Core 2.1, then you are not in fact using .NET Framework, and you don't even need .NET Framework installed on the server you're deploying to. All the requisite framework dependencies will come from the .NET Core runtime, or can even be packaged along with your app if you opt for a self-contained deployment. In that case, once compiled, it's virtually inconsequential that the libraries you referenced actually targeted .NET Framework.
If however the libraries do not work without full .NET Framework, you can still build a .NET Core app, but you'll be forced to continue to target .NET Framework, rather than .NET Core. In that case, you will of course be reliant on the .NET Framework CLR, with the performance drain that entails. That said, an ASP.NET Core app, for example, is still generally more performant than something like an ASP.NET MVC app, so you will get some gains - just not as much as if you were actually targeting .NET Core.
Regardless of what you ultimately end up targeting, your app is actually served via Kestrel. IIS acts merely as a reverse proxy.
Does ASP.Net Core 1.0 support .Net WebForm projects? Or it is an MVC only environment? Also can I create classic web services(asmx) there?
Short answer: No, ASP.NET Core does not contain Web Forms or Web Services.
Long answer:
Depends on your meaning of "support". If you aim to run ASP.NET Core project on top of CoreCLR and CoreFX, then the answer is no: ASP.NET Core will contain support only for MVC ja Web API -projects (which are the same thing in ASP.NET Core).
If you can run on full .NET Framework, then ASP.NET Web Forms can co-exist with ASP.NET Core. The Web Forms will be the same Web Forms they are today on System.Web. In this scenario you would host your web forms in a different project (normal ASP.NET 4.x application) on IIS and ASP.NET Core would live in it's own application on Kestrel.
A need to use .NET technologies not available for .NET Core
Some .NET Framework technologies are not available in .NET Core. Some of them will be available in later .NET Core releases, but others don’t apply to the new application patterns targeted by .NET Core and may never be available. The following list shows the most common technologies not found in .NET Core 1.0:
ASP.NET Web Forms applications: ASP.NET Web Forms is only available on the .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Currently there are no plans to bring ASP.NET Web Forms to .NET Core.
ASP.NET Web Pages applications: ASP.NET Web Pages are not included in ASP.NET Core 1.0, although it is planned to be included in a future release as explained in the .NET Core roadmap.
ASP.NET SignalR server/client implementation. At .NET Core 1.0 release timeframe (June 2016), ASP.NET SignalR is not available for ASP.NET Core (neither client or server), although it is planned to be included in a future release as explained in the .NET Core roadmap. Preview state is available at the Server-side and Client Library GitHub repositories.
WCF services implementation. Even when there’s a WCF-Client library to consume WCF services from .NET Core, as of June 2016, WCF server implementation is only available on the .NET Framework. This scenario is not part of the current plan for .NET Core but it’s being considered for the future.
Workflow related services: Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service) and WCF Data Services (formerly known as “ADO.NET Data Services”) are only available on the .NET Framework and there are no plans to bring them to .NET Core.
Language support: Visual Basic and F# don’t currently have tooling support .NET Core, but both will be supported in Visual Studio 2017 and later versions of Visual Studio.
source Choosing between .net Core and .net Framework
when right click the property of the project in vs2010, what's the difference of the target framework with or without client profile?
thanks.
The client profile is a subset of the complete .NET 4 framework, aimed at client side applications. It allows users to have a smaller download and install, leaving out the bits they wouldn't normally use.
However depending upon your application, and which bits of the framework you want to use, you may need the complete version and not the client. For example if you want to access the Membership provider stuff from a WinForms app you'll need the full and not client.
See this for more info:
Differences between Microsoft .NET 4.0 full Framework and Client Profile
In Visual Studio 2008, the target framework settings for a project are
.NET Framework 2.0
.NET Framework 3.0
.NET Framework 3.5
However, in Visual Studio 2010 they are
.NET Framework 2.0
.NET Framework 3.0
.NET Framework 3.5
.NET Framework 3.5 Client Profile
.NET Framework 4
.NET Framework 4 Client Profile
What do the Client Profile settings mean?
Edit
A little more experimentation shows that with MVC, WebForms and WCF projects you don't get the Client Profile options. When creating WinForms and Console applications, the default target framework is .NET 4 Client Profile. Which makes sense.
The client profile is a smaller version of the full .NET framework that contains only the more commonly used content. Scott wrote a nice post about this. Here and here is an official introduction.
The client profile was added recently, so VS 2008 does not know about it yet. The client profile is one of the major features that come with .NET 4 and VS 2010. Since the Client Profile is a subset of the full .NET 4 framework, you don't need to install it if you already got the full .NET 4.
It can be an advantage to develop against the Client Profile since it exists on more machines than the full framework (and it is smaller in download size for your customers).
The disadvantage that comes along naturally - it does not include everything. If you are developing a server application or a program that uses uncommon parts of the framework, you'll need the full framework in any case. Typical client programs, however, are likely satisfied with the Client Profile.
The Client Profiles are smaller, more compact versions of the .Net Framework. More info here.
It is a subset of the .NET framework for CLIENT applications (i.e. applications installed on the client computer).
As such, they do not incorporate server technologies. THis allows the client download to only install a smaller part.
Server technologies are for example ASP.NET.
Using ".net client profile" as search on Google, first link leads to http://msdn.microsoft.com/en-us/library/cc656912.aspx which has a detailed explanation.
Also the local .NET documentation (F1 - I hope you are aware this exists) has the same content.