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.
Related
I'm enjoying using the well-made MVCSiteMapProvider through Nuget at the moment but I've hit a roadblock.
I'm trying to modify the template for the #Html.MvcSiteMap().Menu() helper. The file I'm modifying is ..\Views\Shared\DisplayTemplates\MenuHelperModel.cshtml and no matter what change I make to the file, the template does not update when rendered.
I've done a Find All with notepad++ and found that within MvcSiteMapProvider.dll there is two templates, one for classic asp.net and one for Razor. So clearly the template within the .dll file is being called - but how do I make this not the case?
It may be worth knowing that although the templates are located in ..\Views\Shared\DisplayTemplates\, the site is configured to use a different folder for Views.
edit: also if I pass in a template name to the helper, still no effect.
Templated helpers are an MVC creation, not one of MvcSiteMapProvider. I strongly suspect your issue is due to reconfiguring your Views folder. MVC does not support a way to reconfigure your templates folder.
But as pointed out in the accepted answer, it is possible to put them under ~/Views/CurrentController/DisplayTemplates/. You might be able to use that feature to put the templates in your newly configured folders. This means that you would need to add a copy of the templates for every single controller, though.
The best solution is not to change the MVC folders from their defaults.
If that is not an option, you might consider rolling your own Menu HTML helper based on the code from the current one that returns an HtmlString rather than using templates.
The templated helpers are better because you can edit the code after it is deployed (which is why we did it that way), but it comes with the caveat that you have to rely on MVC's default folder structure to use them.
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 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?
We have a bunch of user controls we would like to pull out of a web application and into a separate assembly/library, and I thought it would be as simple as creating a class library and pulling the ascx and ascx.cs files into the project, and compiling a DLL to be reused among our applications.
This was not the case, however.
Our ultimate goal is to have a single distributable DLL (similar to how Telerik distributes their controls) that we can throw into any web application. The steps here: Turning an .ascx User Control into a Redistributable Custom Control were very simple to follow, however this results in many files named controlname.ascx.guid.dll, which is not the desired result. I couldn't even get these to work anyways, since we have additional classes that need to be compiled into the assembly.
Has anyone successfully created a web user control library in .NET (we're using 3.5 here)? I can't seem to find a nice step-by-step guide.
I realize this is an old topic, but if anyone is looking for a solution for creating reusable user control libraries, it turns out it's fairly simple. Here are two good step-by-step guides along with source code:
From MSDN: Turning an .ascx User Control into a Redistributable Custom Control
From Code Project: Straight way to create ASP.NET user controls library
The second link provides a solution to the multiple dlls created by the first link.
Edit- (2) Seems to be a dead link. Here's the new link
https://www.codeproject.com/Articles/30247/Straight-way-to-create-ASP-NET-user-controls-libra
If you want to share controls among project, my experience has shown that the best way is to build custom asp.net server controls instead of usercontrols. User controls are good for sharing within the same project, but not over multiple ones.
For this purpose I suggest you to build a set of custom server controls inside a class library and use that on all of your projects.
This book does quite a good job at explaining the basics of creating server controls
Edit:
I'm currently developing a .net web server control library. I actually didn't follow any step-by-step guide. I mostly considered using the book I mentioned above and the MSDN library + Reflector, which is a great tool for inspecting existing MS server controls and learning from them.
I found the tutorial Creating and Using User Control Libraries but it seems like a bit of a hack as it relies on a post-build command line event to copy the user controls from one project to another.
Somewhat late, I admit.
To create a re-usable library of user controls; create a new Web Application Project, delete all the scaffolding, add a (number of) user control(s). Create a Web Deployment Project from the Web Application Project, in the WDP properties choose the option to Merge all control output and assign a name for the library and ensure that Allow this website to be updatable is NOT checked.
Build the WDP and use Reflector to examine the generated library; you'll see that it contains an ASP namespace and the types you carefully crafted have been renamed i.e. usercontrol_ascx. In your target website(s) add references to BOTH the output dlls from your WDP, add a system.web/pages/controls node to web.config using the namespace ASP and the name of the assembly that you defined in the WDP.
Now when you use the library in a page (for example) you must use the alias that you defined in web.config and the typename as seen in Reflector i.e.
<ucl:usercontrol_ascx ... />
I found it useful to add a dependancy for the website(s) on the WDP so that the WDP is built before the websites; now I can change the user controls in the WAP without having to remember to build the WAP before building the website(s).
I hope that someone finds this useful as it cost me a few grey hairs getting to this stage and still have VS do its 'automagically' thing.