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.
Related
OrchardCMS, Umbraco and DotNetNuke are CMSes in .Net galaxy. They work as stand alone applications well. Suppose I have a requirement that need CMS features in an another ASP.NET MVC application. I do not like to implement CMS again in the application. Rather I like to use current CMSes as a component of application.
Is it possible at all to use for example OrhcardCMS as a component of my MVC application? It is ideal to have relations between CMS and application itself, for example I can load entities from CMS, update them etc.
I know there are integration techniques in .Net. For example ASP.NET Identity integrates with ASP.NET applications in core level, but view (CSHTMLs) must be copied and customized in most cases. Or Hangfire and ELMAH that integrates with an application without need to copy view (cshtml, html, css) to the target application. Indeed it is good to know that integration methods are available regarding plugging CMSes into ASP.NET applications.
I can tell you more about Umbraco as I don't know other CMS as much as this one. There is a whole course / training for those who want to integrate their apps with Umbraco: https://umbraco.com/products-and-support/training/umbraco-application-integration/. So yes, it's possible and it's even suggested way from my perspective to use already done piece of software rather than building the wheel once again.
Umbraco is an ASP.NET MVC application. You can use Umbraco components, backoffice, membership and everything else CMSish delivered out of box and still you're able to write and use your business logic, controllers and everything else what you've created inside your ASP.NET MVC / C# app. Still, it's an ASP.NET app, so you can use anything what you want from the .NET world. We're using ELMAH.io for example to take care of logging and keeping the errors in the cloud. We're also using a ton of 3rd party, both open-source and commercial tools and softwares to do multiple things around our web components. Umbraco is not blocking us from using them or anything else. I like to consider Umbraco as a framework or library helping us to deal with content editing and giving us a massive number of opportunities to offer for our clients or editors.
Speaking for OrchardCMS, there are some questions touching this subject already, see
Reusing Orchard's Core to build another extensibility framework
Extracting a Module from Orchard
If it's possible for you then try to setup Orchard as the base system and move your MVC application in a module. This will be much easier than trying to cut out peaces of Orchard. In return you get amazing possibilites when running Orchard as the underlying framework, e.g. Localization, Modules, Themes, the whole user / role management etc.
OrchardCMS 2 is currently developed towards single components that can be reused in any application but it's far from finished yet.
When creating a new web project in ASP.NET are you better off to use the "ASP.NET empty web application" or the "asp.net web forms application"
I would recommend against even bothering with ASP.Net Web Forms. It was an interesting idea that proved to be unweildy in practical applications. The entire web development industry is moving towards some kind of MVC framework or another whether you're using PHP, Ruby or ASP.Net so you're best off using that.
Of course there are still a lot of ASP.Net Web Forms applications out there and they're likely to exist for some time into the future so there is some benefit to learning the technology but I would avoid it for any new projects.
As per your question if you should use the empty project or not it doesn't really make a difference. If you're just starting out the populated project can give you a basic idea of how the structure works but if you're comfortable enough building it from scratch then go with the empty project.
It depends on what you want to do.
Generally speaking, there are three kinds of ASP.NET application project:
Web Forms - what ASP.NET was originally back in 2001. Its use is discouraged in modern and greenfield applications because it is built-around outdated ideas about how web applications should work.
MVC - The new hotness. Try to use this. StackOverflow is built using this.
Everything else - too many to list, but this generally requires you create an empty project and do everything from scratch using IHttpHandler.
If you're new to ASP.NET I strongly recommend avoiding the two project types you listed as they're both for Web Forms; consider using the "ASP.NET MVC Application" options instead - if you're using VS2008 then you need to download and install the ASP.NET MVC 2 add-on. VS2010 and later come with the MVC templates preinstalled.
You might want to use the Empty Web Application project template if you want to work from scratch using IHttpHandler, but you sound new to this, so I recommend avoiding it.
I'm new to developing in SharePoint and would like some tips please. I want to develop a WebPart. I understand that I effectively need to do this on a machine with SharePoint Server installed and create the web part as an ASP control. Once the control is created, how do I link it into SharePoint?
I would recommend you to take a look at the WSP Builder extensions for Visual Studio. It will simplify the development and deployment process for you, since it contains both templates for web parts, features and it will also package it up in a WSP solution for you.
I would read though this:
http://msdn.microsoft.com/en-us/library/ms452873.aspx
It will answer a lot of your questions about creating a web part, deploying etc.
If you're using the Microsoft Provided WebPart Visual Studio template...it will automatically be deployed to your site when you build it.
If you need to deploy to a test/production environment, you need to create a SharePoint Feature and then deploy the Feature to the server.
http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/ helps you to create simple webpart and shows how it deploy in server.
You are able to build Web Parts in a number of different ways, through Visual Studio .NET using either the SharePoint Web Part Namespace or the normal ASP.NET Web Part Namespace further you are able to build Web Parts in SharePoint Designer using a combination of different technologies, such as XML Web Services.
XML Web Services will allow you to hook directly into SharePoint using SharePoint's Native Web Services, you can then create a Data View Web Part which will enable you to view, collate, filter and group List Items. This, of course, will also allow you to mingle normal HTML as well as XSLT syntax, allowing you to build logic into the Web Part.
The good thing about doing it this way is there is no "real' coding, i.e. no Code Behind page etc as there would normally be in ASP.NET. This also allows you keep things more or less SharePoint Centric, which is important because you may or may not have access to Central Admin or SSP nor indeed the Server itself, the 12 hive or the GAC.
How you decide to develop Web Parts should include thinking about all of the above, you may have a very restricted development environment. Further, you can also use Namespaces provided directly from GAC assemblies provided by Sharepoint, you may either need access to a development environment which has a MOSS or WSS Server on it or the PIA's or Assemblies from a MOSS/WSS Server.
I am a software developer, however, it is important for me to develop applications which are as SharePoint centric as they can be, which is why I decided to develop my Web Parts in SharePoint Designer. However, there have been times when using full VS.NET is the way to go, I would suggest you look at SharePoint Designer first, get a feel for the interface, XML Web Services, XSLT and HTML once you have created a SharePoint Designer Web Part and Provided this Web Part exists within a Web Part Zone, you can export the Web Part and reimport it into any number of Site Collections.
I must add that the above relates to SharePoint Lists and Libraries but it gives you a grounding to understand how it all fits together. it helped me understand more and made development of more coded Web Parts easier, It may not suit your individual requirements, SharePoint is a huge environment offering many paths.
Hope this Helps you out, search for SharePoint Designer... at least as a starting point.
Cheers
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.
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change