In my company we have to develop a ASP.NET MVC 5 web application which must have a number of plugins.
We want these plugins to have the following features.
Each plugin can be deployed in a separate folder; No need to copy plugin assembly to bin folder, the plugin files keep same structure as an ordinary website;
Dynamically install/uninstall plugin after website gets running;
Plugins share same master/layout;
I have found an article that describes a similar solution, but it depends on plugin framework which is based on OSGi.NET which is not open source.
Is there a plugin framework that has the above features?
Yes. MEF is very good.
This is example of how to build MVC website with plugins architecture:
http://www.fidelitydesign.net/?p=104
http://www.fidelitydesign.net/?p=130
I had the same task few weeks ago and now I have working solution, so ask, if you have more questions.
UPD
In my case I want users to be able to add extensions to the app without any dependencies or configuration files. All you need to do is copy extension's folder into the main project's extensions folder. Each extension might contain dlls, views (in separate views folder), content (styles, images etc). Moreover, each extension might have one or more db types support and this can be configured with just copying of files too. Also, my app contains some backend, and this backend should be extensible with the extensions too. So every extension have to tell the main application what it can offer for the frontend and for the backend.
I have spent a lot of time for this, but now it works very good.
Related
I recently finished a personal web application I had created for my uni. It's mine now to do with as I want. I wrote it on Visual Studio using ASP.Net, CSS, and C#. (I had originally written the first few pages in HTML and PHP, but due to a problem with my computer's inability to run XAMPP, the PHP pages weren't running as required so I redid it on Visual Studio)
The project's initial functionalities (uploading media and documentation, and login and user registration) are there and the pages work, and I plan to proactively work on it to add more features and make it more dynamic and versatile.
However, I have a question, what can I do with it now? Is there a platform (maybe Stackoverflow itself?) that I can upload the project as a whole on to add it to my technical portfolio? or maybe another such action I could do to upload or publish it to add it to my list of things done as a reference for recruiters, or as part of my project history for graduate school?
I've heard recently that you can precompile Web Application projects. My question is how?
Right now, when I do a publish for my web application and select only files needed to run this application I get it published but it still has all my ASPX pages and it will still only JIT compile the pages. How do I make it so that all of the ASPX pages are precompiled before putting them on the server?
You can download a project template called a Web Deployment Project (WDP) (VS2008 version here), which enhances the build and deployment features of Visual Studio. This basically wraps features of aspnet_compile.exe, but allows you to do this visually as part of your overall solution.
Besides pre-compilation, it also allows you do a number of interesting things, like config file replacement (great for deploying to different environments) and setting how your assemblies are built (per-page, per-site, etc.).
Two good Scott Guthrie blogs about this project type:
announcement of the tool for VS2008:
http://weblogs.asp.net/scottgu/archive/2008/01/28/vs-2008-web-deployment-project-support-released.aspx
basic walk-through of the tool
(VS2005 version, but it's basically
the same in VS2008):
http://weblogs.asp.net/scottgu/archive/2005/11/06/429723.aspx
I've used this project type for some VS2005 and VS2008 projects and it's invaluable (especially for those legacy web site projects!!).
I didn't know this was also in the MSDN library, but here's a nice article in MSDN for WDP's.
I hope this helps!
EDIT:
WDP's exist for VS2005 and VS2010 also.
Unfortunately, the way to do this isn't spectacular. You would have to "deploy" the solution locally, then move it, or just compile it on the server where it will go. Either way uses aspnet_compiler.exe. See http://msdn.microsoft.com/en-us/library/ms227976%28v=VS.90%29.aspx for more details.
When you publish the site, uncheck the option that says "Allow this precompiled site to be updateable".
This question already has answers here:
ASP.NET Web Site or ASP.NET Web Application?
(25 answers)
Closed 9 years ago.
I am reading from the following link,
http://reddnet.net/code/asp-net-web-site-vs-web-application-project-part-2/
My two confusions,
What is the so-called issue "No control over your namespaces" cons from a web site project? Could anyone show me a sample to illustrate this issue please?
What is the so-called issue "It is hard (read, nearly impossible) to reference pages, user controls, etc from custom classes in the app_code folder."? Could anyone show me a sample to illustrate this issue please?
I am using VSTS 2008 + .Net 3.5 + C#.
thanks in advance,
George
imagine a WebSite...
that is a simple web app, all alone in the world... remember, you can't add anything else to it, right...?
Now, how about a web project? that it's part of a Solution, and a Solution can have n projects, take my current work for example:
alt text http://www.balexandre.com/temp/2009-06-29_0816_so_question.png
In just one solution, I have more projects than the website, and even if they are in different directories I referenced those projects in the website and it's easy to edit, for example, the ExtensionMethods project when I need to add more.
This is something that you can't control in a WebSite, only in a Web Application Project.
The Web Application Project is like any other project, it includes all files that are in Projects like the proj extension file, and it's treated like a project, for example, you can exclude files to be compiled (you can't in a Website), it is easier to deploy because of the nice plugin called Web Deployment Project", just right click in your WebSite project and choose Add Web Deployment Project...
alt text http://www.balexandre.com/temp/2009-06-29_0825_soanswer.png
And you can deploy only this project (add it to your Web Setup, in order to create the msi file) and you will deploy a compiled website (no source code is showed, all code is compiled into dll's so you can hide the source).
There are numerous advantages to use Web Application Project over a simple Website...
Is there any difference between website and web application project? What if you are working on a project that is sort of hybrid of site and application? which project should you chose?
I'ld go the newer Web Application project (always, regardless of the size of the project).
There is nothing to lose and everything to gain with using the Web Application Project (you cannot say this about using the "website" only).
The official list of differences are here:
Use Web Application Projects when you
Need to migrate large Visual Studio.NET 2003 applications
Need to
control names of output assemblies
Need stand-alone classes to
reference page and user control
classes
Need to build a Web
application using multiple Web
projects
Need to add pre-build and
post-build steps during compilation
Use Websites if you:
Need to generate one assembly for each page.
Prefer single-page code model to code-behind model.
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
Want to open and edit any directory as a Web project without creating a project file
#Mehrdad's link here is essential if you want to know more http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
As for which project to choose, I would go with the Web Application Project, regardless of size. Having all of your code behind compile down into a single DLL is a major benefit for maintenance and security on the hosting end. I know there are precompile options for web site projects, but they seemed like more trouble that it was worth for me.
I know that the IIS filters are in place to prevent users from accessing your .vb or .cs files, but it still makes me a little leery.
But more important to this is the nice fact that if you make a bunch of coding changes, or maybe add some classes and change the processing logic, the only thing you have to merge up is the compiled DLL and nothing else. Similarly, if you do a few UI changes (say change the stylesheet or position of a few controls), you don't have to worry about recompiling the application, you simply bring over the update .aspx page and you're done.
Take a look:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
http://forums.asp.net/p/1300026/2538628.aspx
I'm used to create websites when I want to create a new webapplication.
My current project had some problems on compiling, so I switched to a webapplication project. The step isn't very hard. Visual Studio helps you to change all necessary lines.
Refer to the links in the post:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Anthony :-)
Which Visual Studio template should be used for a ASP.NET web site, the Web Site template or the Project | Web Application template?
you'd better read this:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
in my opinion it depends on what you are developing
Both function and perform similarly, but still differ in following ways:
Web application:
We can't include C# and VB pages in single web application.
We can set up dependencies between multiple projects.
Can not edit individual files after deployment without recompiling.
Right choice for enterprise environments where multiple developers work unitedly for creating, testing and deployment.
Web site:
Can mix VB and C# page in single website.
Can not establish dependencies.
Edit individual files after deployment.
Right choice when one developer will responsible for creating and managing entire website.
Web application projects works more like a traditional VS project, which has a project file, is compiled in one step and so on.
Web site projects works more like classic ASP or PHP-sites. There is no project file (references are stored in the solution file), and pages are recompiled dynamically on the server. The nice thing with web sites is that you can just ftp to the server and change a file in a text editor. You dont need VS. Some may hate that, though.
It probably depends on your background. If you are used to ASP or PHP style development, web site projects will seem more natural to you. If you have a traditional application developer background, web application projects will seem more natural.
If you're using Team Foundation Server for source control, you'll probably have to use a Web Application Project, as you need a .csproj file.
There are more details from Jeff Atwood himself: Web Site Projects vs. Web Application Projects
Web Site web projects are particularly painful in Team System due to the lack of a physical file that contains project information and metadata. For example, it's impossible to check in code analysis rules on Web Site projects, because the code analysis rules are stored entirely on the client!
I prefer a website. A website is a collection of files in a directory. It becomes more portable and deployable. A web application clouds the issue with a project file.
Personally I use web application projects exclusively now. I actually converted a rather web site to a web application because of compilation times for the web site.
I also use pre-build events to move configuration specific configuration files around and pre-build and post-build events are not available in web sites.
In Visual Studio 2015, I've come to somewhat prefer web site projects over web app projects. I still use visual studio though because you get Nuget Packaging, you can install nuget packages to both types of projects.
However a WebSite Project does not have a project file, you are literally just adding a folder to your solution.
However you can still have code, but I prefer to put it in a separate project.
In WebApp projects you have your Assets, Css, Views (razor, aspx etc), Controllers/Code Behinds etc all in one project and it just mashes together. I prefer to work with websites in two halves. The front end (css, js, images, "html/cshtml/aspx/ashx/.master/etc") and the back end (all the code).
So I create a Web Site project and a class Library to accompany it (in visual studio you can add references to the web site project). I add my class Library as a dependency and all Code is in the class Library. You can still have a global.asax, you just have to tell it that the code behind is in another dll (not the one that the site will compile to). MVC views, you just specify the namespaces like normal (the dll is referrence so the namespaces are there). And in WebForms you Just have to remember to include the assembly name with your type references that the code is in.
It's a little tedious to get use to, but when you do you have isolated structure, everything is in a place that makes sense and modularized in an easy to maintain way.
And the PLUS side is that because the Web Site is just a folder (no project file) it can be opened in Visual Studio Code easily, and other popular text editors making it easy for designers to work on the css/js/images etc (which are not in the code project). Keeping the layer designers separated, the designer sees just what they need to see.
Now structure wise. I keep my code local on my machine checked into a subversion repository using Tortoise SVN and Visual SVN (java/.net shop). To test locally I install IIS and I set the website project up in IIS locally just like I would on the dev/prod servers.
Then I install MSDeploy on the dev/prod servers and I use the Publish web app feature via MSDeploy in visual studio and I use web.config transformations. So I have web.config transformations for dev and prod and the main web.config without transformations is for local testing (so it works for all devs on the project).
To previous stated cons: Having a WebSite Project vs a WebApp Project doesn't mean multiple developers can't work on it, that's only if your WebSite Project is on some server some where and you are loading it directly from there which would be bad practice.
You can treat a WebSite Project just like any other Visual Studio project, local code, source control, multiple developers.
As a final note, an added benefit of separating your code is you can put all of your code in a shared project. Then you can create a Class Library for each port you might do, say one on straight .net 4.6 and another on .net core 5 and link in your shared project. As long as your code is compatible with both, it will build and you don't have any duplicated code files.