One of the projects I was in charge of as a JSP/Struts developer at my last employer was a themes tag library (present on every WebSphere server as a shared library) that let any Java web dev in the company pull in any of the standard themes like intranet, public, etc. with minimal effort. The themes included header, footer, navigation, and links to css & javascript, etc. They could even customize things a bit when we gave them the option, like choosing a selected tab.
This setup was ideal because we could make centralized change to any standard UI elements and they were automatically pulled in by all sites using themes without any effort by the site developer.
With the new job I started in December, I've switched to using ASP.NET. I'd like to propose something similar in spirit to the themes app here, since we're running a bunch of different sites that should have a unified look and feel.
What's the best way to accomplish this? I'd rather not have to recompile anything to update the theme to make this work.
Edit:
Although I was hoping for a better answer, the .NET gods apparently don't approve of what I was trying to accomplish. Here are the three options that were found:
Compile a Master Page into a DLL and put it into the GAC:
This works in simple cases, but as a hack it's too brittle. I couldn't get it to work correctly with our site.
Create a virtual directory to the Master Page in each web app: This actually does work, although it doesn't make for a very comfortable development environment. However, one of the things we are trying to move away from is having to create virtual directories inside each web application. No dice.
Create a bunch of custom controls, compile them into a DLL, and put it into the GAC: This is the answer I selected. It's the least centralized option and requires more work for the developer of each site, but it seems to be the only Microsoft-blessed way.
In conclusion, I'm pretty frustrated with .NET over this. In the grand scheme of things Master pages are just code, and I don't see any reason why they couldn't be easily centralized for use in multiple web applications. This seems to be a major loss compared to JSP/Java.
You can put some UI into the form of custom controls or server controls (if not in MVC) and then place them in the GAC thereby distributing them. All references to the controls in that assembly will be pulled from the latest version in the gac. You can also do things via the Machine.config which is controlled at the server level rather than the app level.
Related
I'm working in a web application that has several areas of bussiness work. With time it's size has became a problem to develop on and to maintain.
I would like to break the web project into several sub-projects or libraries depending on a main root web project that has the common files to share (Masterpages, Resources, Css, etc...)
Ideally I would like to have some kind of injection that allows me to optionally publish that "components" or simply publish a customized variation, although it's configuration depended on after deploy DB setup.
I searched all over the web, reading all the pages related to multiple projects, dependency injection and composite apps that I could find, 'till I soften my head, but couldn't find anything really useful.
Major part of the writings where a theoretical approaches or unit testing applications (well, you can't make your desired app, but you still can unit test something else)
Other approaches simply don't work in VS2010 .Net 4.0
Can someone address me on a COMPLETE solution or an example? Or simply lets discuss.
We say that the solution has the following structure, with module contents already separated into directories:
Solution
L_ Datalayer library project
L_ Bussiness logic /common utils library project
L_ Web project
L_ Controls
L_ Images
L_ Css....
L_ Warehouse
L_ Sales
Masterpages
...
Warehouse and Sales contains pages related to the "module"
Thanks,
I post my progress in the subject.
As per suggestion of Steven I experimented further more using MEF. Due to the lack of documentation, specially for webforms, that was a pain in*. So far I managed to implement MEF in my solution and sucessfully inserted a plugin project visible for the main app.
Then loads the available plugins, through an interface that has the plugin name, the default page url and its order, picks all this data and render a menu tab. That part it's easy.
Clicking on a menu element must redirect to the main page of the plugin, which will render several menus for its pages contained (from another export interface)
I finally got an aspx page embedded as a resource in the plugin project. Where I'm currently stuck.
¿Is there any way to render a page embedded as a resorce on a libray using MEF or I'm forced to also use a VirtualPathProvider? ¿Hows specifically the statement to redirect to that page? I've tried several ways but no-one works (MEF and VirtualPathProvider)
I looked at zillion of articles that talk about it but all them end doing control rendering, not page. So frustrating.
Though it is not an answer to your question, I am adding it as answer due to length of my suggestion.
I suggest you look into the approach NopCommerce is following where they have extended over .net with their own framework, which supports Plugins and extensions to existing solutions. Though I definitely know that nopcommerce is an ecommerce solution but if you study it, you can modify it according to your business needs or at least it can give you a heads on for what you should adopt while designing your solution. Hope it helps.
I was recently asked to create a web page using a static website generator, like Jekyll. My question is this:
How does this differ from just creating a website using HTML or writing the page as an ASP.net project in Visual Studio?
How does it work on the server?
What are some concerns I should have?
I'm a .net guy, so I would like to be able to create this in visual studio, if possible.
Here are some advantages and disadvantages that came to my mind:
Advantages
can be deployed on every server, as it's just static html
has partials, that can be reused, in contrast to normal html, where you have to code/copy paste every thing
you can still code in an IDE
a non developer can edit code (sometimes at least)
Disadvantages
the template language is limited and sometimes a bit awkward/needs to get used to
you have something new in your environment, which has additional costs (more than one developer needs to know how to build the site, ...)
If you know your current toolkit well and you do not have a problem hosting another ASP.net project on your server, I do not see the need for you to introduce another tool in your tool chain.
If you want to do something, where users can generate content - like github does on the github pages - this is something you might consider.
As for Jekyll, we tried it on one project and being devs, who like to code, we ran into it's limitations quite early. You can work around this, but if you know a programming language you will be faster. It was still fascinating, how far we were able to go with just using Jekyll
With ASP.NET pages exist throughout the life cycle of the page, and able to work with request and session context. See this article asp.net page life cycle
HTML pages are static and you can not access any variable that is on the server.
I recommend you follow the step by step this link to go to just understand how to develop ASP.NET http://www.asp.net/get-started
I hope that helped
Vicente
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
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
ASP.NET: Web Site or Web Application?
I have noticed that there is clearly a difference in what you get when you fire up Visual Studio 2008 and choose 'New Project' -> 'ASP.NET Web Application' instead of 'New Web Site' -> 'ASP.NET Web Site'. For example if you choose 'Project', then you can compile to .dll and each page gets a *.aspx.designer.cs codebehind file.
1) Why do we have these two different project types?
2) Which do you prefer?
3) Why would I choose one over the other?
4) What's the deal with the *.aspx.designer.cs files?
They have different purposes.
A website is a site with content that is likely to change over time, that is the pages themselves will change. There is no actual project file and the site is deployed simply as a set of files.
An application is a site where the content is just the application, the dynamic part will mainly be in persistant store such as a database. It will have more complex logic since its likely to represent a set of forms for data entry as much as a means to examine content. It has a project file to more strictly control its configuration and its code deployed as a compiled dll.
1) The 'web site' model was introduced with ASP.NET 2.0, the 'web application' model was the project type of the original .net framework. They both have different uses (see below).
2) It depends on the context. A good example is if you are selling a software product, you may wish to use a 'web application' project because it naturally lends itself to cleanly compiled code.
3) See above, personal preference, maintenance characteristics. An interesting thing that a 'web site' allows you to do that can get you in a lot of trouble is making arbitrary changes to code-behind (typically a *.cs or *.vb) file in notepad while the website is running.
4) The designer.cs file is used to store the auto-generated code. "This code was generated by a tool."
MSDN Article describing the differences
Similar stackoverflow question
I won't duplicate the definition of the 2, since that just got answered.
So why use one over the other?
Web Site lets you treat it like a PHP or classic ASP site, where you can make inline changes that take effect immediately.
Pros
You can make tweaks to the site right on the web server
Deploying is as simple as copying the folder
Cons
If you are not making the changes right on the live site, you can get into change management problems, where you forget to keep all your files in sync
You can get runtime syntax errors displayed to your end users, since the only way to check is to manually run every page
Web Application lets you treat it more like how you would a desktop application - there is one deployable that is compiled on your machine.
Pros
Clear, structured change management. You cannot accidently mix code from two different versions. This can be important when there are 2 people involved - one writing the code, and one responsible for putting files on the server.
Because you compile it on your machine, everything gets syntax checked at that point*
Cons
Deployment is a little more involved then just copying the folder from your development machine. However the usage of the "Publish" command greatly simplifies the process of compiling and putting together what files should be copied to the web server.
Any changes need to be done on your machine, compiled, and a whole new version sent to the web server*
*The aspx/html files are only syntax checked if you turn this on in your build options though. It is also possible to edit these files on the server unless they are compiled into your project.
The simple answers are as follows:
New Web Site - creates code behind pages that are compiled at the server when page is requested.
New Web Project - creates pre-compiled pages into one or more assemblies (entire site even), and deployed on server.
Scenario #1 - If a hacker obtains your code-behind files, any database passwords are exposed. These pages are compiled at the time they are requested. You can choose to pre-compile everything into a large assembly. If not, there is more load on the server.
Scenario #2 - if a hacker obtains your assemblies, they will be obfuscated. Obfuscated assemblies are harder to crack. These assemblies are pre-compiled, thus reducing load on the server.
For more information:
Introduction to Web Application Projects
3) WebApplication projects are buildable by MSBuild. WebSites are not (without a lot of tweaking). If you use TeamSystem with automated builds then this is the way to go.
THe biggest difference that no one has really mentioned (except touched on by Annakata) is that with the model where everything is compiled into a single DLL, your have complete control over the classes that your application generates. You know where they are and can always reference them from anywhere else in the application.
With the single page model, you can't do this. You have to get around it by creating "stub" classes in the AppCode directory, and inheriting those in your pages, but even that isn't ideal, and add complexity.
You'll only really come up agaist this stuff if you're trying to develop an intricate dynamic site, where you dynamically load lots of user-controls at run-time based on content. Then, the differences are painfully clear - hence much of our development stalled on ASP 1.1 until we could go back to the same model later.
Nich
Speaking from experience with both: "Web Sites" are used where there is no testing methodology in place, no CI server, and a culture that encourages and promotes "hotfixes" to specific pages regularly. "Web Applications" are the de facto standard where proper software methodologies are followed and there is unit testing (if not full TDD) and a CI server with a focus on writing clean code and finding bugs before the need for a "hotfix" arises.
Sites are the 2003 original .NET way of doing web dev. In my experience they are extremely problematic since lacking a project definition they can't be reused and have issues with modular coding, have issues with TeamSystem integration and namespacing. The one-to-one bind with a domain and lack of real publishing abstraction creates maintenance problems down the line.
The ancient "classic" ASP way of !codebehind is a serious problem because it again impairs code reuse and testing, and the often cited benefits of allowing hot fixes - if ever called upon - is actually a massive signal that you have a failing development process. The ability to hot fix is of course better than not being able to, but it's something you never want to invoke.
You might say that the problems with the web site model were great enough that MS gave us web apps instead. Personally I would never use them for anything beyond demo code... no actually I wouldn't even do that.
At first there was a Web application project (it behaved similarly to the current Web site project). They changed it to reflect what some users requested. However people wanted the old functionality back so they re-introduced the Web site project which behaves like the original Web application project.
I -- and my workplace -- prefer the Web site project
We like that the files of the website are the files in the file system (no need to add them manually)
No idea
Here's two articles I found about both:
http://damieng.com/blog/2008/02/07/web-site-vs-web-application
http://www.dotnetspider.com/resources/1520-Difference-between-web-site-web-application.aspx
Note: A lot of the issues with Web sites have been resolved with the Web deployment project
Update: Fixed the point 1, Web application was there first
If your work needs to leverage oo language features (class hierarchies, namespaces) or if you need to reuse common code among projects (data access, class libs etc.) then the web application project is the only way to go.
The website project (the clue is in the name) is only really good for non-complex 'brochureware' sites (where the pages consist of static content) as opposed to web applications.
There is very little difference, and I would highly recommend using the Web Site model.
The main difference is for a website, some files need to be placed in certain directories (code files need to be placed in the 'App_Code' directory), besides that, it's pretty straight forward.
If having compiled code for deployment is important to you, and you want a single DLL (opposed to the several that are created when you do a normal publish for a web site), then you'll want to get this add-on: http://msdn.microsoft.com/en-us/asp.net/aa336619.aspx