I've been asked to take an existing fairly large (150 page) database driven site that was written in ASP classic and upgrade it to .net 5 or .net 6.
Are there any reliable tools available to make this process not a nightmare?
Would a complete rewrite in .net 5/6 or php be a better solution?
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.
I am mostly interested in the unified Web API in MVC 6 for building restful services. However I am a bit confused at the moment on how these components fit together. When building a new app with the latest Visual Studio 2015, MVC 6 is available as an ASP.NET 5 template. My understanding is that ASP.NET 5 is now ASP.NET Core 1.0. What does this mean for MVC 6 and how will it be supported in the future? Will it be part of the ASP.NET Core 1.0, ASP.NET 4.6 or both?
Could someone please explain how these components fit together? Thanks!
ASP.NET Core is the unification of MVC and WebApi.
It can run on the .NET Core framework or on the .NET full desktop framework.
The MVC design pattern is still there but there is less reason to call it "MVC" when talking about it. In the old days we talked about "MVC" to distinguish it from other things like WebForms or WebPages, but ASP.NET Core doesn't have those other things so calling it "MVC" is not really necessary. It was earlier called "MVC 6" but that was before everything got renamed to ASP.NET Core.
You can find a good explanation here: ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0
In few words:
ASP.NET 4.6 is the newest version of the ASP.NET we have known so far. This version is available right now.
ASP.NET 5 was going to be the name of something that wasn't a newer version of the ASP.NET we've used so far. SO Microsoft decided to rename it as ASP.NET Core
MVC 6 was the name of the MVC included in ASP.NET 5, so this name no longer make sense
One of the characteristics of ASP.NET Core is that, as you're asking, the MVC and Web API controllers are unified (which aren't on ASP.NET 4.6). But another very interesting thing is that ASP.NET Core runs on OSX, Linux and Windows, and there are available tools to develop thiskind of projects on these 3 platforms.
ASP.NET Core runs on .NET Core (previously named .NET 5), which is a "reduced" version of the .NET CLR that runs on OSX, Linux and Windows.
ASP.NET Core is already incomplete: it doesn't include SignalR or Web Pages so far, but it expected in the future.
Officially, it's supported. I get that. I've personally done it in a VM. My question is, are there any hidden gotchas of running VS2012.x side by side with VS2010 SP'd and hotfix'd? I recall reading about an issue with the version of .NET or the CLR, I don't recall the details and it was last fall.
My coworkers and I would really like to move to 2012 but we have a lead developer that refuses to move. We need to convince him, especially since we have a large project that was started on 3.5, moved to 4.0 (will not go to 4.5), but we've heard rumblings about the aforementioned possible problem.
.NET Framework 4.5 is an in-place update. This means that once you install it all apps (including VS 2010) will be running against .NET Framework 4.5 and not .NET Framework 4. While there has been a great effort to make .NET Framework 4.5 backwards compatible there are some (mostly minor) bugs where the behavior changed in .NET Framework 4.
I think the biggest thing you should consider is whether you are going to target .NET Framework 4 in your apps. The problem is that when you target .NET Framework 4 your VS2012 will only allow you to use APIs that as they were in .NET Framework 4 but your app will actually run using .NET Framework 4.5 runtime. I have seen cases where a legitimate bug in .NET Framework 4.5 was fixed (i.e. an incorrect exception is no longer thrown) but when you run your app against real .NET Framework 4 the app did not work even though it targeted .NET Framework 4 because the bug is still there. Note that you can get to the same situation even with VS 2010 if you install .NET Framework 4.5 on your box. I have been running both SxS and I have not had any problems (but am primarily using VS2012 - is so much faster and more stable).
I think the main take aways here are
if you are working on .NET Framework 4 make sure you test your app on real .NET Framework 4
try running VS2012 sxs with VS2010 on a limited set of machines and if you don't see any problem move on
you may also try running VS2012 only if you don't use any functionality that is not supported in VS2012 (the biggest risk in this case is the .NET Framework anyway and running VS2010 only will not protect you anyways)
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.