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.
Related
i have just went through this article to create a web application with multiple web application.
https://support.microsoft.com/en-us/help/307467/how-to-create-an-asp-net-application-from-multiple-projects-for-team-d
my requirement exactly match this.i have a large web application which i have to deliver in multiple phases and when deploying the changes of any child project,it should not affect the existing running child project or main project.i should be able to use the use control or dll between the child projects.
i need a sample of this approach. i have tried to create the same but the sharing of user control etc. between the child projects is not working.i think ,i am doing something wrong. if anyone have a sample or example of this approach then please share.
i am working on asp.net web form application not MVC.
Presuming you are using source control effectively, this should not present any problems. You can add a child project at any time and keep it checked out to yourself. When you are satisfied with unit testing you can perform integration testing before putting it live.
The only issue I see with your description of the problem lies with attempting to share User Controls between projects. People have been experiencing problems with this approach for a long time, especially with the Web Site Template. It apparently is possible for Web Forms projects:
How do I share user controls between web applications in ASP.NET?
Creating and Using User Control Libraries
Personally, I think it depends on what you are trying to to with the User Controls. For example, are they just displaying something that is repeated on different pages? In that scenario, make more judicious use of Master Pages. If they are being used for functionality, then consider the creation of a library of Custom Server Controls and reference these in your projects?
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.
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.
In a website, I see some developers put code into app_code, and sometimes appcode (due to some bug), other files into DataModel, and other files into miscellaneous folders.
Is there a standard approach to organizing code within an application?
How is it different between an ASP.NET, MVC, Silverlight, Console, Database, and WCF application? The reason I mention WCF is because many people seem to have a shared types library that is linked between the server and client code.
Where can I learn these common practices without having to try, fail, and try again. I'd rather just learn it once from the experts.
the most standard well organized is MVC framework. For anything else, mostly i organize folders as namespace.
eg companyName.projectName.folderName
myCompany.StackOverFlow.Extension
myCompany.StackOverFlow.OpenID
There is no set in stone 'best practice' standard for organizing namespaces. My personal approach to keeping projects organized is to limit the content of any directory/namespace to about 20 items. This means I can fit the full contents of a folder into my screen, and also see every other item surrounding it (assuming other folders are collapsed).
On the other hand, lots of folders without much content can make navigation difficult as well.
Another thing you should do is to separate your solution into projects based on dependencies. For example if you are using m-v-vm, you should have a project for each of Model, View, and ViewModel.
Files placed in AppCode should only be files directly relevant to the presentation modules. Other files (ie ViewModel, Model, Controller etc depending on the framework you're using) would be preferably placed in separate projects.
Take a look at the "WCF the Manual Way…the Right Way" http://www.code-magazine.com/Article.aspx?quickid=0809101
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control