I need to put my html helpers created in a separate project and I want those Helpers to be visible and usable in another project.
How we can do this .is it possible?
As far as i know if you creating your own HtmlHelper you should create static class in System.Web.Mvc.Html namespace.
So nobody forbids you to crate library type project (dll) in VS, create all your helpers there and then add refference to your MVC projects where you need your helpers.
Related
I am currently stuck trying to add my own class file into ASP.NET MVC project, so it could
be referenced by my controller. But Visual studio 2010 always complain about "The type or name 'Products' could not be found (are your missing a using directive or assembly reference?)
I am not sure where to put my class file and tried add the class to Models or Controllers directory, and it wouldn't work either. My the class is under the right namespace, and I did reference the Models namespace in my Controller. It could be something obvious, but I couldn't get it working:(
Make sure that the "Build Action" property of the file is set to "Compile" in Visual Studio. Perhaps when you initially added the file, you added it to a location or added it as a file type that did not automatically set the build action properly.
The general rule of thumb is that business objects go it the Models folder you're correct. If it isn't working you don't have the project configured correctly. In the controller where you wanted to reference the Products object, did you add a reference to Models.Products?
Are there any other errors in listed? Sometimes multiple errors in a solution can combine to create something like this.
Ensure the namespace of your class is correct.
Based on a comment to a different answer, it appears you're trying to add a utility or helper class. I suggest you put it in a Helpers folder under the root of the project.
So first add the Helpers folder under the root of the project. You should have the following structure when done (there may be other folders as well):
[project]
- Content
- Helpers
- Controllers
- Views
Now, add a new class to the Helpers folder. Call this class ProductsHelper (in the Add New Item dialog make sure to put ProductsHelper.cs, as it's asking for the file name).
Now have a look in the new ProductsHelper.cs file. Copy the namespace found in said file, to be used in the controller.
Now, add a using directive at the top of your controller that looks like the following:
using [copied namespace];
Sometimes projects are set up to use default namespaces that don't match the project name, in which case the namespace in your newly-added class file might be different than what you thought you should add as the using directive. If you're wondering what the default namespace for your project is, you can see it in the project's properties, on the Application tab, in the "Default namespace" textbox (you can change it here as well).
I had the same problem adding some utility class .cs files to my new MVC project.
I was working mostly on VS 2010 Website projects which compile differently from
Web Application Projects ( WAP ) like the MVC 3 Project.
Just to clarify Jacob's answer, In the VS Solution Explorer: right click on the class .cs file and select the Property Dialog and then set the property: Build Action to Compile.
This will force the code to be compiled when you Build the project.
HTH, LA Guy
Is it possible to distribute an EditorTemplate control ASCX along with a type in a library project and have it be used by MVC3 when the type is rendered with the EditorFor() method?
Where I work we have a lot of DateTime, Gender and a few more custom fields which have a specific but concsistent way of (HTML) input and a corresponding backing ViewModel type for them (i.e. DateTimeViewModel with separate month, day, year field etc.) and they are in a shared library project.
However we still have to copy the EditorTemplates for these types to each project which is not very DRY.
So is there a way to bundle such EditorTemplate along with the library project and make sure that it's used when the corresponding ViewModel is used without having to copy all EditorTemplate to every projects?
You need a custom VirtualPathProvider to achieve this but nothing out of the box. Here's a blog post you may take a look at.
Disclaimer: Custom VirtualPathProviders don't work with precompiled web applications. So if you intend to precompile your web application before shipping don't use virtual path providers.
Because of this limitation personally I use custom NuGet packages that allow the developers to pull all the necessary templates to their corresponding locations.
You could create your own VS Template, Export it and distribute it to all of your developers I think.
Write Templates for VS2010
You can register your own VirutalPathProvider implementation:
HostingEnvironment.RegisterVirtualPathProvider(new YourViewProvider());
Then you will be able to get your files from basically anywhere (for example from embedded resource).
Hope this helps.
I think this is not currently possible. ASP.NET MVC editor templates should be defined in a partial view file. There is no way to define them in code only.
is there any particular directory that i should put my code into in an asp.net mvc project
i have some extentions to the HtmlHelper class. Right now i have it sitting in the Content folder. is this correct? is there a better soluiton?
I usually create a separate project (or projects) for my own code, including my data layer, as class libraries. I then reference the libraries in my MVC web site.
you can put code wherever you want, but typically you want things organised. heres how i do it:
2 assemblies
MyProject.Domain
this contains all my domain code; business logic and entities
MyProject.Web
this contains controller code, views and assets like css/images
Your HtmlHelpers belong in the .Web project because they are mvc related (nothing to do with the domain). You probably want a new folder called Helpers or Extentions. Its really up to you, the key point is to decide where something belongs and to namespace it accordingly
I agree with what everyone else said, here's how one of my solutions would look like:
1- MyProject.WebUI
2- MyProject.DomainModel
3- MyProject.Test
4- MyProject.Extensions
This extensions project is new to me (actually since I knew about extension methods). It usually concludes sub-folders describing what the extension methods are used for, for your particular case, the folder name would be HtmlHelpers. I then reference this project (or its output library when using elsewhere). HTH
If you are going to re-use the same HTMLHelper extensions in different ASP.NET MVC projects, I'd suggest putting them in a class library which is completely seperate from your project.
Where do you put non-controller, non-model code, like util classes, extension methods and so on in a ASP.Net MVC project? Maybe there's not a specific place to put it, you just put it anywhere, if so, any recommendation? Any best practices?
if it's a single class i put them in a "Library" folder on the project root. If it's a bit bigger I use a specific folder and if it's something more complex i create a new project in the same solution.
According to the Kigg Sample MVC web project (You can get it from the official ASP.net), they put extension utility classes with a subfolder under root.
Good references for ASP.NET MVC Best Practice
http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
http://weblogs.asp.net/rashid/archive/2009/04/03/asp-net-mvc-best-practices-part-2.aspx
App_Code is intended for such purpose if I'm not mistaken.
Anything stored here (including in subfolders) will be accessible throughout the application.
In VS2015 Community (probably others as well but I've not checked) it's even in the context menu under Add -> Add ASP.NET Folder -> App_Code along with a few others.
My recommendation is to put them where they are used most. So if it is the controller that uses them put it with the controller, and so on.
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)