I have a few MVC3 projects that uses the same partial views. These views contain parts of forms that i can easily reuse in other MVC projects. is there a way to centralize Views. Like, in another project perhaps? So i can add the assembly of the project and easily call the views i need?
Otherwise i have to copy the reusable views folder every time i start a new project. And when i make a change to one of those views, then i have to change it in all the other projects too. Would be better if i could put it in one place and reference to it somehow.
Is this possible?
The easiest solution is to simply map a shared virtual folder in your views folder, using IIS's virtual folder feature. That way all apps that use the same views will actually point to the same physical folder.
You may have some challenges with deployment, and you could make the shared folders part of their own project. But you will need to deal with that both on the local dev machine and the server.
Related
I'm working on a web site project. I have inherited a C# class file that I would like to put in a DLL, but the class references classes that reside in the App_Code folder. Is is possible to access App_Code classes from a DLL?
Thanks
ASP.NET websites - as opposed to ASP.NET web projects - are compiled when executed. So when you build them you won't see a .dll output in a bin folder that you could reference from anywhere.
But it wouldn't make sense to use a website as class library anyway. If it contains classes that you need, it would make sense to pull them out of the webiste. That means
create a new class library project
move the class files from the website into the new project
make whatever adjustments are needed to for it to compile.
How well this works may depend on how tightly the code is coupled with the website project in which it lives. For example, a class might look for values in HttpContext.Current. If that's the case, the class won't work outside of a website as-is. You'd need to modify it to get inputs differently. (Without seeing the code, it's hard to know whether this will be trivially easy or tedious and frustrating.)
Hopefully if the classes aren't too coupled to the ASP.NET environment you can remove them from your existing website and even that website can use your new class library.
We have a big project developed in Asp.net MVC5. Our models and business logic are defined in separate class libraries. Now we need to add another module to an existing project but we want a separate dll.
This module also shares the most javascripts, css files and other files. That is the reason we don't want to separate MVC project.
Is there any why we can create separate dll for module basis. so we don't want deploy or touch other dlls.
From your description, you say that the projects share CSS and JS files. This leads me to believe you are talking about a separate MVC website (possibly part of the larger corporate website). This can be easiest with the use of Areas. If you are not familiar with Areas, please read the following: https://msdn.microsoft.com/en-us/library/ee671793(VS.100).aspx
Of course using Areas will require you to deploy the whole site everytime one of the areas change, and you have mentioned that you want to avoid doing so.
If you don't want to use areas, and instead want to create another MVC project in the same solution, you can do that easily too. You can right click on the solution, add new project > ASP.NET web application > MVC to add the project. To share JS and CSS files between these two MVC projects, you will have to create a new solution folder (right click solution > Add new solution folder), and move your resource files to that folder. Inside each MVC project in your solution, you will add existing items and select those js/css resource files. This way if you change the css file, it will be reflected in both the projects.
For more information, read the following:
How do you share scripts among multiple projects in one solution?
Yes you can, just add the logic classes to other class library project (you can have as many as you want), then add references of those class librarys to the mvc project.
Don't forget to import the classes after in your code
Edit: I'm assuming you are using Visual Studio, if yes, you can go to File -> Create Project, this will create another project in the same solution.
I don't know whether you tried with Managed Extensibility Framework (MEF) or not.. this framework works as you required ... I think below link will help you more
ASP.NET MVC Extensibility with MEF
How to integrate MEF with ASP.NET MVC 4 and ASP.NET Web API
http://www.codeproject.com/Articles/167321/MEF-with-ASP-NET-Hello-World
Other people have posted answers regarding the use of Areas. Areas are great and good and helpful. They really benefit the project structure.
This module also shares the most javascripts, css files and other file
The title of your question is about .dlls, but I suspect the client-side resources are the main concern.
If you consider your webapp as having two distinct parts: server-side and client-side, you can use appropriate strategies to modularize each. Areas a great for organizing server-side code, but don't help the front-end.
Front-end package management options have expanded for ASP.NET 5. In addition to the traditional NuGet package manager, Bower and NPM are now supported. For example, consider how this article demonstrates installing jQuery via NPM. Here's another good article about setting up NPM, Bower, and Gulp in Visual Studio.
What to do: Take your existing client-side code and make a custom NPM or Bower package, and then use that package from one or more Asp.NET projects.
I can suggest you two ways to organize your multi-module project.
Option 1 - Create Area per module, within same web project
One way to do it is, create separate Area within the same MVC project. So each module will have a separate area, with separate controllers, views, scripts etc. But,
(1) This will still create a single dll for the whole MVC project
(2) Sharing files across areas might not be very easy in some scenarios (you can keep all the scripts for all the modules in one shared directory though)
Option 2 - Create class library per module, merge after build
Another way is to create a single class library project per module. Add reference to the System.Web.Mvc and other libraries so that it can have controllers etc. Create your own views, scripts and other folders and populate with files as you need them.
Now, all your modules will build as separate projects, with the dll file and the javasvripts, htmls, csss, images etc. To make them all work as a single web application you can create a (only one) MVC web project, which will go to the IIS virtual directory and will be published as web.
To use all your separate modules from the same web, you can write post build events in all those libraries to copy the artifacts (dll, scripts etc.) into the main web, into corresponding folders (dll to \bin, javascript to \scripts etc.). So, after successful build, all the artifacts are available in the same web project, and that can be deployed as a single web with all the modules. Your post build scripts should look something like this
XCOPY "$(ProjectDir)$(OutDir)*.*" "$(ProjectDir)..\YourMainWebDirectory\Bin\" /Y
XCOPY "$(ProjectDir)Content" "$(ProjectDir)..\YourMainWebDirectory\Content\" /S /Y
XCOPY "$(ProjectDir)Scripts" "$(ProjectDir)..\YourMainWebDirectory\Scripts\" /S /Y
XCOPY "$(ProjectDir)Views" "$(ProjectDir)..\YourMainWebDirectory\Views\" /S /Y
XCOPY "$(ProjectDir)Images" "$(ProjectDir)..\YourMainWebDirectory\Images\" /S /Y
Now,
(1) You have separate dlls for separate modules
(2) Can directly share scripts and other files, as they will be in same location (after build)
(3) If you decide to remove a specific module from the web, just remove the post build event from that module (project) without affecting anything else. You can add that back at any time you please.
Your overall solution will look like
Module01.csproj => post build copy to main
\Controllers
\Scripts
\Views
\Contents
\Images
Module02.csproj => post build copy to main
\Controllers
\Scripts
\Views
\Contents
\Images
Models.csproj
\...
Application.csproj
\...
Main.Web.csproj => main web application hosted in IIS
\Controllers
\Scripts
\Views
\Contents
\Images
I've read in other posts that you can put the business logic in a VS2013 MVC project "anywhere", which I take to mean "possibly outside the Controllers folder".
However, when I create an App_Code folder in my project, and put business logic classes in it, (with the build property set to Compile, not Content) I get a compilation error, on the following, and the code editor intellisense won't recognize the the .Caching in the following:
using System.Runtime.Caching;
If I move the class back into a subfolder of Controllers, no problem, the .Caching appears in intellisense and no compilation error occurs.
Any explanations of why this might be so, and how I might adjust my project to allow business logic classes to operate correctly outside the Controllers folder, would be appreciated.
The App_Code folder contains code that is compiled at runtime.
See the following reference: http://msdn.microsoft.com/en-us/library/t990ks23.aspx
If you have business logic, it's probably best to put it into an external (from the webiste) library to increase reuse and enable better compartmentalization.
Add a business layer class library project to your solution, and then add reference to this business layer class library project to your MVC project.
First off, there's no such ting as App_Code folder for MVC.
Why?
Well, the App_Code concept is meant to work with Website Projects, however, MVC are Web Application Projects which is a framework or implementation of a pattern to work closer to the HTTP protocol and web requests and separate concerns into presentation (views), request handlers (controllers) and models. So, don't expect it to work with App_Code
Suggestion
Create/Add a Class Library project in the same VS Solution where you can keep all your business logic and then reference this project in your MVC app
Now I'm working on web analytic system, which is MVC based. While developing I got a good thought to extract web administer panel to separate assembly. It's for using in other my projects. So, in future I could just reference that assembly and don't care about layout web panel.
Web panel itself is just a markup of elements with some tight design. It contains main menu, submenu and a place for stuffing of needed other elements.
at the moment, I've got an assembly with all views in such panel using RazorGenerator.
The issue is how can I manage css files for such assembly? Should I just inline them to views and place that views to compiled assembly or deploy them as separate css files with assembly?
That css bundles would be compressed/minimized or any way combined in final project.
You could package the css and js files as resources and have them served using the resource handler, but you wouldn't be able to edit them in future projects if a design exception comes up (e.g. you need to modify the a css class because it clashes with the main css of another project).
Why not create a nuget package? some advantages
You have everything on a zip file (you don't have to publish the package to use it)
You can add the project directly from the console
The nuget creates the corresponding folder structure for views and controllers for the admin area
If you need to remove it you just uninstall it and it takes away all the files.
Plus, you have the flexibility to modify css and js files for the admin.
This is easier than having a "black box" dll on your application that handles routes and serves packaged files hidden from the rest of the application.
Here are some tutorials on how to create your own nuget package:
http://www.codeproject.com/Articles/593605/All-you-need-to-create-a-Nuget-package-for-ASP-NET
http://docs.nuget.org/docs/creating-packages/using-a-gui-to-build-packages
http://msdn.microsoft.com/en-us/vs2010trainingcourse_aspnetmvcnuget_topic2.aspx
Is it a deployable assembly? For example, will it be added to lots of different systems, in different locations, or will it be used on say a corporate network?
If you're deploying the assembly then you probably want to compile the css as resources & use the ASP.Net built in resource handler to serve the css. You therefore have no dependencies on anything else, you pre-compress/minify the css & the host server can take care of caching.
If it's for a corporate network, or a servers you control, then put the css on a central server & have them all reference that location. The previous approach work just as well here though.
I'm using EntityFramework 4 in my WPF desktop-application (NS: MyCompany.MyProduct).
Now I want to create the same application in ASP.NET (NS: MyCompany.MyProduct2), with the exact same functionality... Hence I need to use the exact same database as the WPF application already does.
Additionally, I want to create a new executable (hence a new wpf project) on top of my primary WPF project, that also uses the same ConnectionString like the WPF / ASP.NET-Application, to display some reports.
So I figured out I'd need to share the .edmx-Model (NS: MyCompany.MyProduct.Models.DBModel.edmx) and the ConnectionString that is already persistent in the app.config of the WPF app or the web.config of the ASP.NET-App.
What is the best or recommended way to do this?
What is the best or recommended way to do this?
Create a class library project and put EF model in there and share it between your WPF/Web projects. The app.config file of a library project isn't picked up by the parent project therefore you will have to manually update your web.config file to add the ConnectionString section.
This approach allows you to share business logic between your WPF app & your web app. If they are essentially the same app but on different platforms, then you should only be re-implementing the UI - this is one of the major advantages of the MVC pattern.
Agree with #James here. Don't be afraid of adding library projects to your solution. So you would have a project called MyCompany.Model that contains your EDMX. (Actually, you might find later that you want to use the T4 generation to split your model off from your DbContext or ObjectContext, but that's another discussion.)
With Visual Studio you can actually add a project--your EDMX project--to more than one solution. Be careful not to make changes to the EDMX project when editing one solution that break the other, though.
Respectfully, you may find that it's not ideal to use the GAC here, especially if your EDMX is still evolving.
As for connection strings, these are one thing that you tend not to share between projects. Typically they are in the app.config (or web.config) for your executable project. This can be a gotcha, because if you use a library project to hold your EDMX, EF will automatically create an app.config in the library project, with the connection string in it. But .NET never uses an app.config for a DLL. The only reason it's there is to give you something you can copy/paste into the real app.config for your executable (WPF) app.config or the web.config.
If your goal is to share the single .edmx dll between all three applications on one machine, the best way to accomplish this is to sign the dll, then add it to the GAC. If the dll will remain on different servers, there is no need to GAC the dll, you can just reference it in your projects, and add the connectionstring entry in the respective .configs.
GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.100).aspx
Install a DLL to the GAC: http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx