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.
Related
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
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.
Our group does not primarily develop in c#/.NET, but a few years ago we picked up a couple of licenses for Visual Studio 2008 for a few projects. Since we do not develop full time in .NET, we have not upgraded Visual Studio since then.
There is a project coming where we need to develop a web application that contains a REST API. We have been looking at all of the documentation that deals with creating REST APIs. It appears that while VS 2008 is capable of creating APIs (with WCF), later versions of Visual Studio seem to have much better support for creating REST APIs (ASP.Net Web API).
My questions are:
Would upgrading to Visual Studio 2012 or 2013 make that much of a difference in the development/maintenance of an API, or is Visual Studio 2008 sufficient?
How can we go about justifying an upgrade in our Visual Studio licenses (if needed)?
We don't want to justify an upgrade by just saying "it is newer so it is better". Are there any documents that show how Visual Studio 2012 or 2013 is much better at creating REST APIs than Visual Studio 2008?
Not sure if is enough to justify the money but here are some reasons to adopt Visual Studio 2013:
With Visual Studio 2008 you are restricted to .NET Framework 3.5 or lower. If you upgrade you have access to 4.0, 4.5 and future 5.0
If you use Framework 4.5 you can use new REST API Framework.
You can use latest versions of MVC.
You can use latest Microsoft Entity Framework versions (old version can be used in Framework 3.5.1 but you really want the latest version as it has important performance improvement)
You can benefit from ASP.NET WebAPI.
WCF was a way of improving web services, but not the best one. I would avoid WCF if possible.
What is Web API?
ASP.NET Web API is a framework for building web APIs on top of the .NET Framework. You can use the new MVC4 (ASP.NET MVC 4 Web Application project)
using Web API template.
You can actually get Visual Studio 2013 express for free and build all the web API's you'd like. The paid versions include lots of enterprise features and plugin support.
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
For me, it will always be a factor of the business side of things. If they see the value, it is an easy sell.
If using Framework 4.5.1 (VS2013 required) will reduce both the server resources
(See:
ASP.NET application suspend
Just-In-Time (JIT) performance of 15%
"The .NET Framework 4.5 and Windows 8 introduce features that can help you achieve a significant performance boost for web-server workloads. This includes a reduction (up to 35%) in both startup time and in the memory footprint of web hosting sites that use ASP.NET."
)
AND bandwidth resources
(SEE:
.NET 4.5 and WCF Request Compression
http://www.topwcftutorials.net/2014/03/whats-new-in-wcf-v45.html under Compress and Cache
),
then one can actually do the maths and see if it makes sense already. Then, the developer and maintenance side (which is quite "neat" in Vs2013 - new intellisense, nice nuget, etc.), is just jam. From a developer point of view, you will also need to consider the cost to upgrade the application between versions, i.e. the cost from 2008 to vNext vs. 2013 to vNext.
Update:
As this is a very similar situation I find myself in, I have been doing some research. Our company standards is VS2012 (RE: Microsoft Dynamics environment).
According to "What's New in the .NET Framework 4.5, 4.5.1, and 4.5.2" at http://msdn.microsoft.com/en-us/library/ms171868(v=vs.110).aspx they suggest the following for your domain specific improvements:
•Ability to support multiple authentication modes on a single WCF endpoint when using the HTTP transport and transport security.
This is always a big seller for business. Please look at the other improvements under WCF at the link above.
I have also found an article at http://www.msmsoftware.com/2013/8/6/the-business-benefits-of-upgrading-net-35-to-45.aspx that is very specifically aimed at your question. They note, as I said, better performance, better security and increase development and support functions.
Your question is unique in that it targets the work side of things (WCF), so the fluff around better support for app stores, better web standards, etc. is somewhat pointless. Hopefully I have given you enough to make the answer somewhat clear.
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.