I am trying to get an ASP.NET 3.5 site to run on a Windows 2000 machine (not my idea!!!) but am having some problems. I have been working through copying required DLL files from C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5 into my app bin directory. This succesfully got me past the "assembly not found" errors.
However, I am now getting the following error.
Compiler executable file csc.exe cannot be found"
How can I fix this? It is primarily LINQ functionality I am looking to utilise.
You are going to have many issues as .NET 3.5 is not supported on Windows 2000 (see System Requirements).
You can try to install .NET Framework 3.5 manually. It relies on .NET 2.0 runtime + some extra stuff.
See Microsoft .NET Framework 3.5 in
Windows
2000
for install steps.
See also More details on installing
.NET 3.5 in Windows
2000
for explanations.
Install a Virtual Machine with a newer Windows in it ;-)
Many 3.5 sites will work just fine in 2.0, you just need to compile them that way. I would have whoever built the app switch to 2.0 targets and see how it goes. If that doesn't take, the VM option is probably the best way to fly.
Save yourself some time and pain, install on a platform that supports 3.5.
Trying to circumvent minimum requirements usually comes back to bite you in the end.
Just because you can doesn't always mean you should. :)
Unfamiliar with the environment, but...
More of the framework (including csc.exe) resides in %WINDIR%\Microsoft.NET\Framework\v3.5 (e.g. C:\WINNT\Microsoft.NET\Framework\v3.5) - are these files on your installation and the directory in your path?
Related
I hate to ask a question that seems like it should be easy to find the answer to on the web, however I am unable to find a straightforward answer anywhere as to how to check what version of ASP.NET is installed on my Windows Server 2008 r2. Any help with this would be much appreciated. Kind regards, Jon
Read registry key, HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ as documented in
https://learn.microsoft.com/en-us/iis/install/installing-iis-7/discover-installed-components
As you use IIS 7, its "ASP.NET" feature matches ASP.NET 3.5 you are looking for. If you want to check ASP.NET 4.x, then this approach won't work.
Generally speaking, the ASP.NET component in IIS wraps over aspnet_regiis command line tool to register ASP.NET bits on IIS (ISAPI and so on). Microsoft designed it this way so it felt more natural. However, it turns out to be a disaster later, as .NET Framework new releases can easily break the design.
For example, on IIS 7 if you use ASP.NET 4.x then you have to manually run aspnet_regiis from .NET Framework 4.x installation folder, as there is not ASP.NET 4.x component on IIS 7.
You can go to
C:\windows\Microsoft.NET\Framework
and check if there is v3.5 folder
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.
I'm trying to run any application on XSP4 web server using new Mono 2.10 (downloaded from windows installer bundle). I have already tried to run simple ASP.NET MVC2 project and ASP.NET. Both were simple applications stubs. In all cases in browser under localhost:XXXX it seems that page is loading but nothing happens. With Mono 2.8 it works without any problems. Any suggestions how I can debug or solve this problem?
PS. My windows firewall is turned off so it shouldn't be problem.
The latest MonoDevelop Beta, 2.6b1, contains an updated XSP4 and Mono.WebServer.XSP (aliased as MonoDevelop.Xsp.dll in this distribution, and from my experience must be placed in the GAC for it to work) which fixes this issue on 2.10.
A good place to ask questions regarding ASP.NET using Mono is Mono ASP.NET list
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.
Are there any issues with running an asp.net 1.1 application under windows server 2008 64-bit web edition?
I have never tried it myself, but I did find the following pages that you might find interesting:
This blog has an in depth walk through of configuring ASP.NET 1.1 on Windows Server 2008. The author does not say if it is x86 or x64, so I would just assume its x86. But either way, it looks like the author had to jump through some hoops to get the ISAPI filter setup correctly.
I also found this thread on the IIS7 forums where someone discuses having poor performance from ASP.NET 1.1. on x64 Win2k8. So from poor performance I would assume it worked to some extent. Unfortunately towards the end of the thread the author mentions encounter 500 errors, and then the discuss stops :-(
So from what I've read I would guess that its possible, but I would also guess that you would have less hassle if you could find some alternative that didn't involve both II7 and x64.
I have recently been testing our application on 64 bit 2008. Our application is .net framework 3.5 but we had a few problems.
The main issue we had was with 3rd party components such as Aspose words which were not built for 64 bit and caused an error. Unfortunatly you wont know without trying it..
.NET 1.1 is 32 bit only hence the app pool would have to run as 32 bit and use the classic pipeline. I haven't tried myself and I would do all that I can to not have to install .NET 1.1 on a 2008 server but it should work.
No problem. Just follow intructions on
http://learn.iis.net/page.aspx/472/how-to-install-aspnet-11-with-iis7-on-vista-and-windows-2008/
The option "CGI Restrictions" (last step) is found on IIS7 admin by clicking on the machine name.
I'm pretty sure that the article at http://learn.iis.net/page.aspx/472/how-to-install-aspnet-11-with-iis7-on-vista-and-windows-2008/ is for NON-R2 versions of Windows Server.
As far as I know ASP.NET 1.1 cannot run (or at least, not run well) on Windows.
There are some band-aid solutions around that various people have posted / blogged but this isn't supported by Microsoft.