I am currently using .NET 1.1 but my client wants to move application from .NET 1.1 to .NET3.5.
So client wants know how they will be benifited if migrate from 1.1 to 3.5.
What are the benifits of 3.5 over 1.1 for clients who is using that application?
With every version upgrade in .NET there's a bunch of new features these features might be language / compiler enhancements which are not visually regocnizable by the end user.
However these features makes it easier for the developer to create solid and manageable applications, then one might wonder; What is really benefiting the end user?
If it is easier for you to create readable code that is much easier to test and quality ensure, then it will most likely benefit the end user.
It's also become much easier to create trivial things in later .NET versions which will save you some development time which benefits the client of yours.
From a developers perspective there are a handfull of reasons why you should use .NET 2.0+ instead of 1.1 and all these reasons will in the end most likely give you a more trustworthy application which is to more value for your client.
it's a higher number? :-)
no serious, i think as long as you don't implement new features, the upgrade vom 1.1 to 3.5 will bring him few benefits. some security updates are included, and he will can deploy also asp.net-mvc applications on the same server.
but i don't see any great advantages for clients.
cheers
Migrating from 1.1 to 2.0 (and higher) is a must.
The most obvious benefit I see on top of my head, without much thinking is the use of generics which was introduced by the CLR 2.
And don't forget support for 1.1 has simply ended, see here: .NET 1.1 mainstream support ended in 2008
So the question would better be "what are the risks"? Here is a document on this subject: Microsoft .NET Framework 1.1 and 2.0 Compatibility.
Related
Is it safe to have a .NET6 application which references a .NET Core 3.1 NuGet library?
I tested this case using a simple console application. Everything looks good and there are no errors/warning. However, I haven't found any specific information so prefer to make sure.
This is important, as one of my providers offers only a .NET Core 3.1 NuGet package. Knowing the company it'll take them a year or so to prepare a .NET6 / .NETStandard version.
There is a good chance that your .NET Core 3.1 library will run without any compatibility problems as part of your .NET 6 application.
Quoting the .NET fundamentals article Changes that affect compatibility (emphasis mine):
Throughout its history, .NET has attempted to maintain a high level of
compatibility from version to version and across implementations of
.NET. …
Along with compatibility across .NET implementations, developers
expect a high level of compatibility across versions of a given
implementation of .NET. In particular, code written for an earlier
version of .NET Core should run seamlessly on .NET 5 or a later
version. In fact, many developers expect that the new APIs found in
newly released versions of .NET should also be compatible with the
pre-release versions in which those APIs were introduced.
However, compatibility is not guaranteed. The article goes on to say:
This article outlines changes that affect compatibility and the
way in which the .NET team evaluates each type of change.
Understanding how the .NET team approaches possible breaking
changes is particularly helpful for developers who open pull
requests that modify the behavior of existing .NET APIs.
Furthermore, in an answer to the question Clarification on backwards compatibility of .NET Core, a member of the .NET runtime team says:
We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We
intentionally make breaking changes where we believe that they are
necessary to move the platform forward and the cost of the .NET
ecosystem adjusting to them is low enough.
Breaking changes that could potentially affect the compatibility of your .NET Core 3.1 library are those that are documented for .NET 5 and .NET 6.
But, if you are not experiencing any problems with your .NET Core 3.1 library, it would appear that none of the documented compatibility problems apply.
Ultimately, of course, you'll have a higher degree of confidence in the library when your vendor provides one that has been updated for .NET 6.
Finally, with the introduction of .NET 5, there became a lesser need for .NET Standard:
.NET Standard is a formal specification of .NET APIs that are
available on multiple .NET implementations. The motivation behind .NET
Standard was to establish greater uniformity in the .NET ecosystem.
.NET 5 and later versions adopt a different approach to establishing uniformity that eliminates the need for .NET Standard in most
scenarios. However, if you want to share code between .NET Framework
and any other .NET implementation, such as .NET Core, your library
should target .NET Standard 2.0. No new versions of .NET Standard will
be released, but .NET 5, .NET 6, and all future versions will continue
to support .NET Standard 2.1 and earlier.
I have an application written in ASP.NET 1.1. If I switch IIS to use 2.0 what issues am I likely to see? Initial tests have thrown no problems, but I was wondering if anyone had experience of running ASP.NET 1.1 applications under 2.0 and could maybe point out some areas to watch out for?
Thanks for any advice.
Just make sure that you are not running different web applications in the same application pool if they require different versions of the .NET framework.
Create separate app pools (at least one for each version of the framework).
Maybe also have a look at this blog post by Brad Abrams about breaking changes between .NET framework 1.1 and 2.0. Here's a short quote :
...we work very hard to ensure that
your V1.1 apps will this just work on
2.0, but none-the-less, this doc is likely worth a quick scan as you
migrate to 2.0
When we migrated our 1.1 applications to 2.0, I don't think we had any problems. There were a handful of cases where the compiler warned us that we should use a different (updated) assembly, but other than that everything was fine.
Most ASP.NET 1.1 applications will run just fine under ASP.NET 2.0. One thing to watch though is that you don't run an ASP.NET 1.1 and an ASP.NET 2.0 application in the same application pool.
The biggest problem we had was connected with the insertion of the xhtmlConformance element in the web.config file connected with javascript libraries, removing it worked fine for us
check this post from Scott Gu.
Usually asp.net 1.1 application migration to 2.0 does not raise any issues. You might need to change the location where you put the class files.
You will see some warnings, some deprecated method call etc.
We are migrating many ASP.NET 1.1 web applications to new servers. We would like to convert all of them to 2.0 in the process. Ideally, in the end, the 1.1 framework will not even be installed on the new servers. We've never had major issues converting applications to 2.0 from 1.1. Our biggest issue has always been changing ConfigurationSettings.AppSettings to ConfigurationManager.AppSettings.
Has anyone else ever had major issues?
Are there any major things to look out for or consider up front?
Here is a good resource on how to convert asp.net applications from 1.1 to 2.0 using visual studio 2005.
Converting an ASP.NET Website from Version 1.1 to 2.0
Edit: Here is the MSDN step by step guide for converting apps:
http://msdn.microsoft.com/en-us/library/aa479567.aspx
When converting to 2.0 the only major issue I've run across was performance of compiled Regexes got much worse the way we were using it. Switching it to use the static Regex.Replace() method solved much of the problems.
I can't find the article that I found this in back then, but if I do I'll add it to this post.
The bottom line is make sure you test it not just for functional equivalence but for performance too.
The biggest problem I've seen is that the new default is to use Web Site "projects". This should not be a problem if you're running Visual Studio 2005 SP1, where they corrected this problem.
I also had some odd problem that I think may have involved the vwd.webinfo file. Our web service application worked perfectly on my computer, but on the build server, it tried to become a web site "project", so it didn't compile. No compile == no symbols.
I know we are really behind the times here, but we are just about to upgrade from .NET 1.1 to .NET 2.0.
Thank you for your sympathy.
Anyhow, are there any gotchas we should look out for?
Do you have any general advice before we jump in?
Please do not post telling me to go straight to 3.5: 2.0 is all we're allowed!
We're using mostly C#.
Yes. The most important thing for you to know is to use a Web Application Project, not a Web Site. Web Sites use a totally different compilation model and migration is pretty much a disaster. Web Application Projects are much more similar to how things worked in 1.1.
We also had an intermittent problem with redirecting from the login screen, but according to Google, we were basically the only ones who had that problem - we've since resolved it.
Most of the other problems we ran into were small and easy to navigate, and the overall experience was a net improvement.
Here is my recommendation before upgrading:
If you are used to use Visual Studio 2003, you will need to go for VS2005. You will have to convert the old solutions and projects so that it will be compatible with VS2005. Make sure to have a backup of the project you're going to convert so that you can roll back or even use it as source for any modification you may need to the converted projects.
If you're developing web applications using .NET 1.1, make sure that all the virtual directories and applications in the IIS is configured to work with ASP.NET 2.0. You may need also to configure a new Application Pool for your .NET 2.0 applications.
If you're using any third party libraries in your .NET 1.1 projects, you may need to confirm its compatibility with .NET 2.0 projects. Some old libraries used in .NET 1.1 are not compatible with 2.0.
One gotcha is home-grown 1.1 implementations of .NET 2.0 stuff (that was missing in 1.1) like RegistryHandler and so forth. Sometimes your newly-ported 2.0 code will look like it's properly using a 2.0 class when it's really using the home-grown version.
Deployment is another gotcha, if you're upgrading an already-deployed app. You have to switch the .NET version in IIS from 1.1 to 2.0.
I remember we had to change some client scripts, because the way ClientIDs are generated for server controls changed from ASP.NET 1.1 to 2.0.
I don't remember the exact circumstances, but some IDs which previously wer prefixed ctl0_ became ctl00_...
I've just started working on an ASP.NET project which I hope to open source once it gets to a suitable stage. It's basically going to be a library that can be used by existing websites. My preference is to support ASP.NET 2.0 through 3.5, but I wondered how many people I would be leaving out by not supporting ASP.NET 1.1? More specifically, how many people are there still using ASP.NET 1.1 for whom ASP.NET 2.0/3.5 is not an option? If upgrading your server is not an option for you, why not?
Increasingly I think not.
The kind of large rigid organisation currently still clinging to 1.1 (probably because they're only just upgraded to it) is also the kind that's highly unlikely to look at open source solutions.
If I were starting a new ASP.Net project right now I'd stick with .Net 3.5 and probably the new MVC previews.
Remember that .NET 1.1 is going out of general support in October of this year (and that includes ASP.NET 1.1).
I think you would be perfectly fine with targeting just 2.0 and above, someone who would use your library would most likely be doing new development and using at least ASP.NET 2.0. I think it would be a very small group of people doing new development in 1.1.