One of my Websites is on a Shared Hosting Provider, running either .net 2.0 or .net 3.0, but not 3.5 SP1.
I wonder if it would be possible to still use 3.5 SP1 by simply deploying all the 3.5 assemblies into the /bin Folder, since technically it's all still the 2.0 CLR.
I know that if my Host ever updates I have to remove them or else weird stuff can happen, and that I am driving into Unsupported-Territory at full speed, but is there any really big road sign that says "DON'T DO IT!" or even "That is not possible because of X"?
Primary reason is because I want to use ASP.net MVC and possibly ADO.net Entity Framework, but I do not want to make a contract with yet another Hosting provider.
Thanks!
In theory it can be achieved, but it's definately not recommended.
Scott Hanselman did a post on how to run ASP.NET MVC onto a server with other .NET 2.0 installed, see - http://www.hanselman.com/blog/DeployingASPNETMVCOnASPNET20.aspx
It's very much a "works on my machine" certified post though.
All DLL's on an ASP.NET site can reside within the /bin, provided they are correctly referenced. My suggestion - create a virtual machine (MS Virtual PC is free), install just .NET 2.0/ .NET 3.0 and then copy the DLL's you require from a .NET 3.5 install (tip - you'll find the DLL's in %program files%\Reference Assemblies).
I take no responsibility for the damage you cause to your provider from this answer
I'm pretty sure you can't do this, but googling on the following blogs may get you the definitive answer:
ScottGu
ScottHa
BradA
The problems would be, I think:
You want to load system.dll. Where does it look? does the GAC take precidence? (I think it does), therefore you get 2.0. So you have system.dll v2.0, and you try to use a DLL (eg system.web.mvc) which is bound to system.dll v3.5, but is only in you /bin.... it should explode loudly, not having the same contracts and the like.
Personally, I wouldn't try it, especially on production. But if you can take the site down for a while, give it a go. Worst case, you have to delete the files and re-upload the old site.
YMMV :)
I've successfully run some EntityFramework websites on hosts that only had .net 3.5 installed. I copied the System.Data.Entity.dll and the System.Web.Entity from Program Files%/Reference Assemblies. I also had to modify my web.config and remove the references to the System.Data.Entity and System.Web.Entity.
Update: this technique will not work for DynamicData or the EntityDataSource web control. I belive it has to do with the System.Web.WebExtensions.dll which already exists in the GAC from 3.5
Related
I'm working with one of my clients wherein they are having a few application still written on .net framework 3.5. Though we still have support for .net 3.5, client wishes to upgrade the framework to 4.8. There are no plans to migrate to core/.net 6 as of now but to upgrade to framework's latest version 4.8.
I'm looking for some pointers to migrate an application from 3.5 to 4.8, what could be the runtime changes/retargeting changes/breaking changes. It would be of great help if someone could give me a roadmap to address the problem - where to start from, what details to look into etc. I searched a lot and could not get any specific pointer for my use case. Please help.
Thanks in advance!
Well, in most cases, you should be able to simple set the project up to say .net 4.8 (or 4x). But, you might as well go all the way.
You WILL however has to download and install .net 4.8 on the web server. So, on your developer computer, you most likly do have .net 4.8. But, don't forget to download + install .net 4.8 on the web server (or if it is a hosted plan, find out what is the level of .net they support).
So, for the most part, you should be able to simple in your project, set it as 4.8, and see if it compiles. You have a VERY good chance it will.
That would be this setting project->"my project name properties"
So, the above for the most part should make things work.
Also, once you done the above, (then re-build all). You want to check web.config, and this setting:
<httpRuntime targetFramework="4.8" maxRequestLength="2000000"/>
As noted, you also have to check/ensure that the web hosted server (if this is not a on-site server) also needs the .net frameworks to be downloaded and installed. Often they already are but you want to check that.
It also possible that you are using a asp.net web site as opposed to a asp.net web site application, and thus the above steps do change somewhat.
one thing is not clear to me that in asp.net 1.1 there was asp.net project type but from 2.0 version there is no asp.net project type option rather there is option called website type project.in website type project no link is created with IIS.why Microsoft design in this way from 2.0 version. i think there must be solid reason & advantage behind it and also tell me why no dll is created in bin folder until publish the website in version 2.0.
please explain the reason,advantage and MS Thought behind it if anyone knows the reason very well.
With ASP.NET 2.0, Microsoft split the concept into two different project types: the Website project type you're describing, and the Web Application project type. The main difference is the Website project type is designed to be folder-based, lightweight, JIT - essentially low-overhead where no overhead is justified. The Web Application project is a "traditional" project type: assembly-based, with a project-schema and optimized for precompilation.
In my experience the Website project type is unpopular with developers, perhaps for no other reason than it is different from almost every other project type. The limitations should theoretically make quick-and-dirty website projects more agile, but frankly I don't find the overhead of a Web Application project a concern.
MSDN covers the differences between the two here: http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
Because they forgot to add the template. That bug was rectified in SP1.
Besides, there are now two types: website + web application. Use the latter if you can, because website projects don't offer installers.
Is there are some ability to disable .net 3.5 on IIS 6 for asp.net site? I just have an application (.net 2.0) that has not working on server with .net 3.5, is throw :
Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt.
Description: An unhandled exception
occurred during the execution of the
current web request. Please review the
stack trace for more information about
the error and where it originated in
the code.
Exception Details:
System.AccessViolationException:
Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt.
Thanks in advance.
Please post the complete exception. Also, is the failing application a .NET 3.5 application? There is no "disable" in IIS because .NET 3.5 uses the .NET 2.0 CLR, just like .NET 2.0 and 3.0 did. .NET 3.5 does install service packs.
You shouldn't have to "disable" anything. Your application should still be running in a v2.0 AppPool.
Scott Hanselman's blog post How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0 is sort of the reverse of what you're asking, but it should help explain the situation more clearly.
In particular:
[web.config is] where your web site is
told what version of the compiler to
use, and the new supporting libraries.
This is where you tell ASP.NET to use .NET 3.5, not in IIS. IIS
AppPools know about CLR versions, not
Framework and compiler versions, those
are set by the application.
So your application is still running on the .NET 2.0 CLR, even if you have .NET 3.5 installed.
I realise this is quite an old topic, but I had this issue today and managed to resolve it by deleting some registry entries.
Open "Regedit" and look for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\Security\Policy\Extensions\NamedPermissionSets
Export the keys in case you break something, then you can restore the original configuration.
Within this key you will have a number of sub keys (I had 'Internet' and 'Intranet')
Look at the values in the subkeys and remove any Keys which refer to versions of .NET later than 2.0.5027
I suppose the alternative to this would be to register the appropriate library and/or classes in your web.config.
Hope this helps the OP or anyone else having the same problem.
Not sure if this any use for you, but I think you can declare the required runtime for your site in the web.config file. Check out this blog post. By specifically declaring which version of the .NET framework you want your site to use, it might help.
<configuration>
<startup>
<requiredRuntime version="v2.0.5027"/>
</startup>
</configuration>
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.
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_...