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.
Related
I am trying to generate Well formatted Excel files from .Net Core and found ClosedXML library which runs only on .Net 4.61
I already tested the following libraries which work on .Net Core
OpenXML - Too many codes for a simple task and difficult for me to use
SyncFusion - Public / Government Organisation cannot use for free.
I changed the target to Net461, do the dotnet restore and all my codes are still running as usual and I could generate the Excel file with ClosedXML too.
What I would like to know is, is it a good approach? This is not a one-off small project and I am likely to maintain this website for another 3-4 years at least.
Is there any potential to lose the new functionalities and not able to use new Libraries from .Net Core in the future?
Or should I create another separate website running on Net461 and call that URL from my .Net Core app? So, I don't need to worry about losing new .Net Core functionalities in the future.
There is obviously no way to know the future, but the biggest thing you get with .Net Core over the full framework is the ability to run the app cross platform. So if cross platform isn't a concern, then going with the full framwork shouldn't be an issue. There is no question that the full framework will be fully supported for the 3-4 year time horizon you mentioned, in fact I think most developers would feel comfortable using the full framework even for a project with a much longer time horizon.
With regard to missing out on new .Net Core features, many of the features can be accessed even from libraries compiled for the full framework. For example I use the new encryption libraries found in Microsoft.AspNetCore.Cryptography (that are part of .Net Core) from my full framework class library. The net .Net Core libraries are just Nuget packages and as such can be referenced from non .Net Core projects.
I am in the middle of the development of a project.I am using asp.net framework 4.5.So far what I have developed, I have to publish it on a Linux server. So i fount that, I will have to upgrade my existing project to ASP.NET Core 1.0 in order to publish on Linux server. Can anyone please suggest me how can I achieve my goal?
You may encounter a couple of issues and looks for different solutions but a general guide can be found here: Migrating From ASP.NET MVC to ASP.NET Core MVC
For specific errors when the general migration will be done, it's worth to take a look at ASP.NET Core's GitHub page as a lot of issues that can occur during migration is described there.
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_...
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
We've been working on an application that quite heavily relies on VirtualPathProviders in ASP.NET.
We've just come to put the thing on a live server to demonstrate it and it appears that the VirtualPathProviders simply don't work when the site is pre-compiled!!
I've been looking at the workaround which has been posted here: http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/, but so far I haven't been able to get that to work, either! (Well - it works fine in visual studio's web development server - just not on our IIS box - again!).
Does anybody here have any more information on the problem? Is it fixed in .NET v3.5 (we're currently building for v2.0)?
Unfortunately that is not officially supported. See the following MSDN article.
If a Web site is precompiled for deployment, content provided by a VirtualPathProvider instance is not compiled, and no VirtualPathProvider instances are used by the precompiled site.
The site you referred to is an unofficial workaround. I don't think it's been fixed in .NET 3.5 SP1