Keeping DRY with ASP.NET and multiple projects.
At the company I work for we are in the process of moving from Classic ASP to ASP.NET for our large intranet site.
There are currently two developers working with this intranet site at this time and we do not currently use any form of source control other than communicating to each other which projects we are currently working on. I’m not sure if we are going to get approval to use Team Foundation Server or any other source control system yet.
Our site currently consists of a mix of single static content and single dynamic content pages.
In addition there are approximately 50 different web applications all used by various departments throughout the company. These all range in complexity from single page forms all the way to very complex multiple page applications with various levels of report generating capabilities.
All of these web pages share a common layout, basic javascript, css, header, footer, and sidebar. I’d like to follow the DRY principles as much as possible to aid in redesigns or changes to the shared header, footer and sidebar.
My guess is that we will end up having a mix of HTML, Classic ASP, .NET Webforms and .NET MVC applications all housed on one server under the same domain name.
Goals:
Master Pages / _Layout.cshtml - Share a single master page and an MVC layout page among the various webforms and/or MVC applications. I don’t mind having to maintain one master page for Webforms and a Layout page for MVC.
Header, Footer, Sidebar - If I can’t easily share the Master/_Layout page. I want to share at least the header, footer and sidebar among all the various pages so they can easily be updated sitewide.
Publishing changes for single applications - I’d rather not have to publish the entire site and all of the various applications every time I make a change to one of the applications. Is there a way to retain this functionality and still achieve goals 1 and/or 2?
If you can please tailor your answers for someone with almost no experience working with ASP.NET Webforms, MVC and C#. I have completed several tutorials but am still very much in the beginning stages of the learning process.
Thanks for any help that you can offer it is greatly appreciated.
To achieve all three requirements you'd have to have your layouts in a separate project that will be common for all other your projects.
Take a look at this article, which explains how you can compile views into a dll.
Once this is done, you'll be able to share this dll file between the rest of your applications, thus sharing layout pages, which will have header, footer and sidebar.
Put all your other MVC application in separate projects as well (You can still keep them all under a single solution), so that you can build and deploy them separately.
Related
I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).
I am trying to integrate a CMS into an existing ASP.NET Web site built with .aspx files and .aspx.cs code behind files (not compiled).
My research indicated that my best candidate is N2 CMS.
My ideal approach is to configure the editor with various editable content types and have my existing pages and user controls use the API to retrieve the content and place it pro grammatically into containers.
I couldn't find how this can be done, anyone have any idea how and if can this be done ?
Is there any other CMS that is better suited for the task?
We have had this exact setup existing web applications (WebForms + MVC) integrated with N2 in the same manner as you have described in previous projects and it was fairly simple to implement, but by now we have switched to using umbraco for the same purpose for the following reason:
better support (larger community)
better backend editors
more ready avilable modules (even commercial supported ones)
richer backend ( proper multi language support)
configurable rather than code oriented (this is a pro/con depending what you need)
One important note:
Don't waste time host the CMS + the actual application in the within the same ASP.NET application. We have all of the installations separate and we would have not done it differently looking back, especially when you have existing web applications with routing etc. in place already. The CMS is just going to mess this up at some point. Also this is not CMS specific.
Traditional CMS are pretty intrusive, they dictate you the way you must build your system. And if you already have a web site, and just want to add some Content Management functionality into it you are out of luck - all traditional CMS want you to demolish your old web site and rebuild everything from scratch.
It's actually a good idea to keep CMS and web application separate. In that case all you need is some kind of markers on your web pages telling the CMS what should be manageable. "Software plus Service" solution. This is what ElasticWCM (http://www.elasticWCM.com) is trying to do.
For a web site developer ElasticWCM is just a set of ASP.NET controls you can wrap around your Html to make the content manageable. When you click on the "Edit Page" button on the PageToolbar control you get redirected to the rich page editor where you can manage all your content fields. Nothing to install, just reference the controls' DLL.
You can't get less intrusive than that. As a bonus you receive all bells and whistles of a full-scale multilingual CMS and a bunch of unique features.
We have had a fair amount of luck with Sitefinity from Telerik. It's .net based, easy to extend, and has a good collection of plugins. On the downside it is pricey.
I have been working on ASP.NET MVC for a while and loving it so far. But I am hitting a wall now.
I am working on a new intranet site, where I will have to host many projects, ranging from couple of pages to full blown applications. I have been using Areas to differentiate between the projects. It's all good so far.
Now, the solution is too big and every simple change I need to compile the whole projects which consists of all the areas (multiple projects). I am always afraid of making changes to live once I compile and upload the dll.
Is there anyway that I can hold multiple projects sharing same layout but to compile each projects into separate dll?
Thanks in advance
EDIT
Thanks guys, I followed Portable Areas as an ASP.NET MVC Project and he seems to have explained things much easier in a step by step to get started.
Have you considered using Portable Areas feature in the MVCContrib? - read a post about it here
Also read the response from Eilon in another question Multiproject areas in ASP.Net MVC 3
If the portable area solution won't work for you then it's probably time for a refactor/restructure of your single web project into separate web projects. As it is an intranet site you'll probably want to setup some sub-domains to allow you run separate websites under the one domain.
Eg.
www.yourdomain.com
admin.yourdomain.com
calendar.yourdomain.com
etc.
This way you can segregate your functionality and update different areas of the intranet without affecting others. You may of course need to look into single sign-on across your sub-domains depending on your site.
I would normally extract all common functionality into a core project (class library) which may be used by all of the web projects, and keep each your web projects as lightweight as possible. Then you can create separate solutions for different web projects or groups of web projects.
Also consider looking into continuous integration/build server so that you can easily check if a change you make in one project is affecting other projects that may not be in your current solution.
I know this kind of question has been asked multiple times here but I am really looking for a solid approach to sharing masterpages and user controls across multiple web projects. The reason for this is that our current web application is just one webform project but has grown out of control. We really need to split this single web project into multiple web projects for a variety of reasons. However, when we try the various approaches mentioned on this site (ex. embedded resources, precompiliation, etc...) we always encounter warnings within visual studio and loose intellisense. We also looked into using source control as a means to share reusable controls but we would really like to avoid this sort of anti-pattern.
Overall, how can a large development team effectively split a single .net web project (webform or mvc) into multiple web projects and share reusable controls (masterpages, user controls, images, css, js, etc...) with full intellisense within Visual Studio? Any insight on this is appreciated. Thanks!
I agree with jfar that your question is very broad and doesn't do a good job of explaining whey you think you answer will be different, but I'll attempt an answer anyway.
User Controls are not designed to be shared among projects or disparate applications. They allow you to group common functionality for your specific application where the case for reuse outside of the project is small (for instance, a project drop down box allowing managers to choose different properties on a variety of pages).
If you need reusable controls that can span multiple projects easily you should be using Server Controls. This will allow you to create, and compile, controls as .dll's that are designed to be reusable between projects.
If you really need to reuse the same controls in multiple places you should explore the pre-compiled and packed into a .dll solution offered by Server Controls. This allow the maintenance task to so solidified around the single .dll which can be version stamped and easier to track over time.
When it comes to Master Pages. You can embed the Master Page file into a .dll that can be shared among multiple projects. Since ASP.NET supports nested Master Pages you should be able to embed the core Master Page while leaving it open for changes in different projects.
If this answer isn't helpful you'll have to be more explicit in what about them isn't working or makes them not worth pursuing. The clearer the question the better the answers.
I'm still struggling with this question as I'm trying to get up to speed with SharePoint, coming from ASP.NET Web Forms. We're looking to use SharePoint exclusively for several reasons; one of the main selling points is to consolidate our development efforts. So for example, today we have several one-off websites with anywhere from 1-5 pages (smallish) on several servers, IIS installs, etc. and seem to be a bit fragmented.
Let's say I have a requirement for a smallish site (1-5) pages. What is the SharePoint way to handle this situation? Do I create several Web Parts, then create the pages in SharePoint and plug them in or do I simply create an ASP.NET Web Forms application and provide a link within SharePoint to it?
Thanks!
Update
I'm going with neither. Based on feedback and additional research it seems that Application pages are what I'm looking for. Here's a good article: http://grounding.co.za/blogs/brett/archive/2008/07/13/sharepoint-the-role-of-a-web-part-vs-using-application-pages.aspx
You use SharePoint web parts when you want non-technical users to be able to compose pages through the SharePoint UI - creating new pages in a site, selecting which parts they want for the page, configuring them, and arranging them on the page. They can use audience targeting to only show the desired web parts to certain users.
You get all of that pretty much out of the box with SharePoint. Even if you don't need all of it right away, it's not much more effort than building normal ASP.NET applications - except getting over the initial learning curve.
What kind of user experience are you looking for? Sometimes it makes sense to have a static page, and sometimes it's much better to allow users the ability to move things around and create their own page. Creating a web part isn't too bad, but I saw somewhere that you are in a time crunch, it might take you a little while to get over the initial learning hump.
It's tough for me to estimate the learning curve because Visual Studio 2010 does make things a lot easier to do than anything that was available when I was new to SharePoint.
Don't create an asp.net web application to interact with Sharepoint too quickly, there is much out of the box that you can accomplich with sharepoint.
If that is not enough you can easily program Sharepoint 2010. You can create Application pages that are equivalent to ASP.NET web forms. Look into that first before creating 2 disperate systems.
What are the pages supposed to do?
Here's what we did... we moved all our existing applications on to a dedicated application site. The idea is that this will enable us to roll out SharePoint faster. We developed a custom Web Part with security-trimmed links to all our department apps on the new application site. Only other deployed solution was for customizations.
The idea is that we can move forward and port existing application over only if there is a real reason to do so. All new collaboration-based apps can be developed on SharePoint from scratch as needed.
UPDATE
You could create application pages but familiarize yourself with the difference between application pages and site pages:
http://blogs.msdn.com/b/kaevans/archive/2010/06/28/creating-a-sharepoint-site-page-with-code-behind-using-visual-studio-2010.aspx