I have been looking for an solution for structuring my MVC5 project, but have not found anything yet.
What i look for is. I have an Main Website, which off-course has it's own Views, Scripts and Controllers, but what is special is that i like to have sub Website projects which add an menu point in the main page, but the sub website also contains it's own Views, scripts and Controllers( I have tried to draw a picture of what i'm talking about ).
The point of this is to have an structured in a easy way. But also to reuse the same views in a framework way.
You should be able to define an area in another project, found an article that explains in detail how it is done in MVC3, it should not be very different in later versions since areas and routing haven't changed a lot.
http://nileshhirapra.blogspot.no/2012/02/aspnet-mvc-pluggable-application.html
Update: you do not actually need to set up the project in the Areas folder, but you need to copy all content like views and scripts/css into there before being able to use it in the main application.
If you want these sites to actually be separate websites but only look similar, then that is what you'd need to set up. You'd probably want to decide on a single-sign-on scheme for that.
Related
I have a WebAPI/MVC app which loads separate plugin assemblies with embedded controllers and views and puts them into the MVC PartManager. This works fine but now I'd like to be able to swap these parts out in runtime without restarting the server. I can use PartManager.Remove on the old part and Add with a new part, but this does not seem to be enough. When calling the controller I still get a response from the old controller in the old part.
Apart from adding parts in the PartManager I also add a EmbeddedFileProvider into the RazorViewEngineOptions on Configure because just adding an AssemblyPart does not seem to be enough for the Razor engine to find the view (not sure I'm doing this right). But I don't know if I can replace this Razor-fileprovider in runtime? I have not found a way.
Anyway, what is the preferred way of doing all this, I mean loading/replacing dlls with controllers, views and static resources. Am I on the right track even?
i think that Razor view engines are configured once only, so you cannot change them later.
What you can do is to
have multiple view engines running,
choose between them based on the URL (as in your case - you want to use a different engine for the one controller).
This is described in CUSTOMMOBILEVIEWENGINE section of Scott Hanselsman's blog post. What he was doing was to use different view engines for different devices, but you can adapt the technique for your own purposes.
I've got the following project setup
Project A (main)
Business
Data
View (asp.net mvc 3 project)
Project N
Business
Data
View (asp.net mvc 3 project)
How can I call from Project A the View in Project N and from N back to A. Essentially what I'm trying to do is package each Project N to have its own individual MVC as it comes from different sources and plug it in to the main project and then just have it navigate to the correct view.
Can this be done? Or is there a better way to do this?
You could write a custom virtual path provider. Here's a nice blog post which shows an example of such a virtual path provider allowing you to embed Razor views into assemblies as resources and reusing them in multiple applications.
Unfortunately without a custom virtual path provider, you cannot cross reference views between multiple ASP.NET MVC applications. This simply is not allowed by the default provider which looks for views only inside the current application.
I do sugest another approach if possible. if I understood correctly, those projects are somehow ike plugins but they are not standalone applications.Also they now about each others so they are coupled. It's, let's say tricky, but I would use only 1 asp.net mvc project (the web ui). All the UI bits which belong to other projects I'd make them helpers (pretty much widgets). This means, that each project contains only the helpers which will be used to construct a view.
I think it's a bit of an architectural problem if you only want to keep the views in each project just for the sake of hosting them in a different assembly. Going the widgets' way it might seem mkore work, but I think you gain the most control and the separation level you want. The only thing is you don't have full Views defined, but why you would want to have full Views (partials, layouts) in separate places if they will be used in one place only?!
Now, if each project is indeed a plugin, independent of other plugins, then going with compiled views is the best way. But if Project B knows about the view of Project N, then I think the above solution is more suitable. That or the whole app is too over engineered. Separation is good when it doesn't create a whole new jungle to navigate it.
N00b here. I've been looking around for a bit on how I might accomplish this but have not had much luck, and am hoping for some code examples.
I am using a plugin architecture that is working pretty well. It "discovers" other assemblies (web projects) and then compiles them into the current website's "Areas". Here is the code I am using (for reference) Click Here.
For some of these plugins I am faced with a choice: I have 3 services that would use a plugin, but are unique in some way as to not make the plugin totally reusable. I could just create 3 spearate plugins and pull them into the 3 different main web apps. But then I thought to create an Area within the plugin and got it to work (in that the extra Area is picked up and put into the main website (so Area > Area). I felt the latter approach would work so I created 3 areas within the plugin, with common code being in the main part of the plugin, and each 3 areas having code/views specific to the 3 services.
Now, where I am stumped is in figuring out how I might be able determine which of the 3 services' areas to use when a user is on one of 3 separate websites I have. I can create 3 separate Main apps and pull in the plugins no problem. Each of the 3 websites will have it's own Database, so I started to think that if there was some way to determine which DBContext is being used from the main site then I could determine which of the 3 areas to use within the plugin.
I thought maybe that the main controller of the plugin could have some if/else logic, or some other class file in the root of the plugin could handle that. This is where I need help. Any examples would be much appreciated.
EDIT: Going to try and show the folder structure:
-Plugin1
-...
-Areas
-One
-Controllers, Views, etc.
-Two
-Controllers, Views, etc.
-Three
-Controllers, Views, etc.
-Controllers
-Views
-...
-Website1
-...
-Areas
-Plugin1 <- hidden files in VS2010, created by plugin architecture
-Areas (from Plugin1)
-One
-Two
-Three
-Views (from root of Plugin1)
-Controllers, Views, etc.
I've inherited an MVC3 project that has a large number of ASPX views that I would like to convert to Razor. This question => Aspx to Razor syntax converter? is similar to mine, and it helped me find a bunch of options for converting the views themselves, but I'm unclear on the steps I need to take in addition to converting the views.
The first known limitation of Telerik's razor-converter is "The tool only works with views and does not deal with the project structure and master pages". This tool claims to be able to convert master pages as well, but it doesn't look like anybody beyond the developer has ever used it.
I think these are the steps I need to take:
Use a utility to convert the views
Convert the master pages manually (how do I do this?)
Modify the project structure (what needs to be modified?)
Delete the ASPX files
Test the application (any specific gotchas I should look out for?)
Are these the right steps? Can you help me with my questions on steps 2 and 3?
I have only tried this on one solution and the actual conversion did a fairly good job. I downloaded the Telerik converter project, compiled it, and then converted my projects using these command lines:
aspx2razor C:\Development\MyProject\MyWebProject\*.ascx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.aspx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.master C:\Development\MyProject\MyWebProject -r
I only needed to go back to add an #include for a namespace here and there, and to add a few parenthesis to force the Razor view engine to recognize my inline code properly. This was also a fairly simple solution, so YMMV. But even if it converted 80-90% of your views successfully, it's that much less manual work which you would have to perform yourself. From here, you could also create a _ViewStart.cshtml file and make a few minor adjustments to take advantage of Razor-specific layout features. (Check out Scott Gu's post on it here: http://weblogs.asp.net/scottgu/archive/2010/10/22/asp-net-mvc-3-layouts.aspx)
The big issue I had was trying to reconcile the file changes with source control. Since the classic MVC view engine uses .aspx, .ascx, and .master extensions, I had to manually add the .cshtml files to my MVC web project and source control then remove the old versions. It wasn't difficult, just time-consuming.
In addition, you may need to add all of the necessary web.config entries to support the Razor view engine as well if your project was created using MVC 1 or 2. Projects created with MVC 3 should already have these entries in place, even if it was not originally created as a Razor site.
Is it possible to change around the folder organization to the following and still have MVC work.
P1
Controllers
Models
Views
P2
Controllers
Models
Views
etc..
This looks a lot like the new feature area's which is available in MVC 2 though it is currently in preview and will be release with VS 2010.
If you want to do it yourself without using areas then check out this article on view engines
as said before, the Areas feature is what you are looking for.
If you are using vs2010, then although you have MVC2, you don't have the tools for creating the areas - these are only available on vs 2008, when you install the MVC2 rc
to make it happen follow the instructions at the following link: http://msdn.microsoft.com/en-us/library/ee671793%28VS.100%29.aspx
as you can see the menu options are missing so:
download the example project from there.
build the directory structure at your solution according to the example
change the AreaRegistration.cs to match your area name
add AreaRegistration.RegisterAllAreas(); at the RegisterRoutes function at the global.asax, right after the IgnoreRoute
NOTE: the namespaces shuold contain .Areas.
for More explanations search at stackoverflow for asp-net-mvc-2-beta-single-project-area-registration-getting-http-404 (since this is the first time i post an answer - SO doesn't let me append more then 1 link, go fugure..)
Hope this helps
Should be doable, I think the default folder structure is just a suggestion. I've seen before in some documentation that larger projects would likely be split up differently, possibly even among multiple assemblies.
The only thing I would think would cause some trouble would be the views. Since controller actions are mapped to them only by file name. I know there's some way to change them, but I have not had to do so yet.
You can create your own viewengine to solve the paths. That sounds like a very strange idea, but the ViewEngine class is actually responsible for 2 things: locating a view and rendering a view to the httpresponse. The thing you have to change is the locating part, you can just inherit the default aspxviewengine and change the view locating part.