Im currently developing an application with two web projects (MVC):
Frontend
Backend
These two are going to have almost the same layout (few minor changes). Therefore I thought about creating a MasterPage, they can share. But since it's two projects in two different locations, where should I put the masterpage, images and javascript?
The images and javascript (static stuff), could be placed on a CDN.
But how 'bout the ASP.NET specific stuff? Any suggestions? Any help appreciated!
A MasterPage is a UserControl under the hood, so any method of sharing UserControls would work for MasterPages. Unfortunately this isn't that great of an experience in ASP.NET as the BuildManager (what compiles and connects the app paths to classes during build-time) only recognizes & processes files within the current project.
Sharing code-behind, or base classes is easy and works well. It is the design surface (.master, .ascx, .aspx) that doesn't have a lot of ability to be shared. You can use a deployment project to compile a web app project into an Assembly that can be referenced, but you will still need some design files in your actual project.
This might also be of help:
ScottGu: Creating and Using User Control Libraries
SO: How do I share user controls between web applications in ASP.NET?
It's possible to include an existing file from another project in a new project. You can do that. So just put it in one project and include it in the other.
Alternatively, you can create a 'core' library, and put things in there, but that doesn't 'play' well with controls and so on, so I'd recommend the first approach.
Related
Building large web applications in one massive ASP.NET MVC project is not easy to manage, especially with multiple developers, as you know Controllers, Models, and business logic can all be put into separate packages.
but what I want is a little different than deployment, suppose several developers are working on a ASP.Net MVC project in presentation layer so what I want is that each developer can be able to work in her/his zone and at the end give me a package which is contains controller,model,views and UI staff such as CSS,JS,pics and etc...) then I patch it into the main project without any manipulate main project, so from what I have googled there are some plug-gable architecture to do this
but as you know each of them have it's pros and cons but I am hesitant to choose better,
there are some of them listed below:
1- MvcContrib
2- MEFContrib
3- Microsoft Unity
1- I think in Unity dependency injection there is a problem, after building package we should define all interface in main project(I think UnityContainer) so it is a problem because you must change the main project and rebuild it
2- In Mef and MVCContrib there are some other problem such as memory leak and they are embed all CSS and UI staff to a dll, so think a about if we want to change one of that css file then developer should rebuild all the package.
so what you think about the above problem or is there solution to make they easier to use or I am going wrong because I am newbie to use them.
which one is better according to their pros and cons.
Thanks in advance.
I'm in the research/planning phase of a project (.Net c#, mvc or silverlight). It's a web project that offers certain services bundled into packages. The client can sign up for one of the different packages.
I'm looking for any suggestions on which architecture/framework to use for this kind of project. I want the ability to load or unload modules depending on the package. I also want to be able to enable and disable features within the packages themselves.
The modules have to be highly portable and plug-able into different clients. I know there are MEF and Prism but I haven't really worked with both. I also read about MVC and Areas. I would rather design everything from scratch and not depend on a third party if the task is simple enough. I just don't know where or how to start.
I appreciate the suggestions.
MG
You can forget about unloading. You have to use seperate appdomsins to be able to unload modules. And that's nothing that I would ever try with a ASP.NET website.
You have to get used to the thought that all modules are loaded at all times. You can use role based security to control if a user can use a module or not (one or more roles per plugin).
As for loading things dynamically: I've written an article about how you can create a plugin system using my Griffin.MvcContrib: http://www.codeproject.com/Articles/386674/ASP-NET-MVC-3-plug-in-architecture-using-Griffin-M
I am building several different asp.net mvc 3 web projects all under one solution. I'd like to be able to utilize a few views across all of those projects as they're all going to be displaying the same thing on 2 or 3 different pages (with some custom stuff plugged in per the application).
Is this possible to do?
Only thing I can think of is to compile your cshtml into a separate assembly (assuming you are using RAZOR). See here.
Generally speaking I've not seen many examples of multi project ASP.NET MVC solutions. Because it kinda doesn't make sense. It complicates things, it disregards areas, which could possibly be used to get the same kind of experience but are far better option that multiple MVC projects. Then there's the question whether the 3 projects have so much in common that they really should all be in one solution. What kind of MVC applications do you actually have? What do they do? Most sample solutions online are single MVC project and multiple class library projects.
Now to the actual question..I recently found myself doing something similar, actually I didn't have multiple projects in one solution but I had different standalone projects that would all benefit from using the Views from one single, we could say the "master" project. I ended up creating Nuget package for it. I actually also injected other stuff into the package (scripts, styles, images, etc) but you could use it for Views only too. Then you just add the package to the next project and it inserts the files in the package into destination project. What I'm trying to say is, your package doesn't necessarily have to contain code.
I won't go into details here but you should look into it.
I'm developing MVC application where I currently have 3 projects in solution.
Core (it is supposed to be for Repositories, Business Classes, Models, HttpModules, HttpFilters, Settings, etc.)
Data access (Data provider, for instance SqlDataProvider for working with SQL Server datastore - implements Repository interfaces, XmlDataProvider - also implements Repository interfaces but for local XML files as datastore)
ASP.NET MVC project (all the typical stuff, UI, controllers, content, scripts, resources and helpers).
I have no Models in my ASP.NET MVC project. I've just run into a problem because of that coz I want to use the new DataAnnotation feature in MVC 2 on my Business class, which are, as said in Core, however I want to be able to localize the error messages. This where my problem starts. I cannot use my Resources from MVC project in Core. The MVC project references Core and it cannot be vice-versa.
My options as I see them are:
1) Move Resources out but this would require correcting a whole bunch of Views and Controllers where I reference them,
2) Make a complete restructure of my app
What are your thoughts on this? Also, Should I just move everything business related into Models folder in MVC project?? Does it even make any sense to have it structured like that, because we can just make subfolders for everything under MVC project? The whole Core library is not intended to ever be used for anything else, so there actually no point of compiling it to a separate DLL.
Suggestions appreciated.
Throw it all into one big .csproj boat and use folders to separate things. Its much easier to navigate folders than separate projects. You won't have to fight namespaces all the time and everything is right were you expect it. You completely eliminate any .sln kung fu when things aren't int he right location or assemblies need to be referenced and you can spend more time coding rather than moving .sln bits around.
Some people say it makes it harder to "swap out an implementation" which is baloney. Swapping the contents of a folder is just as easy as swapping the project.
The MVC source is what made me fond of this approach. They flatten everything out and its really easy to swim around their source code.
I would like to use a WebSite project instead of a Web Application project for an MVC project.
What is the best way to accomplish this and are there signifigant problems that I might run into?
(as a side note, my reasoning for wanting this is because I have graphic designers who put files into SVN but they don't get added to the "project" and don't show up on deployment or deployment testing. My thought was that switching to a Web Site project might prevent this)
You don't need to do anything special if you are not using CodeBehind files (if you're using them, it'll be more complex but anyway, it's an MVC app. If you're using them, don't!). Just take an MVC Web app project and put all source files (*.cs) under App_Code directory of the Web site. That said, I fail to see any advantage for it.
The application project allows you to use the Models folder to embed classes into. This would then be compiled for that web project. A web site does not provide for this directly. It would require that you use an assembly project to maintain all of your classes. Rather than converting from one project type to another (which I am not sure how you wold go about doing that) you can simply attach an assembly project to your web application and not store any classes in the model folder of your application.
Having said this, you should keep your web project as an application as there usually are view specific classes that are required such as a your view model classes that belong in the web project.