I'm trying to create a 'shared' MVC application, which can be used for all common data that is used by other MVC and legacy Web applications.
For example, I have two Virtual Directories setup on my server:
mysite.com/Report
mysite.com/Base
So what I'd like to be able to do is this to include a view from the 'base' folder in the 'Report' one;
#Html.Partial("/Base/Views/Shared/_NavigateMenu.cshtml")
Note that ~ in Report will go to mysite.com/Report, I cant use that.
However doing so results in the following exception:
The virtual path '/Base/Views/Shared/_NavigateMenu.cshtml' maps to another application, which is not allowed.
I know about areas however there are a lot of downsides in using them, firstly I cant (or is very difficult) to migrate the existing legacy applications into a area, also logistically it is nicer to have each MVC application separated and have a space for common objects. (Not just views, but css, images, etc.)
So the question is how do I 'allow' MVC to map and thus access to other applications?
Trying to share a MVC aplication is basically trying to share several different components :
Controllers should be shared through a separate class library, reachable through area registrations
Models can be in any referenced class library
for views, I assume base Base application root folder contains the application web.config. Views, hosting the views, can contain a web.config relative to views rendering (say for razor configuration)
To use Views in application Report, you have to create a virtual directory SharedViews (or whatever name you want) in Report, which will point to the physical path of Base/Views.
Then you will be able to write :
#Html.Partial("~/SharedViews/Shared/_NavigateMenu.cshtml")
The points are :
having a virtual directory in Report, to avoid switching from an app to another
having this virtual directory not reference the root directory of Base, to avoid app configuration conflicts
you can resolve this problem using the char ~ before virtual path i.e.
#Html.Partial("~/Base/Views/Shared/_NavigateMenu.cshtml")
or else
if it is specified path set up as a Virtual Directory in IIS than it may treat it as another application even though it's in the same directory as the main application.
Related
Context
We have a web app using AngularJS with ASP.NET MVC. It aims to replicate a file-system structure through URLs, like this:
http://(site1)//rootFolder//NFolders//File
For views in Angular, we are using stateProvider, with different states associated to existing views in disk (.cshtml files).
The problem issues when we request a file or folder from the browser and we try to serve a virtual view that doesn't really exist. We have just been able to achieve it with a full postback and some hacks, making a complete reload on each file/folder request.
Question: Is there a way of achieving that in Angular? Other way, the request for different URLs which don't have either their corresponding physical view as a file or any state in stateProvider, handling them with Angular and customizing a specific view which would deal with disk routes requested by URL?
RE-EDIT
We will have:
a fixed root view for the website: http://website
several root projects with a name:
http://website/site1
http://website/site2
....
http://website/siteN
each site may have different files and folders accesible via the URL:
http://website/site1/folder1/folder2/.../foldern
http://website/site1/folder1/folder2/.../foldern/fileX
RE-QUESTION: is it possible to handle this "virtual" URLs without having a physical view behind for folders or files? Our idea is to have one unique view called siteController which would control all the sites, and paths to folders and files.
I would suggest you define rootFolder/NFolders/File as parameters. Then you can have a html file as the view template to populate data from server.
Have a look at this link
https://github.com/angular-ui/ui-router/wiki/URL-Routing#stateparams-service
Get ready for yet another elementary question from me...I think I have a grasp on the Area concept in a MVC site, but I would like to organize them even further, could I either move them to an external project (with controllers, views, scripts, styles) or create sub-folders within the Area folder?
Reason I'm asking is that I have tried to create a folder under Areas and called it Common, then created an area inside that folder and called it MyTest. When I attempt to browse to mysite.com/mytest, it fails.
You should try to go the usual way and use areas as a subfolder of the Areas ASP.NET root folder. The only reason why your URL would fail is that your AreaRegistration file is not properly registering your route. You can check out Glimpse as a way to debug routes or simply look at the files and try to figure it out your self. Keep in mind that ASP.NET automatically look for classes that inherit from AreaRegistration and use them to register routes that are specific to your area. If your routes seem to be configured properly, make sure your controllers are in namespaces that are visible to the route.
If you want to isolate the areas (with the controllers models and views) into separate projets, you should look into creating your own VirtualPathProvider, because that's the only way for your views to be located. However, they would have to be Embedded Resource and couldn't be debuuged. Your area, if located in a separate DLL, would be automatically registered and your controllers would be automatically found as long as the DLL is in the main application Bin folder.
I want to be able to have a folder which allows regular access like the \content folder except that it holds a ClickOnce application. I can't seem to be able to achieve this using Mvc, but I'd like to have this folder accessible without Mvc seeing it as a controller action.
I tried using routes.Ignore(theUrl), but this seemed to have no effect.
There are two ways you can do this. The first is where you are currently going, which is to satisfy it with routing. You should be able to use the following to ignore the intended route:
routes.IgnoreRoute("...")
However, this might not be the right approach from a security stand point. I would recommend you define an explicit action to download your click-once exe. Have a look at this q/a as an example of using the FileContentResult class.
The reason for this is that you can control security for that file without having to open up access levels to other directories.
Edit: If this is for an entire directory, you can still follow this same approach.
Set up the folder as a virtual folder in the website on IIS. then you can set the url in the code to point to the machine serving the request and to the virtual folder on the web server.
I have an ASP.NET webapp using the ASP.NET MVC 2 framework. It allows users to upload files to an uploads folder. The issue occurs when an image within a sub-folder is accessed by a web browser:
http://mywebapp/uploads/image_gallery/sub_folder/image.jpg
The uploads folder is static and can't be modified by users, but anything below it is intended to be modifiable.
In the above example, the image_gallery folder becomes locked because w3wp.exe appears to create a handle on the sub_folder directory (using process explorer by sysinternals). I am still able to rename the sub_folder directory and the handle seems to stay with it after a rename, but i can't rename the parent folder (image_gallery in this case).
I can still browse within the folder and view other images and files etc. But can't rename the parent folder.
As this is using the MVC 2 framework i've put in an exclusion for the uploads folder like so:
routes.IgnoreRoute("upload/{*pathInfo}");
into global.asax, so i'm assuming that ASP.NET is serving up those images directly (outside of the MVC framework)
So I guess my question is, is there any way to prevent IIS from putting a handle on specific directories or forcing it to remove a handle? Is the MVC 2 framework doing something tricky even though i have the ignoreroute specified?
Thanks in advance for any tips!
I had the same problem, and after much investigating I've found the culprit:
Web.config
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
Setting this option (which makes all http modules run on ALL files, static ones included) to false fixed it for me.
I believe, directory handle gets created in worker processor because ASP.NET typically watches the file system for changes - this allows it to respond to change/addition of config files, new dlls etc.
I suggest that you move from the concept that users can control physical directory structure on the web server. Typically, what user can create is an logical directory structure but physical structure would be controlled by your program logic. Your logic will store the logical structure created by user and its mapping with actual physical structure on the web server.
Does there exist a method when publishing an ASP.NET MVC application to completely remove the .aspx view files (and if possible .master too) by compiling them into the application DLL as resources?
The published application would just be the /bin folder, Global.asax and web.config, a default.aspx if needed, and whatever is in the /Content folder. All the views would be contained in the MyProject.dll file.
To clarify I don't mean where every .aspx is overwritten with a 1 line dummy file referencing the correct resource, but where those files can be eliminated entirely in the published app.
The goal here is to simply change management and all the auditing and layers of people surrounding it - one file gets deployed, that file replaces the existing file, and no messing around with a stack of .aspx files that have to be added/removed/updated (yes, SVN or a similar solution handle that problem instead, but management politics prevent this).
Is this what you are looking for?
It's possible with the web forms view engine but you'll have to extend the path provider yourself.
Here is a question here at SO about the same thing:
Using VirtualPathProvider to load ASP.NET MVC views from DLLs
If you use the Spark view engine, it already has additional path providers built in.
The documentation can be found here:
Adding a view folder to config
It allows you to locate your views inside a DLL as an embedded resource, somewhere else on the file system, using the default virtual directories, or plug in your own custom provider.