I'm having already existing project (of medium size) that is created using WebForms. Now I have to gradually migrate it to MVC5. I should start section by section, site by site, and at the end to got to the point where it will be fully in MVC.
I'm having intermediate knowledge of MVC and basic/intermediate knowledge of WebForms. I guess these will be the steps:
1.) to create empty MVC5 solution
2.) integrate WebForms project into new MVC5 solution
3.) make WebForms and MVC5 run side by side (make sure that old system works correctly while it's part of MVC5 solution)
4.) modifying WebForms project, section by section (site by site) and converting them one by one to MVC patterns
In theory I think I got the idea, but in the code I'm really not sure how to start the integration. All I did so far is step 1 :)
I have take a look into this link:
Combine ASP.Net MVC with WebForms, but it did helped me a lot since the blog post from #jeroenh maybe can help me in step3 but not in the step2. For step2 I have tried to apply the post from #Matt in the same link, but I end-up with a lot of errors (at his step6) and a lot of effort, so I'm thinking I'm not on the right track.
Are there some posts/tutorials related to this, step by step, that will guide the developers from doing this WebForms and MVC running side by side (but in one project and not in different projects)?
Related
this is my first question. The company I work for uses a pretty large and old vb.net site. We were hoping to integrate mvc.net into the site. I've been following a book "Pro ASP.NET MVC 2 Framework" by Steven Sanderson - and it doesn't seem terrible complicated to merge the 2 systems together.
The breakdown looks like this:
Update build file - add GUIDs to so IDE gives options for mvc files.
Add assembly references for mvc.net.
enable routing. (I need to be sure it still uses the vb.net routing first, then mvc)
Merge web.configs. (Using a new blank mvc.net vb project, also where I got the GUID from)
Add whatever folders and start using mvc.
For reference, we currently use .net 3.5, but our operations team tells me 4.0 should be no problem.
The problem I run into is that the GUID from the blank mvc project doesn't work. When I add them to the older project I get "The project type is not supported by this installation." errors. I'm not very familiar with the project types and I'm not sure how to proceed from here. I've tried several combinations to with no success.
Does anyone know how to where I can get or generate the correct GUIDs to get this working? If anyone has done this, are there any other pitfalls I should watch out for? I have the project copied to another branch, so I'm free to make changes without affecting anything else.
Edit:
These are the GUIDs from our main site project:
{349c5851-65df-11da-9384-00065b846f21};
{F184B08F-C81C-45F6-A57F-5ABD9991F28F}
These are the GUIDs from a new mvc4 project (I'm not picky about MVC2-4)
{E3E379DF-F4C6-4180-9B81-6769533ABE47};
{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}
I would suggest that you leave the current code base as it is.
You can start all your new development(new modules) in ASP.Net MVC. You can then just integrate this new module in your application. This way you can keep all the regression in respected code bases.
You will face problem only in case of session. If you are having InProc session then it would be little difficult to share. If it is already OutProc then it is easy.
I have an asp.net forms based site, and I am thinking of somehow integrating OpenForum which is written using MVC. I don't have any experience with MVC, so I'm wondering should I even bother - is it possible/makes sense to build this hybrid?
I guess you can add OpenForum like a SUBWEBSITE for the your MAINWEBSITE under IIS. It should work well because it is going to have its own BIN folder as well as web.config.
It's certainly possible. I've done it the other way around - added ASP.NET forms into an MVC site. And it may make sense (I've never used OpenForum), one could migrate to MVC this way.
If you search for "mix mvc and asp.net" there's a few resources with step by step instructions.
You can have some working side by side, but you mentioned in a comment about wanting to share master pages and user controls, and that's most likely going to be somewhere between difficult and impossible in some cases.
MVC doesn't use Viewstate which is a big part of webforms, nor does it have the concept of a postback. It's an entirely different paradigm. You can share session and also common classes and data structures, but as far as re-using view logic between them, it's most likely not going to be easy.
I have a reasonably large project at work that I've inherited. It's an ASP.NET 2005 website project and two C# library projects for data access and some business logic. The code actually runs 6 different database driven websites. It displays different images and text for each site based on logic that examines the URL and uses a series of Web.config values and switch statements.
We now have several new websites that will follow the same pattern and framework as these 6 and so management has decided that we should not reinvent the wheel and we should continue to extend the existing code. While I understand the decision from their perspective, the thought of extending this code with even more Web.config values and even more switch statements throughout feels wrong. It seems like there should be a better way to manage this particular form of complexity, but I don't have a handle on what that better way should be.
At the same time, I've been looking for a project to start learning ASP.NET MVC and I've been leaning towards re-developing this project with it on my own time since it's complex, but the requirements are in the code. I'm looking to gain 3 things out of moving it to MVC: 1) be able to test the app and all it's versions and all it's dark corners that I don't even know exist yet, 2) hopefully find a way to make managing about 12 sites on a single code base manageable and 3) learn MVC.
After rambling a bit, here are some specific questions:
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue? It's a bit hard for me to tell without having a deeper knowledge of MVC.
Is there a templating pattern or framework that I can apply (in either WebForms or MVC) that is suited for sites like these that have similar content and structure and run from the same code base?
Is there a better way than examining the URL to decide which site is being viewed and what the images and text should be displayed for each site?
Thanks for the time. I do appreciate it!
ASP.Net MVC might have some real advantages for you here. You wouldn't be manually examining URL's any more, because the Routing functionality of MVC would do it for you - so in a way, it is a "better way". Here are some advantages:
URL routing is an easy way to differentiate which site was being served, and your "which site am I" parameters would be automatically handed down to every Controller (and subsequently, every View) if you structured your routes correctly.
URL Routing works both ways, so it would be relatively straightforward for you to define a single View for all your sites that generated proper images and script references to whichever site directory you needed.
Partial Views would be a great way to switch in site-specific content in corner cases where the template wasn't exactly the same for each site.
As long as the logic was reasonably similar for each site, ASP.Net MVC 1.0 could handle this. If you need different controller logic for each site, the upcoming release of ASP.Net MVC has the concept of "areas", which would allow you to implement different sites in the same application that all had their own Controller, Model and View directories - but were differentiated by their routes.
Will MVC actually offer me better ways to manage the 12 site in 1 code base issue?
Honestly: I would not go this road. ASP.NET is powerfull enough to have a multitennant system. There are things that help to build multitennant applications in ASP.NET MVC. You have IoC for changing business rules between applications and you have the option to dynamically choose which view to render.
You have testabillity.
Thats all great: read here about it
link so
But still: It is an enourmous effort to implement such a system. ASP.NET is great (you got Routing now!) and if you have a running system better invest your time in making it better.
I really like the MVC "way" and have actually enjoyed learning ASP.NET MVC (I never liked ASP.NET Webforms but I didn't know why until now). The problem is I'm about to inherit a bunch of Webforms code and wondered if I'll be able to add new things to the codebase with MVC instead off using Webforms. I suppose it depends a lot on how authentication is set up and if the code is set up in a way that I can include some library or something and just use those function or if I'll have to recreate them or gasp duplicate them somewhere else. What should I worry about? Should I just stop messing with MVC and get working on Webforms or can I make it work together so that if I need to modify something from the Webforms codebase I can just remake it the MVC way as I move along?
I would recommend attempting to only add new stuff using MVC and convert over the legacy webforms code as you can.
This is a pretty decent post of putting them both together in the same project:
http://www.chadmyers.com/Blog/archive/2007/11/30/asp.net-webforms-and-mvc-in-the-same-project.aspx
Scott Hanselman has a post that talks just a little about it in his blog. If you want to start going down the MVC route then go for it. I think it probably depends on how big the ASP.NET Webforms app is.
Well, MVC is built on top of Asp.Net so they should be able to play well together. The question is if the data is structured in such a way that it would lend itself to using the MVC framework and ideology.
Also think about the maintainability of it -- and not just for yourself, but for others. It might be better to just stick to webforms depending on where the application state is at. If you have to start doing more work just to get the application to work, it might not be worth the hassle.
Has anyone successfully used a CMS developed for standard ASP.NET with ASP.NET MVC?
I currently use Immediacy CMS and it seems to be quite tightly coupled with standard ASP.NET, but I'd really like to start using ASP.NET MVC.
Are there any CMS systems out there directed at MVC?
How could I persuade my employer to move to ASP.NET MVC?
I suggest take a look to Kooboo (kooboo.com), a simple to use but powerful for developers. Well documented API and based upon ASP.NET MVC (of course ;-)
N2 CMS has an example site in ASP.NET MVC that I've been playing around with that works quite nicely - note that the code is now hosted on Google Code.
The problem you've got is that many CMS' already do a lot of "routing" in that the pages you are requesting/editing don't actually exist on disk, but are all in a data store of some kind, and there's an HttpHandler or ISAPI Filter sitting in front of ASP.NET to intercept the requests and work out what should be happening.
I have not personally seen any of the big name CMS systems out there upgraded yet to take advantage of many of the new things the .NET framework offers, let alone start working on the MVC framework.
As with all things, a cost-benefit analysis is the best way to convince your boss to do anything. If you can point how how moving towards the MVC framework is going to make some immediate positives (as well as many long term positives) that can outweigh the costs (in time, energy, and money) in the switchover, then you have succeeded.
ASP.NET and ASP.NET MVC are very different beasts in terms of how you develop applications on top of them. Technically, an ASP.NET MVC application is an ASP.NET application with some generic handler that invokes the core MVC framework.
The ASP.NET MVC framework is also relatively new (1.0 just released last MIX) and so it'll take a while before becoming mainstream.
How you can persuade your boss? Talk to him about the positive sides of ASP.NET MVC, and how it will improve his future business. There's plenty of material available to demonstrate that.
I do a lot of work using Immediacy (I used to work there) and I had thought about doing the same thing a couple of months ago. I think that the main issues would result from things like the plug-in handler, the idoc handler and (if your still using it) the ilink hander.
When you enable things like friendly URLS I think this would cause issues if you had similar named methods in your controller actions.
You may be able use some MVC in your project, I could see it working as an admin add-in but I couldn't see it being used to usefully in the main webroot.
I would think a CMS would have to be built using MVC in mind to get the most benefits from using the pattern, instead of trying to make it work in parallel with a pre-existing system API (limited as it is) and making more work for yourself.