Has anyone been able to create an Asp.Net Mvc plug-in implementation using MEF (or some other IoC tools) that does NOT require the Razor views to be compiled into dll's? Ideally, I'd like to be able to deploy Razor view changes by simply dropping new files in a folder rather than having to recompile and drop new dll's. Any ideas?
By default views are not compiled so you should be able to do this without any extra work.
Related
Visual Studio 2015 + all updates.
Asp .Net Web application (MVC).
I start off by adding a few class libraries and separating the Asp .Net WA into layers i.e. DataAccess, Business Logic and the web project itself.
Once separated I add relevant references and everything is working as I expect it to be (i.e. the application functions as it did before I separated it into layers).
In my BL (Controllers are found here). I don't have the option to Add a Controller, like you would when right clicking the Controllers folder in the default project, so add the below line
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
to the csproj file for my class library and the Add Controller option now appears. Create a controller but throws an error which was due to not having a web.config file - add this file and all works (although it would be nice to have this library working without a web.config file).
The problem I've hit is, when the Controller is created it also adds a View template within the class library but my Views folder is located in my web project.
Have I done this wrong? Is there a workaround so when a controller is created, it also creates the Views into the correct project? Or another approach for this?
This is just a guess, but it seems like you are try to use a UI-based architectural pattern to build your business layer.
Typically, your models, views, and controllers are all maintained in the main web-app project. Any supporting functions (like your BL and DL) are added via class libraries. The Visual Studio MVC templates are built around that concept, which is why you had to manually add support with the GUID - and why it automatically creates the view.
If I may ask, why are you trying to build controllers into your BL? If you are trying to decouple your UI from your server code, perhaps WebAPI would be a better option.
UPDATE - A few helpful links
ProDinner - ASP.NET MVC Sample App
N Layered App with Entity Framework, Autofac, ASP.NET MVC and Unit Testing
Architecture Guide: ASP.NET MVC Framework + N-tier + Entity Framework and Many More
Most of your issues boil down to using the scaffold. The scaffold is great when you're just starting out or for extremely simple projects, but it quickly falls down beyond that. Specifically, adding a controller via scaffold is designed for an MVC project, so it expects to find things you'd find in an MVC project. Additionally, it creates scaffolded views in an appropriate directory in Views because, again, that's what it's designed to do.
The simplest solution, then, is to just not use the scaffolds. A controller is just a class that inherits from Controller. Nothing special there. Then, you can create the views where you want to create them.
Is it possible to add Razor views to a deployed .NET MVC site? How would you do this?
CSHTMLs are not binaries like controllers. Assuming the existing site is already set up to use Razor files then yes, you can drop them in there and they work as expected.
If you have to change controller/ action method code to actually use this view you would have to recompile and redeploy the bin directory.
Not possible but first build your project with adding new .cshtml file and then adds on specific folder where you want on deploy.
I will say yes.
In asp.net, there are 2 different build. Project build and dynamic build.
Project build is the normal build u see on other types of build. Generating doll or exe.
Dynamic build is the build when for cshtml related files. It is built by triggering it. So, ideally, u can replace cshtml or add cshtml. And it will work for the iis.
Hope this answered your question.
I have several websites and these website share several components. It was quite easy with classic ASP.NET WebControls ascx. I created several such controls, put into one dll library and I reference these libraries from these websites via namespace.elements runat=server...
But I don't know how to do it after I have upgraded to ASP.NET MVC. I can put model and cotroller class into dll.
But how should I put and reuse Views into dll?
I suppose that Views are not compiled into dll, if I can change the View without recompiling the dll.
EDITS:
I would prefer some standard solution over third party. The last solution for me is to use StringBuilder instead of ViewEngine.
I've been using Razor Generator for several years to store reusable MVC views and helpers in separate .dll.
Razor Generator "is a Custom Tool for Visual Studio that allows processing Razor files at design time instead of runtime, allowing them to be built into an assembly for simpler reuse and distribution."
Installation instructions
It’s on the VS extension gallery, so install
it from there. It’s called “Razor Generator” (not to be confused with
“Razor Single File Generator for MVC”).
It is quite simple to use:
Usage in an MVC app
Install the 'RazorGenerator.Mvc' package, which registers a special
view engine
Go to an MVC Razor view's property and set the Custom tool to RazorGenerator
Optionally specify a value for Custom Tool Namespace to specify a namespace for the generated file. The project namespace is used by
default.
Optionally specify one of the generators in the first line of your Razor file. A generator declaration line looks like this: #*
Generator: MvcHelper *# . If you don't specify this, a generator is
picked based on convention (e.g. files under Views are treated as
MvcViews)
You'll see a generated .cs file under the .cshtml file, which will be used at runtime instead of the .cshtml file
You can also go to the nuget Package Manager Console and run 'Enable-RazorGenerator' to enable the Custom Tool on all the views.
And to cause all the views to be regenerated, go to the nuget Package Manager Console and run 'Redo-RazorGenerator'. This is
useful when you update the generator package and it needs to
generate different code.
MVC project should be chosen for class library in order to support intellisense and other useful features.
Usage in a View Library
If you need to create a separate library for your precompiled MVC
views, the best approach is to actually create an MVC project for
that library, instead of a library project. You'll never actually run
it as an Mvc app, but the fact that it comes with the right set of
config files allows intellisense and other things to work a lot
better than in a library project.
You can then add a reference to that 'MVC View project' from your real
MVC app.
And note that you need to install the 'RazorGenerator.Mvc' package
into the library, not the main MVC app.
Programming ASP.NET MVC 4 written by Jess Chadwick tells that
In the ASP.NET Web Forms world, you can achieve this by creating user
controls or custom controls that can be compiled into standalone
assemblies. These assemblies can be distributed across projects,
thereby enabling their reuse across projects.
The Web Forms view
engine offers the ViewUserControl class, which can be leveraged to
create such components for the MVC framework. The Razor view engine in
ASP.NET MVC, however, does not offer any such method out of the box.
and suggests using Razor Single File Generator visual studio extension, another one but the similar to Razor Generator approach.
I've developed a most reusable ASP.Net WebUserControl for our company's web applications. I'm now going to make it as a redistributable DLL according to this msdn topic. Since the WebUserControl comes with some JavaScript(s), CSS(s) as well as images. I'm asking how can I bundle them all together to form a single DLL?
Our development environment is Visual Studio 2008, .Net Framework 3.5
Please kindly advise!
Thanks!
William
You could bundle the non source code parts in a resource file and reference them through there in your ASP.NET code. You could add to the default resource file (.resx) or add your own..
I haven't actually tried this but I think you could embed the user controls, JS files, etc into the output assembly of your reusable library project. Basically in the Properties dialog you'd set the "Build Action" to "Embedded Resource" for those files instead of "Content".
Then the consuming application would implement and register a VirtualPathProvider to tell ASP.NET to look for user controls inside the assembly.
Here's a similar question dealing with loading MVC Views from a DLL, same idea: Using VirtualPathProvider to load ASP.NET MVC views from DLLs
And this: http://www.wynia.org/wordpress/2008/12/aspnet-mvc-plugins/
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 :-)