I've been trying with the idea of taking an existing ASP.NET Webforms application and converting it to a hybrid so that going forward, we can do ASP.NET MVC.
In order to do this, I created an ASP.NET MVC application and started copying some of the folders from the ASP.NET webforms projects that contain webforms. I'm having a problem building the resulting project getting hundreds of compile errors of this form:
Error 1951 'Documents_Admin_DocPushByTag' does not contain a definition for
'CtlCategoryList' and no extension method 'CtlCategoryList' accepting a first argument
of type 'Documents_Admin_DocPushByTag' could be found (are you missing a using directive
or an assembly reference?)
Each of these error messages refer to server controls in my markup. It's as if the mark-up is not getting parsed? When I edit one of the code behind files and type this. to see what intellisense recognizes, these controls don't appear. The event handlers do (but that must be because they are defined in the code behind file). As far as I can tell, the CodeFile and Inherits Page attributes are correct (and unchanged from the ASP.NET project from whence they came). I'm mystified what is causing this problem. Any ideas? TIA.
check out how scott hanselman does it:
http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
basicallly, you'd use ignoreroute to exclude all of your webforms from being routed to an mvc handler
I think you'd have a lot easier conversion adding the System.Web.Mvc assemblies to your current project and updating the web.config file and global.asax.
You have to make sure your current application is a web application (not site) project. If it isn't convert it and make sure it compiles first.
Related
I have a web application that began using WebForms. We've been steadily converting each page to use ASP.NET MVC instead, and we're finally just about done removing all WebForms dependencies entirely.
Are there any dependencies that get baked into a WebForms project, but which can be removed if we're only using MVC pages?
(I've found a post talking about how to remove the WebForms view engine, but I think that's talking about the MVC .ascx-based view renderers, which we haven't entirely eliminated yet.)
How to remove WebForms dependencies from an MVC application
It's simple, 3 steps:
Ctrl+F for System.Web.UI in your entire solution. If you have more than 0 occurrences found you still have legacy code. Remove them. As a consequence of this removal your project won't probably compile => fix the compile time errors. Fixing the compile time errors doesn't mean anything yet. At runtime you might still hit glitches with some server side controls left in your views.
Ctrl+F for runat="server" in your entire solution. If you have more than 0 occurrences found in a place other than a content placeholders you still have legacy code.
Ctrl+F for HttpContext.Current in your entire solution. If you have more than 0 occurrences found you still have legacy code.
But the correct way to port a classic ASP.NET application to ASP.NET MVC is not by doing an in-place replacement. You will most certainly forget stuff. The correct approach is by starting from scratch. By using the Create New ASP.NET MVC 3 application wizard in Visual Studio and progressively migrating the code and views.
I'd like to add MVC support to an existing Website project (not a Web application project) and have a few questions.
To get Visual Studio's MVC goodness, it appears that I need to update the .csproj file's <ProjectTypeGuids> node. There is no csproj file in a website project.
It appears that I need to create Models and Controllers folder in the App_Code. Is this true? I prefer having these folders under root.
For Views should I be creating a aspx and aspx.cs files? Is cshtml razor files supported in this kind of a setup?
Any other responses are appreciated. Thanks
With asp.net MVC2 and above, the MVC team separated the core functionality into
three different assemblies, each of which extends from the common System.Web assembly:
System.Web.Routing
System.Web.Abstractions
System.Web.Mvc
With this seperation, they went ahead and made the assemblies to "work in Medium-trust server enviroments and be bin-deployable".
One of the good things about this featuere is, you don't have to have a specific project type to run MVC. You only need the assemblies, some directories and a tweaked web.config.
To do this, you need only to place the assemblies in your local bin folder of your project and make the necessary references for those assemblies.
Once this is done, you have access to asp.net MVC.
Here are some detailed instructions from the Wrox Professional ASP.NET MVC 1.0 book which should help you get started:
Including MVC in Existing Web Forms Applications
Adding ASP.NET MVC functionality to an existing Web Forms application is comprised of three
different steps:
1. Add a reference to the three core libraries that ASP.NET MVC needs: System.Web.Mvc, System.Web.Routing, and System.Web.Abstractions.
2. Add two directories to your application: Controllers and Views.
3. Update the Web.config to load the three assemblies at run time as well as registering the UrlRoutingModule HttpModule.
For reference, here are a couple of blogs/sites which have some more detailed scenarios which might help you out:
Mixing ASP.NET Webforms and ASP.NET MVC
ASP.NET WebForms and ASP.NET MVC in Harmony
Good luck, and hope this helps you out some.
I've successfully added a ASP.NET MVC 3 to Webforms project and here are some suggestions:
Add Controllers as a separate class library project and add a reference to this project from the Web forms web project
I attempted to get VS MVC support (like goto controller etc), but adding the GUID {E53F8FEA-EAE0-44A6-8774-FFD645390401} to the .csproj file didn't help.
Yes, you can add references to get the Session from your class library. You can always mock it out if you want to write unit tests.
Add Views folder to the root
Add Models within App_Code
If you are using Razor, then you need to add System.Web.Razor and System.Web.WebPages references
If you are using Razor, update the Web.config per this post
Keep in mind, you can add server controls to your view as long as they don't use postbacks (I had a lot of server controls from my webforms project that I had to use)
I believe if you set up a new MVC project and copy your web forms across to the new project, they will render as expected.
I haven't experimented with this too much but I have tried in the past out of curiosity and the web forms were still rendered OK. I guess it depends on the complexity of your project as to whether this approach would work.
This would involve changing your project type.
I have seen this work in the past if you place a Global.asax file in the root of your website. You'll need a way for your project to recognize and differentiate MVC requests from standard requests, like this:
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapRoute("Default",
"{controller}.mvc/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
}
So, an MVC url in your app might look like: http://www.mywebsite.com/mycontroller.mvc/View/5
I was tasked with updating (but unfortunately not re-writing) a legacy .Net 3.5, VB.NET (ughh) webforms, web site project and I successfully upgraded to 4.0 and added MVC3 support (with seperate code compliation folders to support C#, yah!), and it works just fine.
The #DotnetDude instructions do work, but be careful of a couple of things...
(1) When adding Razor support, this is done in the Views/Web.config file not the web.config file in the root of your project.
(2) If you do happen to add a Razor file (.chtml or .vbhtml) OUTSIDE of the Views directory, vs.net will update your root web.config with the following value
<appSettings>
<add key="webpages:Enabled" value="true" />
</appSettings>
Not good. This setting is to allow direct browsing of razor pages and when set to TRUE in my case, caused everything to break. That being said, I'm only using razor pages in my Views subfolder, however what I found nice is making AJAX calls from my .aspx pages to a controller defined in the App_Code directory allowing me to modernize an app that was mostly all postbacks, and C# to access the VB.NET written data layer.
ASP.NET MVC does not support web site template, it can only be Web Application. So you can not add MVC functionality to Web Forms project.
The message sent to browser is as follows:
The type My.API.Class is ambiguous: it could come from assembly '[on Temporary ASP.NET Files]' or from assembly '[on bin folder]'
The problem occurs when debugging a Web App, specifically when making a request to a WebMethod of a WebService.
The project compiles just right. It generates My.Website.dll on bin folder and if I publish the Web Application. It works fine.
The asmx file is on the root of the application. The CodeBehind file is on App_Code and its marked to be compiled to generate My.Website.dll.
I should be missing something really important.
I found someone having the same issue with a possible related cause. Check it out. The way this person exposes its problem is somehow similar but I get starting to be lost when he talks about a proxy class and shared dlls I don't use.
Any help is appreciated.
According to this, the App_Code folder should be used only on Web Site projects. That's the reason the CodeBehind of the asmx was compiled at runtime too.
The initial question was made based on a Web App. But I didn't specify this Web App. was been manually changed from a Web Site project.
To solve my problem I did the following:
Convert the project to Web Application. This will make App_Code to be renamed to Old_App_Code.
Moved all the Old_App_Code resources to a Class Library and then referenced this library into the Web Application.
#Tony: Thank you for guiding me.
The best way to debug issues like this is to use the "Modules" window in the Debug->windows menu of Visual Studio. It will show you all loaded assemblies. In particular, you want to look for My.API.Class in the modules list more than once. Sort the list by order loaded, and look at the dll right before it (that's usually the one responsible for the assembly to be loaded). The most likely cause of this is that one of your references also references My.API assembly, but references a different version of the assembly than your site does.
You can also fix it by adding your assembly name at the end of the attribute "Class" ex :
Instead of
<%# WebService Language="C#" CodeBehind="~/App_Code/WebService.cs" Class="WebService" %>
Use
<%# WebService Language="C#" Class="WebService, YourProjectName" %>
When you're making a web site, the assembly name is something random starting with "App_Code" but when you change it to a Web App the assembly name will be "YourProjectName".
This problem is only on development environment, so I guess my solution is better because you won't have to rename your folder (thie could cause problem with your source control).
What is the syntax/analogue for Assembly Directive http://msdn.microsoft.com/en-us/library/a7c375wt(VS.71).aspx in MVC 3.0 Razor
On MVC View i have this:
<%# Assembly Name="Web.Plugins.Authentication" %>
How i may say the same in MVC 3.0 razor view ?
More details and solution:
I did build pluggable MVC application where i am having one Main App and a lot of Plugins in it. All assemblies and views output from Plugins Apps located not in Bin directory of Main App, and in Razor case i was experienced some problems that views cant find model classes.
Finally i did come the solution for that problem. I did make output of all *.dll of Plugins Apps in to Bin Directory of "Main App".
You will not find the equivalent of the Assembly Directive in Razor.
The reason is somewhat convoluted, but it begins with the decision of the MVC team to use WebForms for the first two versions of ASP.NET MVC. WebForms are used for many more things than just views in MVC. What MVC does is simply to re-purpose the WebForms engine to render views.
On the other hand, Razor is a plain view engine. Its objective is to provide a language to describe the rendering of HTML in an MVC website, nothing more.
Perhaps if you detail what you want to achieve we could help you in more detail
Yet another.
web.config
system.web
compilation
assemblies
add assembly
MVC RazorView class(inherit BuildManagerCompliledView) is using BuildManagerWrapper.
If code base change ,implement IBuildManager.GetReferencedAssemblies method and custom WebPage Helper.
In that case all *.dll's should be located in the correct place - in Bin directory of the main project "Main App".
I'm trying to convert a Web Site to the Web Application project model and I'm running into compile errors that do not seem to be covered by the guidance I found at Converting a Web Site Project to a Web Application Project.
The issue is that standard ASP.NET controls that are embedded as child controls within the ContentTemplate of the Ajax Control Toolkit's TabContainer/TabPanel are no longer visible to the page (and result in compile errors). It appears that they can only be referenced with a call to FindControl whereas, when the project was a Web Site, they were directly accessible in the page's code behind file as properties.
Unfortunately, we have a lot of webforms that utilize the TabContainer, and converting all the references to child controls from simple property refences to FindControl calls will be quite burdensome.
While researching the problem I found a reference to a property called TemplateInstance in Single Instance Templates that seemed promising, but I understand that this is applicable to control designers, not control users. Any help would be much appreciated.
I thought I'd add one other point. The problem is not specific to the Ajax Control Toolkit's TabContainer. Indeed, I have a FormView control, and all the child controls in the ItemTemplate are no longer recognized by the compiler as being properies of the Page and result in compile errors. I can't believe that I have to change all of these propery references to findcontrol calls throughout my forms just because I moved from a Web Site to a Web Application Project. :-(
I'd be curious to hear what your final decision was to resolve this.
Reading your post, compared with my own current web app conversion research, leads me to venture out and refer you to this page hoping it may shed some light on what happens with your code-behind file upon conversion and compilation.
Did you generate a designer file for all the controls, via "Convert to Web Application..."