I have a problem with the structure of an old asp.net webform page. Now i want to convert this into an MVC page, because i think there a several things which does MVC automatically...
Here are the facts about the software:
The software is not a "real" asp.net project, just a collaction of many aspx pages which are called with ajax (single pages for every event).
One page for "ModuleOne/save/"
One page for "ModuleOne/edit/"
One page for "ModuleOne/create/" and so on... I think you know what i want to tell you...
The software use two different languages (vb.net, c#) inside the app_code directory with two subdirectories (vbcode, csharpcode)
The software use the "yui compress plugin (js/css)", which is good but there are a lot of better plugins in mvc (do it automatically with bundles...)
The global.asax has a lot of routes to the aspx pages
Now, i want to fix theses problems with the following points:
Convert the collaction of asp.net pages to a "real" asp.net web app project
Convert the vb.net classes to one dll file and add a new reference on it
Eleminate the "yui compress plugin" and replace it with the functionality in mvc (bundles)
Eliminate the "manual routes" in the global.asax an replace this with the "controller handling" in mvc.
In my opinion mvc is the best solution to fix all theses "project-structure-problems"?!
What do you think about this solution/new structure? Make this sense?
Related
I saw some Tutorials on ASP.Net MVC HtmlHelpers and they always included the HTML directly into the SourceCode.
I want to create reusable Controls so that I don't have to write a Login view and the parts of it over and over again over the next projects.
The best thing would be if I could write a DLL and place all my created user controls therein
Some time ago I wrote an application with AngularJS and there were directives
and in them was a templateUrl. Is there something similar in Asp.Net MVC ?
I am using the Razor View Engine and the .Net Framework 4.0.
I know I could use partial views but partial views seem to not work in dlls
"The best thing would be if I could write a DLL and place all my created user controls therein" - You can. There is one little cheat which makes it all work really easily.
When you are writing your html helpers, make sure that you change the namespace to System.Web.Mvc.Html.
If you use the TagBuilder class then you shouldn't be using too much html in your C# code.
Then if you reference your dll in the project, you should be able to access the html helper from your razor view
You can use other namespaces, but you have to have to edit the web.config file inside the Views folder and add a reference to the namespace in the <system.web.webPages.razor> section. By re-using the already referenced namespace, you can save yourself some configuration hassles.
Depending on how many projects and how many developers you want to share the code between, you could also consider a build server product (My team used TeamCity for about 2 years before we needed to pay for a licence). You can then produce your own custom NuGet packages, which lets you share (and manage updates) for partial views, editor templates, html helpers and much more.
We have a corporate website with a large amount of dynamic business application pages (e.g. Shopping Cart, Helpdesk, Product/Service management, Reporting, etc.) The site was built as an ASP.Net Web Application Project (WAP). Our systems have evolved over the years to use .NET 4.5 and various custom business logic DLLs (written in a mix of C# and VB.NET). However, the site itself is still using VB.NET Web Forms. We now have done a few side projects in MVC 4 using Razor/C#, and we want to use this framework for new pages on the main corporate site going forward. What would be the easiest way to achieve this?
I found this nice list of steps to integrate MVC 4 into an existing Web Forms app. The problem is that because our existing app is a VB.NET WAP, it compiles into a single DLL, and .NET allows only one language per DLL. The site is way too big for us to contemplate converting it to C# all at once (yes, I've looked at the conversion tools, and they're good, but even 99% accuracy would leave us a huge amount of cleanup work.)
I thought about converting the existing WAP into a Web Site Project (WSP) which does allow mixing languages and then following the steps above, but after a few pages of Google results, I couldn't find any steps for converting a WAP to WSP. (Plenty of sites offer the reverse steps: converting a WSP to a WAP.)
Another idea I had was to create a completely separate MVC project, and then somehow squish them together into the same folder structure, where they would share the bin folder but compile to separate DLL's. I have no idea if this is possible, because certain files would collide (e.g. Global.asax, web.config, etc.)
Finally, I can imagine a compromise solution where we keep all the MVC stuff in its own separate application under a subfolder of the main solution. We already use our own custom session state solution, so it wouldn't be difficult to pass data between the old site to the new pages.
Which of the ideas above do you think makes the most sense for us? Is there another solution that I'm missing?
After some more research and experimentation (and thanks to a suggestion from T.S.) I have narrowed it down to either the 2nd or 4th option from my initial question:
Convert our WAP to a WSP, and then follow the steps to integrate MVC into the site. I don't see moving from a WAP to a WSP as a complete step backward. As the MSDN link explains, performance does not suffer, and it's mainly a question of how to adjust our build/deployment process. The major advantage with this technique is that it allows multiple languages to coexist in the same project and root folder. Certain files, such as Global.aspx.vb, would have to remain in VB.NET. But specific folders and web pages could be designated as C#. The disadvantage for us is that our site has a lot of legacy pages that use old-style server-side-includes of ASPX page fragmets, and these cause build errors in a WSP. These would have to be changed into User Controls, or perhaps renamed to an unrecognized extension, such as .aspxinclude, so that they are not included in builds.
Create an MVC child application as a new .NET project (see http://support.microsoft.com/kb/307467). The parent web.config needs its <system.web> section wrapped with <location path="." inheritInChildApplications="false">, and the new app's subfolder needs to be converted to an Application via IIS Manager. The child app can be a WAP using a different default language (C# vs VB.NET). This makes it is easier to isolate from our existing project. But this is also a disadvantage because the MVC routing only works on URL's in the subfolder of the child application. So if we wanted multiple parts of our site to use MVC routing, it would require separate child projects, e.g. (/cart, /myaccount, etc.)
We are probably going to go down the path of option #1, converting to a WSP, and only resort to #2 if we encounter a big obstacle.
UPDATE: I was able to do the conversion using technique #1. It's been working for several months now, so I published a blog post with the procedure I followed.
Came up with a very simple solution.
Create new MVC C# project
Add the old vb project to the solution.
Move the VB aspx pages to the new C# project
REMOVE THE CODE BEHIND ATTRIBUTE FROM THE FIRST LINE OF THE VB PAGES eg...Codebehind="ProductDetails.aspx.vb" (this is the magic)
Add a reference to the VB project in the C# project
This will work for master pages as well
Strangely the VB aspx pages 'just find' the codebehind from the reference and the C# project does not seem to care about the aspx pages being VB.
Go figure!
Hope I saved someone some time. I spent many hours on this.
You have 3 options here:
Convert the ASP.NET Web forms from VB to C#
Convert your MVC 4 written in C# to VB.
Develop all old apps in ASP.NET Web forms again to MVC 4 (ugly but better for future changes)
My advise is keep them diferent projects only share your business logic. And in the same solution file.
I tried googling, I promise! I may not be asking the question the right way. We have an existing project that is webforms (.NET 3.5 I think). It's not really a VS solution, just a folder with this structure:
/
../App_Code
../bin
../pages
../global.asax
../this.html
../that.aspx
../web.config
In the "pages" folder is where we have a big ugly mess of .aspx pages and there code behind.
App_Code holds some helper classes and whatnot. They rest should be self explanatory.
Questions:
What is the best strategy to put this mess inside an mvc4 application?
What do I have to do with routing back and forth (i.e. from .cshtml pages to .aspx and back again)
Any other considerations?
Yes, you can do it. I would recommend adding this to your routeConfig:
routes.IgnoreRoute("pages/{*pathInfo}");
It may not be even absolutely necessary, but it'll keep the request from even attempting to be parsed out in the routecollection. Just incase you have a page and a route rule that can collide. We do this for our webservices which reside in our MVC 4 application (inherited from an older website project).
That will just work.
You can mix and match any kind of ASP.Net stuff in one project.
The ASPX files will be accessible using their actual paths, just like pure WebForms project.
You can also call MapPageRoute() to apply routing to those files.
I'm absolutely new in ASP.NET.
I've got a web site running under umbraco cms (ASP.NET). I need to create a simple wizard: step by step user will answer questions using simple controls (checkboxes, dropdown lists, radiobuttons, textboxes, etc.). Some steps depends on previous answers, some of them doesn't.
So, I've got 2 questions on this:
What is the best practice to create wizard on ASP.NET web site? I looked at System.Web.UI.WebControls.Wizard class here but I'm not sure it's a good approach to mix asp.net controls and html markup together, especially paying attention to the fact, that every step of the wizard is described in one huge markup file.
I've got the samples of html markup of wizard steps (static aspx pages). That's why I want to divide html and logic. I want to be able to apply new design and markup in the future, not changing code. What is the best approach for this - dividing html and c# code?
Examples are welcome.
Thanks in advance.
I'm not new to programming but am new to Visual Studio, MVC, C#, ASP.NET, and EXT.NET, i.e. all of the tools I am trying to use.
I am trying to create an Ext.Net 2.0 MVC4 project and was given a similar (in functionality) non-MVC project for reference.
I see that this non-MVC project has .aspx and .aspx.cs files. It seems like the .aspx file basically maps to the "View" in MVC that I want to make... And the .aspx.cs file has the functions that relate to the .aspx file - so is that like the "Controller"? Though the .aspx file also has some functions that seem to not be entirely view-related...
Could someone give me a quick overview or a place to start with this?
ASPX files usually will have the UI and will which is usually HTML tags, some ASP.NET server control embed code (which ultimately produce some HTML markups). ASPX.CS file (usually called "code-behind") will have server-side coding in C#.
If needed, I would relate ASPX page to View and ASPX.CS to Controller action methods.
You have to remember that in webforms, there are ASP.NET controls we will be using in the ASPX file to render some HTML. Examples are TextBox, DataGrid, etc. In MVC, there is nothing called Server control. The View will be pure, handwritten HTML.
If needed, you can create a Hybrid project which is a combination of MVC and webforms. Scott has a post explaining about it here.
No ViewState in MVC :)
When switching from ASP.NET Webforms to MVC, One important thing you have to understand is that MVC architecture tries to stick with the truth that HTTP is stateless. There is no viewstate available in MVC. So you need to make sure that you are repopulating the data in every HTTP Request, as needed. Folks usually run into problems in loading DropDownlist in MVC. There are a lot of answers here in SO about how to handle dropdown lists on postback (when form is posted).
I suggest that you look into some beginner-level tutorials on ASP.NET MVC and start building your app step-by-step, and if you run into any issues, post a (new) question with relevant details.
Good luck, and welcome to the wonderful world of MVC. :)
It sounds like you haven't created an MVC project, but rather a WebForms project.
The *.aspx files are the markup and the *.aspx.cs files are the code-behind files. Code-behind files handle the .NET code for any server-side controls in the *.aspx files.
Checkout Wikipedia's document on ASP.NET, http://en.wikipedia.org/wiki/ASP.NET.
It states:
Web forms are contained in files with a ".aspx" extension; these files
typically contain static (X)HTML markup, as well as markup defining
server-side Web Controls and User Controls where the developers place
all the rc content for the Web page.
Additionally, dynamic code which runs on the server can be placed in a
page within a block <% -- dynamic code -- %>, which is similar to
other Web development technologies such as PHP, JSP, and ASP. With
ASP.NET Framework 2.0, Microsoft introduced a new code-behind model
which allows static text to remain on the .aspx page, while dynamic
code remains in an .aspx.vb or .aspx.cs or .aspx.fs file (depending on
the programming language used).
The .cs file names .aspx.cs is the code behind that goes with .aspx, which generally holds the html, css, javascript and other client side controls.
Generally, dynamic code (C# in this case because of the .cs on the file name) goes in the .cs file as a "good practice" to keep dynamic code and static html separated. Another reason for this abstraction is that the .aspx.cs code is run server side, while the .aspx file is compiled on the server and is then served to the web client requesting it.
Additionally, for MVC, I would suggest using a different view model, specifically Razor, which uses .cshtml files instead of the .aspx.cs and .aspx because they are easier to follow. The reason for the change in MVC is that MVC uses the MVC pattern to abstract layers of code so that .aspx and .aspxcs are not as needed. From a personal experience, I have used both Razor and Webforms (.aspx/.aspx.cs) view models with MVC and I find Razor to be much easier to code/maintain and use.
The aspx file contains your page markup. It's automatically converted into code by ASP.NET.
The cs file contains the code behind your page (initialization, event handlers, etc.). You have to write that code yourself.
These two files are related with the inheritance and he Inherits attribute of the #Page directive associates the page markup to the code behind
.aspx is your markup file. Contains things such as HTML, CSS, JavaScript, and ASP markup.
this .cs file is referred to as a codebehind file. This is where you do thing that may not be available or u are not comfortable doing in scripting languages. Generally aspx is run on the client side while the code behind is executed on the server.