I am having trouble using T4MVC VB with Visual Studio 2010 Express Edition.
I can reference the T4MVC classes in my controllers, but I cannot access them in my views (where I actually need them).
In the view, the following code is overwritten by intellisense as if the class MVC is invalid.
MVC.Home.GameBoard
It is replaced with
Mvc.Home.GameBoard
Which generates the error message 'Home' is not a member of 'Mvc'. It seems that in the view there is an Mvc namespace hiding the MVC class. This doesn't exist in the controller. How can I make this work?
Update: After playing with it some more, it seems the classes aren't available in the View no matter what they're named. What decides what classes and namespaces are available in the view? The classes continue to be available in the controller, regardless of naming as well. I presume there has to be some filter or limit on what is available in the views?
Update: I was just watching this excellent video from Phil Haack, and it game me a clue.
I need to modify the <pages> section in the web.config file. Now the question is, can I get that to use a class that's not in a namespace, as the MVC class is by default, otherwise I'll have to modify the T4 template to put it in a namespace and include that.
It seems like you're running into some kind of name conflict due to the fact that VB is case insensitive (unlike C#).
Please try going in T4MVC.settings.t4 and change HelpersPrefix from "MVC" to something else that doesn't conflict (e.g. "MyMvc"). Then change your code to use that prefix instead of MVC.
Hopefully that's all it'll take!
Related
Here is what I want to achieve, I want to separate AREAs of ASP.NET MVC as pure single DLL.
Blog.DLL
Forums.DLL
FAQ.DLL
Each of them are individual ASP.NET MVC Area, with its own default CSHTML or ASPX pages. Installing, migrating and maintaining lots of pages including resources, javascripts and so on are real pain for long run. As most of these will hardly change.
My final website will be like this.
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
Without adding any thing, just dropping Blog.dll, my application should support /blog and all its pages. If I want to customize something, than I can add area, and add only cshtml pages..
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Areas
\Blog
\Views
\Shared
\BlogLayout.cshtml <-- this will override the look
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
This will help in reusing ASP.NET Area Plugins, by simply dropping the dll in bin folder. However web.config may require some changes, but most likely we will save configure values in database and only thing needed will be "Entity Framework connection string" in web.config.
My challenges (Questions)
Is it possible? It sure looks to me, but will there be any reflection/permission issues?
How do I include cshtml/aspx views within one DLL? Probably compiled versions? I have seen couple of text template based View Engines on codeplex but I am little confused on how to actually use them.
And how do I get ViewEngine to first check if physical directory file exists or not and then look into cshtml/aspx within the dll itself as resource file?
You may take a look at the following article which illustrates how a custom VirtualPathProvider could be used in order to retrieve Razor views that are embedded into separate assemblies as resources.
Maybe worth looking at portable areas from mvccontrib. I haven't used them since MVC 2, but found the following SO question by someone having some problems using them with MVC 3, with some possible solutions: ASP.NET MVC 3, Razor Views, and Portable Areas
MvcCodeRouting supports what you want, plus many other cool stuff. Check out this post about ASP.NET MVC Plugins.
Is it possible to change around the folder organization to the following and still have MVC work.
P1
Controllers
Models
Views
P2
Controllers
Models
Views
etc..
This looks a lot like the new feature area's which is available in MVC 2 though it is currently in preview and will be release with VS 2010.
If you want to do it yourself without using areas then check out this article on view engines
as said before, the Areas feature is what you are looking for.
If you are using vs2010, then although you have MVC2, you don't have the tools for creating the areas - these are only available on vs 2008, when you install the MVC2 rc
to make it happen follow the instructions at the following link: http://msdn.microsoft.com/en-us/library/ee671793%28VS.100%29.aspx
as you can see the menu options are missing so:
download the example project from there.
build the directory structure at your solution according to the example
change the AreaRegistration.cs to match your area name
add AreaRegistration.RegisterAllAreas(); at the RegisterRoutes function at the global.asax, right after the IgnoreRoute
NOTE: the namespaces shuold contain .Areas.
for More explanations search at stackoverflow for asp-net-mvc-2-beta-single-project-area-registration-getting-http-404 (since this is the first time i post an answer - SO doesn't let me append more then 1 link, go fugure..)
Hope this helps
Should be doable, I think the default folder structure is just a suggestion. I've seen before in some documentation that larger projects would likely be split up differently, possibly even among multiple assemblies.
The only thing I would think would cause some trouble would be the views. Since controller actions are mapped to them only by file name. I know there's some way to change them, but I have not had to do so yet.
You can create your own viewengine to solve the paths. That sounds like a very strange idea, but the ViewEngine class is actually responsible for 2 things: locating a view and rendering a view to the httpresponse. The thing you have to change is the locating part, you can just inherit the default aspxviewengine and change the view locating part.
I am trying to create a .Net Library with few Controllers, and i want to reuse them in Multiple web projects.
I'm half way through, But problem i'm getting is , Whenever i add the library to the new web project , i need to copy all corresponding view files separately to the new project. Whenever i update the library, i need to repeat the steps again.
Is there any way , i can embed View files inside dll as resource , and pass it to "View()" function as an embedded resource.
What i want to achieve is , I want to put controller and corresponding views inside single dll file, so that i can easily distribute/manage the library as a single dll file
( Oneway i already found , is creating custom view class with IView Interface and Render the output directly by writing to HTML Output Writer, But i prefer to use the View file.)
Phil Haack just posted a blog post a few days ago that would probably help you; He's using a database to store the views and ruby to process them, but I would think you could take his prototype and make it work for views stored in a separate assembly fairly easily.
Just a quick glance through the code and I think the magic sauce is going to be implementing VirtualPathProviderViewEngine (See the "RubyViewEngine" class for example) and inserting your ViewEngine into ViewEngines.Engines Collection (see Global.asax.cs).
You can probably use a VirtualPathProvider for this.
The WebFormView type eventually calls BuildManager.CreateInstanceFromVirtualPath. There is not an overload or other function in BuildManager to take input from a stream instead of from a virtual path. Therefore, if you do not want to implement IView yourself, you will need to actually unpack the files to disk so that they can be compiled by BuildManager. You could still distribute your DLL as a single file, but the aspx files need to be produced in order for BuildManager to compile them. See BuildManager help for details.
Check out the ASP.NET MVC View Engine using VB.NET XML Literals project on CodePlex http://vbmvc.codeplex.com
It is a custom view engine originally conceived of by Dmitry Robsman, who is a PUM for ASP.NET at Microsoft. Each view is a VB.NET class and the Namespace (instead of file path) is used to connect Views to Controllers. It's fairly straight forward to copy the content of your ASPX view files into the XML literals in these VB classes. And as classes, they are compiled into the assembly without any extra effort.
If your controllers are C#, then most likely you'd end up with 2 DLLs, but Scott Hanselman has a blog post on getting C# and VB to live together in the same assembly. http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx
Take a gander over to codeplex and have a look at the Managed Extensibility Framework
Once your done there...
See what Maarten Balliauw has to say about ASP.NET MVC and the Managed Extensibility Framework (MEF)
Trying to create a MVC User Control in the Release Candidate and I can't see to make one with a codebehind file. The same is true for MVC View pages.
Creating Views in the Beta would produce codebehinds...am I missing something?
Code behind kind of defeats the purpose of the MVC Framework. Functionality should be kept separate from the view, the MVC team felt that code behind pages went against this ideology and therefore removed them.
Your can create a custom helper method to create your control. Also I'm not sure if MVC has view components (Monorail/Castle) but that could be an option as well.
From ScottGu's Blog post:
*Views without Code-Behind Files
Based on feedback we’ve changed view-templates to not have a code-behind file by default. This change helps reinforce the purpose of views in a MVC application (which are intended to be purely about rendering and to not contain any non-rendering related code), and for most people eliminates unused files in the project.
The RC build now adds C# and VB syntax support for inheriting view templates from base classes that use generics. For example, below we are using this with the Edit.aspx view template – whose “inherits” attribute derives from the ViewPage type:
One nice benefit of not using a code-behind file is that you'll now get immediate intellisense within view template files when you add them to the project. With previous builds you had to do a build/compile immediately after creating a view in order to get code intellisense within it. The RC makes the workflow of adding and immediately editing a view compile-free and much more seamless.
Important: If you are upgrading a ASP.NET MVC project that was created with an earlier build make sure to follow the steps in the release notes – the web.config file under the \Views directory needs to be updated with some settings in order for the above generics based syntax to work.*
I answered this question here:
How to add a Code-behind page to a Partial View
Seems this wasn't particularly tricky, and is quite do-able
This answer worked for a Partial 'ViewUserControl' but the same should apply
Ok.
First: Add a Class file with the convention of .cs (i.e. view.ascx.cs)
Second: Add "using System.Web.Mvc;" to the class
Third: Change the Class to Inherit from "ViewUserControl<>"
Fourth: Add the following to the View's header:
CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"
Fifthly: Copy the files out of the solution and drag back in to reassociate the two together
Note: For this to work with a Normal MVC View you just need to inherit the class from "ViewPage"
The whole idea for ASP.Net-mvc was to get rid of the codebehind files...thats why asp web controls didnt matter that most didn't work.But with the changes of getting rid of the code behind comes with a different programming style..The idea is codebehind files are EVIL:
http://stevesmithblog.com/blog/codebehind-files-in-asp-net-mvc-are-evil/
the whole idea is to make sure people remember they are using asp.Net-mvc and not asp.et web pages. take alook at this link ,it explains it a little better:
http://blog.lozanotek.com/archive/2008/10/20/Visual_Studio_Templates_for_MVC_Views_without_Codebehind_Files.aspx
I think this tutorial is what you are asking.. but not really sure what you want..
I have been using ASP.net MVC for a new website.
I have found a minor nagging issue with having views with the same name but are in different folders i.e. Views/Home/Index.aspx and Views/Account/Index.aspx
The codebehind files act as if they are partial classes when there is a definition for the same event or function (i.e. PageLoad event). I have avoided this issue by explicitly providing a Namespace to the codebehind file (using the Folder name) and updating the reference in the markup page.
But like i said, this is annoying. Is there something i'm not doing correctly? or is this just a bug in beta software?
No, this is not a bug in the beta software. It has nothing to do with MVC specifically or ASP.NET in general. Essentially, your problem boils down to you wanting to have two distinct classes with the same name. The only way to do this is to put them in different namespaces.