I would like to what is the differece between the webapplication and the website.
Any suggestions will be greatly appreciated!
Yes there is difference between web-app projects and website projects.
Text from the MSDN :
In Visual Studio you can create Web application
projects or Web site projects. Each type of project has advantages and
disadvantages, and it is helpful to understand the differences between
them in order to select the best project type for your needs. You must
select the appropriate project type before you create a project,
because it is not practical to convert from one project type to the
other.
In layman language:
Web application:
If you can think of a site where you create an account, log in, and conduct some actual business, it’s probably a web application
So a web application is a web site that DOES something other than display content to the user.
It’s intended for user interactions and transactions, performing actual business functions, and not simply displaying information to users.
Some example of web application
GMail,Facebook,Ebay,Twitter,YouTube
Web site:
Web site usually use for dispaly information .They have less or no interaction with users, so we can say Websites are informational by neture.
Some example of web site
Nokia.com,Songspk
For development point of view
The Microsoft best described this on there website here here
Please take a look on following table-
Related
I'm looking at the differences between a Web Site and a Web Application on MSDN, and am drawn to the features of a Web Site because I am tasked with devising an architecture in which customers can heavily customize the application we deliver. It seems this feature of web sites would be useful:
You want to be able to update individual files in production by just
copying new versions to the production server, or by editing the files
directly on the production server.
However, I'm also drawn to the MVC architecture because it has built in features for minifying scripts that are delivered to the client. I also kind of like the idea of breaking up the architecture into clean pieces since this is a very large data model we have.
But from what I can tell, these sets of features appear to be mutually exclusive. Is that true? I can't readily figure out how to create an MVC application in which custom views could be dropped in as pure source files, and be able to run, nor can I figure out how to take advantage of any MVC framework when creating a "Web Site" project. Am I missing something or do I have to pick my poison?
Take a look at ASP.NET templates in VS2013. You can create an app with both MVC and WebForms. This will probably give you a good combination of what you need. By default, view files are not compiled, so you'll always be able to publish new files without doing a full push if you want. In fact, VS2012 even allows you to publish select files or folders.
The choice between web site and web app to be is very simple. If you are creating a mostly static app, choose "web site". If you are creating an app that has even a decent amount of dynamic capabilities, choose "web app". Web Sites are not really designed to be dynamic, so the more dynamic you do in that setting, the more of a headache it will be to properly maintain it as the architecture just isn't where it would need to be.
What I would suggest is to spin both of them up and try out some scenarios that you are interested and see what works and what doesn't. Really think about how users will actually want to customize the app. Will they want to copy and paste files to production or would they rather request features and have them built properly? Or maybe they want to work with a workflow instead?
So make realistic business requirements, prototype and then decide. But based on what I'm hearing you want a WebApp and probably one that does MVC and WebForms.
Now everything ONE ASP.Net. You will be creating a WebForm, MVC, Webpages using ASP.Net platform.
Check this video about new features in VS 2013
Not sure you can create website in ASP.Net 4.5.
From my experience, I would go with WebApplication based project, where managing namespace and other stuffs are easy. In website its hard to get the standard name for the classes(randome) generated.
Go with MVC web application.
I'm a web developer who's working in a new shop with developers from a desktop background - as such they have certain idiosyncrasies/best practices when it comes to organizing their code - one of which is that separate UI views are isolated into different projects.
So, on the web side of the house, I have a problem with different projects building in different app domains:
1) I have a "portal" project with a default.aspx
In the code behind there is a custom authentication method called from inside the Login_Authenticate event to log into the "business layer" of the desktop application. The business side stores session data in ASP.NET sessions.
2) I have a "viewer" project with default.aspx - this was originally in the portal project as "Viewer.aspx", where it was covered under the same login scheme and authenticated fine, but we decided it would be good to stand on it's own project because it is a separate view.
We added the same machine key to both web.config files so the .NET forms authentication could be passed via single sign on.
I built the viewer project in two different the fashions:
1st Try (it's own URL):
http://localhost/Viewer
2nd Try (a subdomain under the portal URL):
http://localhost/Portal/Viewer
The issue I'm running into is that the session is not being passed between the Portal project and the Viewer project. I know this is because IIS is running them in different app domains. Unfortunately without the ASP.NET session from the Portal, the Viewer is not logged into the business application.
Is there a best practice/is it even possible for running multiple projects in one app domain? Should the Viewer be a part of the Portal application since it requires the same session? Should the Viewer be a separate project that requires it's own separate login into the business layer? Is there even a best practice/guideline for this scenario?
By default session cannot be shared between different applications.
In practice most projects are not separated this way. In my experience most use some sort of n-tier architecture. Basically you have all your "view" code in one asp.net project, any buisness logic/data objects in another dll project, and your data access in a third dll project. The website then just references the other two dlls.
To solve your issue this answer might give you what you want: Sharing sessions across applications using the ASP.NET Session State Service
There is a way to have multiple projects, but one site. That example is a little old but still works, and is how we do our site.
In Visual Studio, I tried a project in both. But there appears to be no difference in the tools displayed in the tool box....
So what the real basic major difference.?
See these:
ASP.NET Web Site or ASP.NET Web Application?
Website is for internet based audience - in this case your concerns(security, etc) are different;
Web application is a software, just like a desktop application software, usually intended to be used for intranet environments. For instance, an HR software could be a web app - that is available on the intranet for all the departments to fill in their timesheets.
Though, a website may contain specific operations, tasks, or workflows.
Checkout: Web site project vs Web app project
WebSite project is compiled on the fly.
In a WebApplication, you need to build a page before you can debug.
However, WebApplication is the way to go, because with WebSite-project, you cannot create a setup project (and conversion from WebSite to WebApplication can lead to problems/bugs).
That's why I recommend WebApplication.
Simply put, a WebSite is worth nothing if the customer is too stupid to install it manually.
We currently have a product that uses Sharepoint and a number different Web Part libraries to display realtime data to customers. The way this has been set up is that each customer has a custom login (Active Directory), a custom site with their specific data hooked up in the web parts. That means for every customer we have a completely separate site. Eg:
Customer 1 -> www.site.com/sites/customer1
Customer 2 -> www.site.com/sites/customer2
Customer X -> www.site.com/sites/customerX
As you can imagine, this is impossible to maintain as any small change that we make has to be manually propagated across all of the site, a task that has become impossible.
We are also developing separate ASP.NET MVC application that live on the same server under their own Virtual Directories Eg. www.site.com/App1/
I've been tasked with investigating how to best redesign the system to provide a more integrated and "application platform" type architecture.
Personally I would love to just ditch the Sharepoint as I think we are using it incorrectly (not as a CMS at all), but my manager wants to keep the Excel Services for customers who pay extra (a customising service).
We currently embed the MVC applications in Sharepoint using the Page Viewer Web Part, but this gives us less control over the layout of these applications
My next thought was to have a standard ASP.NET masterpage across all MVC sites and sharepoint so that they look the same, whilst still providing the functionality required, but investigation and testing seemed to be that Sharepoint master pages are horrible beasts that barely resemble a clean master page.
Basically I'm stumped, and I'm getting a little disheartened about Sharepoint and it's god awfullness.
Does anyone have any experience with this or could provide some ideas/tips?
Very much appreciated.
CodePlex - SharePointMVC
A helper project for hosting asp.mvc content inside SharePoint.
We have a web site built as an 'ASP.NET Website' type project, rather than the 'ASP.NET Web Application' type.
Aside from the obvious debugging advantages that the app type offers and access to the designer files for each page:
What, if anything, can be gained by switching from website project type to app?
Are there performance losses with one over the other?
How much work is involved in switching an existing (dev) site from website to app? Is it as simple as creating another site as app type and adding these existing aspx files and libraries to it?
This question (How To Convert ASP.NET Website to ASP.NET Web Application) seems to cover the steps.
What are the risks (if any?)
How much work should we plan on?
Are there differences in how HTTP Application deals with requests or how handlers work between the two types?
Anything we forgot to think of?
http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
That describes some of the features and advantages/disadvantages between the two.
The main reason to use the web project versus the web site is that the web site is dynamically compiled which tends to incur a performance hit whereas the web project is precompiled. You should gain performance moving to the web project method. You also gain control over the naming of your final compiled assemblies.
The amount of work really depends on how many pages are in your old site.
I don't think the .NET framework handles code differently in the web site versus the web project. It's really the configuration of the file structure, the lack of a central project file, and the method of compilation that ends up being different between the two.