what are some things i should be aware of before i begin this project? i've notice a few differences between this 1.1 site and our 2.0 sites: i noticed that every code behind file has a "Web Form Designer Generated Code" region which i'm guessing i won't need to transfer over to the 2.0 site.(?) There's also a "sitename".dll file in the bin folder which i was told is also a 1.1 thing and that dll file won't need to be transferred over to the 2.0 site.(?) at this -LINK-, the second answer mentions that my new 2.0 site should be created as a Web Application Project and not a Web Site project - does this apply to all 1.1 to 2.0 upgrades and should i consider doing this?
i would appreciate any advice at all on a 1.1 to 2.0 upgrade that you have. i should also mention that i am not allowed to upgrade to either 3.5 or 4.0 - it has to be 2.0. thanks.
2.0 brought a new project type for websites which, in the simplest terms, does not produce a dll for the website like 1.1 projects would. There was a patch released that supported the 'older' project type if you really hated the new website project (which I did).
To be honest I did not have that much trouble converting my sites over to 2.0 way back when it came out. Visual studio automatically converted my projects and I only had a few bugs to work out to be honest.
Try using the automatic upgrade (simply open the project in visual studio 2005 after you install 2.0) and see if you have any issues.
Be sure to install the latest service packs and be sure to test, test, test. .NET 2.0 added some fixes that amount to breaking changes in .NET 1.1. You may run into them especially in the area of XML processing in general, and XML Serialization in particular.
Note also that .NET 3.5 is nothing more than .NET 2.0 plus some additional assemblies that your code does not use. There is no good reason to not upgrade to .NET 3.5 SP1.
There are potential reasons to not upgrade to .NET 4.0, though not very many.
Related
We have recently taken on support of a web application that was written many years ago and targeted v1.1 of the .net framework. It runs on Windows Server 2003/IIS 6 environment.
After looking at the configuration of the site in IIS the target framework is set to 2.0.
Given that extended support for .net 1.1 will cease in October of this year (http://support.microsoft.com/lifecycle/?p1=1249) I am trying to ascertain whether the site will still use any of the .net 1.1 framework assemblies given that the application is built and compiled in Visual Studio 2003.
I am assuming this is the case because although ASP.net 2 is set as the target framework
in IIS (and therefore the aspet_isapi.dll invoked is the .net 2 one etc) the assembly is a .net 1.1 assembly and will therefore still use the 1.1 framework. However, is this assumption actually true?
The website only has another year or so to live before being replaced by a new solution entirely so I would prefer not to upgrade it if possible and run the risks such changes bring with them.
However, we obviously can't run something on an unsupported version of the framework if any element of if that framework is actually being used.
Any thoughts would be appreciated.
Update:
It would seem that .net 1.1 is a core component of WS2k3 so you can't just uninstall it. I could have attempted to remove the ASP.net component but I don't think that would fully uninstall everything and given that the dev environment is shared I can't risk causing any issues right now.
However I have previously set everything up on my local machine (Windows 7/IIS 7), so I changed the application pool to point at .net 2 (it was already running in classic pipeline mode), uninstalled .net frameworks 1 and 1.1 and cleaned up the files left behind afterwards.
The result was that the site ran absolutely fine, which would suggest in an IIS 7 environment at least that I don't need to worry about upgrading given we are running under .net 2 within IIS.
It's not an ideal test as it isn't a mimick of our live environment. I'm going to post a question on MSDN and asp.net to see if any Microsoft folks can add anything more definitive. I will post back here with any updates.
Just because official support will end doesn't mean Microsoft will pull the plug and force an uninstall of .NET 1.1 via Windows Update. It only means that:
if a gaping hole in the framework's security is ever found, they'll not fix it;
There won't be redistributables for the next versions of Windows, and the next version of IIS won't run it.
So the application will still run in a year. If you leave the server alone, the application might run until the machine breaks of old age.
So my suggestion is relax, and focus more on the new solution.
I got the answer to this questions after reading this link (provided as an answer to this question on the ASP.net forums)
http://msdn.microsoft.com/en-us/library/ms994381.aspx
Under "Application Load Mechanisms and Possible Issues" it states:
By default, an application built using the .NET Framework will run using the version of the Framework it was built against if that version is installed on the computer
It then goes on to detail (for .net 1.1 and 2.0 at least) when a particular version of the framework is used.
Essentially, because our server has both 1.1 and 2.0 installed the application will still be using version 1.1. If 1.1 was not installed then it would run by default under 2.0, which explains why the web application still worked after I uninstalled .net 1.0 and 1.1 from my local machine.
Given that the live server is W2K3 and I can't remove .net 1.1, I will be rebuilding my application to target .net 4.0.
Just converted my .net 1.1 code to .net 3.5 for my vb.net web app using Visual Studio 2008.
I've just compared the old version to the new, and- apart from changing has every references to the Global.asax file changed from Global to [Global] (why!?)- the code itself doesn't seem to have changed at all.
Yet the convertor creates backups for every file, which leads me to believe it can sometimes make significant changes.
So what exactly does the convertor look for, and what can it actually change?
.NET 3.5 is basically .NET 2.0 with "some" new classes and a new C#/VB.NET compiler, therefore it is interesting what breaking changes there are between .NET 1.1 and .NET 2.0. You can find them here.
We have a web application that runs on IIS using .NET 2.0 developed and built with Visual Studio 2005.
We're going to upgrade to .NET 3.5 and begin using Visual Studio 2008. Here are my questions:
I note the runtime is still 2.0-based.
When I loaded the solution in Visual Studio 2008, I was asked to convert, and I did. I then checked the target framework for the default project, and it was set to 3.5. However, all of the other target frameworks for the other projects are set to 2.0.
Do I need to manually set the target frameworks from 2.0 to 3.5 for each of the projects in the solution?
Are there any "gotcha's" anyone can think of to be concerned with a web-application conversion?
As I understand it, the 1.1 to 2.0 migration was a much more difficult issue due to the massive runtime and web-page design changes. However, 2.0 to 3.5 isn't such a big change.
I was not at my current job for that upgrade, but I understand there was a problem with some textarea tags using a deprecated attribute that failed to function correctly after the upgrade.
Can anyone think of any similar issues I might encounter?
Any other issues or thoughts anyone has after having done such a conversion themselves?
Thanks, I appreciate the input.
---Dan---
Do I need to manually set the target
frameworks from 2.0 to 3.5 for each of
the projects in the solution?
Not necessary, but I would recommend you to do so. Visual Studio actually filters the assemblies you can reference based on the target framework version.
Are there any "gotcha's" anyone can
think of to be concerned with a
web-application conversion?
Not any that I am aware of when migrating from 2.0 to 3.5. You don't even need to modify the CLR version of the host application pool. When you need to migrate to 4.0 there might be more issues.
If you're also upgrading your own target server, from my own experiences, be patient with the installer.
It does quite a lot including uninstalling the existing .NET 2.0 and 3.0 frameworks and replacing it pretty much wholesale.
It can look as if the installer is stuck. On one of our production servers it ran for nearly 20 minutes. I was almost ready to pull the plug then it magically jumped into life.
I currently have an ASP.net 2.0 site with multiple ASP.Net 1.1 sites running as Virtual Directories under the main 2.0 site. While this creates some problems with web.config entries inheritance from the 2.0 site to the 1.1 sites, we have been able to configure all the sites so they work. However, we are now getting ready to migrate the 1.1 sites to 3.5. Unfortunately, due to bureaucracy out of my control, we can't upgrade the main 2.0 site, yet. I wanted to make sure that there wouldn't be any issues with simply upgrading the child virtual directories to 3.5.
My initial guess is that this would be fine since 3.5 uses the same runtime as 2.0, however, I'm wondering if there are any major differences in the web.config items in 3.5 that might conflict with 2.0 items.
Does anyone have any insight?
we did this and, as pointed out, it is mainly inheritence in the web.config (aspecially if you use the AJAXControl toolkit as 3.5 and 2.0 are different versions). Once you have those resolved the sites should be fine.
I don't think there are any major differences that would cause you a problem as ASP.NET 3.5 web sites are only ever indicated to be 2.0 sites and it'll be the 2.0 runtime reading the web.config I believe.
You should also note that you cannot mix .NET versions in IIS application pools. So you cannot use the same application pool for .NET 1.1 and .NET 2.0+ web applications.
If at all possible you should set up the same situation on a staging server, test the migration, document each step and the troubleshooting steps you take, if any, to get things working. Then you don't have to guess. :)
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_...