I have a module in my project that I want to share with another project in the solution. It consists of several controllers, models, and views.
I want to avoid seeing copy-pasted files.
I have done some research into this and seen some old solutions of portable areas using mvc-contrib. Does this work in MVC 4? Looks like it doesn't.
I've had a play with nuget and created a package, and it packages up the compiled stuff nicely but it copies the views into the project. What's to stop someone editing those views instead of updating the source project and repackaging?
Does anyone have a solution for this?
This is what I was looking for http://razorgenerator.codeplex.com/
See ASP.NET MVC Plugins......
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 have refereed old questions and found that people face many issues after installing mvc3 and MVC4 on same machine.
My question is how is your recent experience for the same and how the mixture works for you guys.
I want to create one solution which will have four projects out of them two are MVC projects. One is MVC3 and another is MVC4.
Let me know your views on this.
Thanks,
Jigar
In short - there shouldn't be a problem. Once 3 & 4 are both installed, the two use different project templates and the references to the MVC assemblies are specifically targetted at the correct versions.
Beyond that, the web.configs of the two sites then determine the other assemblies that are used - and since they are seeded by the project templates they will be correct.
Now, if you were asking about having 3 & 4 in the same project, that would be another story. But then you wouldn't do that.
It's true there are a few known issues with the Razor editor and stuff like that - but none of those are show-stoppers and are almost certainly likely to have been fixed by the time v4 RTMs.
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 created a blank webforms project instead of an MVC 3 project in visual studio, everything runs fine but i dont have my menues
for example when i right click on the Controllers folder i dont get "Add a controller" option.
does anyone know without starting a new project how to change the type of project into an MVC one so that i get the correct menus.
thanks
It's not that you don't have the menu options, it's that it's a completely different type of [web] application and works in different ways. e.g. Webforms has no concept of controllers so even if you did have a menu option it wouldn't get included in the project as you're expecting.
Because webForms and MVC are so different there could never be a 100% reliable conversion utility.
Just create a new project and copy the files already created. I can't imagine you've written that much code before realising that you're in WebForms, not MVC.
If you have got lots of WebForms code you could always just include this in the MVC project until you can convert it (if necessary) at a later time.
Edit:
If you just want to change the project type you can edit the csproj file of the webforms project and add the following ProjectTypeGuid {F85E285D-A4E0-4152-9332-AB1D724D3325};.
You'll need to update references, files, etc. for this to work but it may be quicker than creating a new project and copying content over. (Especially if you already have the project in source control.)
Note that I've only tested this going from WebForms 4 to MVC2.
Try updating a MVC to ASP.NET Fall Update Release Candidate. There is a link .
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.