Given a library referenced in a project. That library has precompiled views (see this post how to achieve it). So the lib has ABC.dll and ABC.PrecompiledViews.dll assemblies.
There's a view in library inside /Views/Shared/Index.cshtml. And a controler which returns it.
Then I have an application references the library (both assemblies). MVC discovers and returns that Index view in runtime.
Now I create a view inside application in Views/Shared/Index.cshtml. So its relative name is the same as in referenced view. By I doing this I mean that I want to override the view from the library.
When application is started from VS (Ctrl-F5) it works but the view in application is ignored.
When application is published (dotnet publish) then the application fails on start with the following error:
InvalidOperationException: The following precompiled view paths differ only in case, which is not supported:
/Views/Shared/Index.cshtml
/Views/Shared/Index.cshtml
Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler..ctor(IFileProvider fileProvider, RazorTemplateEngine templateEngine, CSharpCompiler csharpCompiler, Action compilationCallback, IList precompiledViews, ILogger logger)
Besides the problem that the view is ignored when I run from VS it's meaningful behavior. The app has two similar view and can't understand which one to choose.
So the question is how to force MVC to use a particular view (from app instead of from lib)?
There's a method to separate views with same relative names when they are belong to different controllers. Here's nice discussion - Restrict route to controller namespace in ASP.NET Core
But my case is a bit different.
Related
Using the base Exrin template, I am unable to use custom controls.
As it stands now, the Droid/iOS projects reference the App/Bootstrapper project, so that seems like the correct place to put them, but when creating a new page or BaseView, I am not able to access the custom control's namespace because the View project does not reference the App/Bootstrapper project.
The Tesla sample app does not have this problem in its current implementation since there is no separation of the App/Bootstrapper and the View projects.
(1) Should a reference to the App/Bootstrapper be placed in the View project or (2) should a reference to the View project be placed in the Android/iOS/etc projects? Or is there a better solution than either of these two?
Edit:
(1) does not work because a reference to the App project from the View would create a circular dependency.
(2) should work (I think), but I'm having trouble getting the Application.Droid project to access the Application.View project namespace because when I add using Application.View;, the namespace isn't found in the Application namespace. Visual Studio attempts to fill in other Application namespaces (.Container, .Logic, .Droid, .Proxy) when I type in using Application.
The native project can have a reference to the View. It already does in a way, because it references the App library, which then references the View. Hence you aren't really adding any further dependencies by doing this, just allowing access further up the chain.
If you are having trouble the namespace, I suggest you start out with
global::Application.
That way it starts from the top, if its getting mixed up with project namespaces.
I want to separate my MVC project into several projects
So first of all, I've created two projects Front and Views
The Front project is a web application that contains controllers and models
The Views project is a class library project that will contains only the views
My question is how can I make controllers call views located in the Views project
I have controllers like this one:
public ActionResult Default()
{
return this.View();
}
For including controllers you need to change your route registrations to tell them where to look for the controllers:
routes.MapRoute(name: "Default", url: "{controller}/{action}/{id}",
namespaces: new[] {"[Namespace of the Project that contains your controllers]"},
defaults: new {controller = "Home", action = "Index", id = UrlParameter.Optional});
For including views, create custom ViewEngine:
public class CustomViewEngine: RazorViewEngine
{
public CustomViewEngine()
{
MasterLocationFormats = new string[]
{
"~/bin/Views/{1}/{0}.cshtml",
"~/bin/Views/{1}/{0}.vbhtml",
"~/bin/Views/Shared/{0}.cshtml",
"~/bin/Views/Shared/{0}.vbhtml"
};
ViewLocationFormats = new string[]
{
"~/bin/Areas/{2}/Views/{1}/{0}.cshtml",
"~/bin/Areas/{2}/Views/{1}/{0}.vbhtml",
"~/bin/Areas/{2}/Views/Shared/{0}.cshtml",
"~/bin/Areas/{2}/Views/Shared/{0}.vbhtml"
};
.
.
.
}
}
protected void Application_Start()
{
ViewEngines.Engines.Add(new CustomViewEngine());
For more information look at the default implementation of RazorViewEngin.
Here some good articles:
A Custom View Engine with Dynamic View Location
Using controllers from an external assembly in ASP.NET Web API
How to call controllers in external assemblies in an ASP.NET MVC application
How do I implement a custom RazorViewEngine to find views in non-standard locations?
Views in separate assemblies in ASP.NET MVC
MVC does not compile views into DLL's, but instead references them as files from the root of your site directory. The location, by convention is ~/Views and a search path is followed. This is more or less hard coded into the default view engines.
Because Views are files, when you break them into a separate project, they won't exist in your primary web application project. Thus, the view engine can't find them. When you compile the app, any projects referenced will only copy the DLL's (and potentially a few other things, like pdb's, etc.)
Now, there are ways to work around this, but to be honest, they're usually more trouble than they're worth. You can look into "Portable Areas" in the mvc contrib project, but these are not well supported and there's been talk of replacing them with NuGet packaging.
You can also follow #mo.esmp's advice, and create a custom view engine, but you'll still need to figure out ways to copy the Views somewhere the site can access them upon build and/or deploy.
My suggestion would be to NOT break out projects in the manner you describe. I don't see any value in it. If your project becomes so large, I would instead separate your code into areas, and keep all your area code and data together.
What value is there in separating items that are clearly dependent upon each other into separate assemblies who's only purpose is to collect things based on their purpose? I see some value in separating models into their own project, since models can be used by more than one assembly. Controllers and views, however, are only ever used by the MVC primary site.
You can precompile your views - that way they are included in the dll and you can reference them from another project.
How to do it:
Move the views to another project
Install Razor Generator extension in Visual Studio
Change Custom Tool to RazorGenerator for those
views
Add RazorGenerator.Mvc NuGet package to the view project
Reference view project from your main project
That's it!
Although you'll need to do something with your models, either put them together with views or have a third project for them - otherwise you'll have a circular dependency.
Another drawback is that everyone who will be working with the views will need that Razor Generator extension.
The way this works is basically you make Visual Studio generate .cs files from your views in design time and those are a part of the compiled dll, same as any other piece of code.
I've been googling for ages now, but cannot find an answer to the problem I'm facing. Here's the situation:
I have a .Net web service (not a wcf service, but an old fashioned web service), that has a web method in it returning, say, an object of type X.
Now when i create a service reference to this web service from a different .Net project, visual studio will generate a proxy class (in the reference.vb), and the return type of the web method in this class is that proxy class (say, type Y) instead of type X.
The thing is, type X is a type that is declared in an external reference that exists in both ends of the web method. Is there ANY way (the service itself should stay a web service, but I don't care if the reference is a "service reference" or a "web reference") i can make visual studio understand that there is no need to create a proxy class and it can use the existing type for the return type of the method?
I know that service references can automatically map types (you can set these settings when creating the service reference). However, this only seems to work when creating a service reference to a wcf service, not to a normal .net web service
Update:
It seems i need to somehow make visual studio match the namespaces of the types. John Saunders hinted me to the xmltype attribute i can use to specify the full namespace of the type. I will try if this works.
I also thought about how visual studio matches the classes. It seems there is no info about namespaces in the wsdl of the web service anywhere (assuming studio uses the wsdl as input for generating the reference) so how can studio match the types?
Update2:
I've tried to use the xmltype to map the namespace. I wasn't sure what namespace to use (the uri kind of the actual ClrNamespace) so i tried both. Using the uri namespace I was able to create a namespace mapping in the svcmap, but this caused the code in the reference.vb file to be generated inside an extra namespace instead of making VS want to map the type. Any new idea's? Can this really be this hard?
It simply doesn't seem possible to do this. The short answer: use a wcf service reference and create a shared library with the types used in the service and reference them in both the service and the application with the reference
I know why this happens and I want to find a workaround it.
Example: a user control that exist in 2 assemblies, loaded at the same time.
namespace MyNamespace
{
internal class MyUserControl : UserControl
{
}
}
My situation - I want to be able to share user interface control between two web applications which are loaded at the same time in the same application pool. If my user interface class is marked public, then ASP.NET will not like it because it will be duplicated into memory ( CLR uses namespaces as full qualifier for class, and if the same class and namespace is met it more than one assembly, exception is thrown ). I do then mark the class as internal and of course I forget how UI compilation occurs, and I expect it to work. Of course it doesn't because ASP.NET compiles the UI into separate assembly which is dynamic and since I marked the class as internal, it is not visible to the main assembly...
The question that follows is: How can I make dynamic compiled assemblies that ASP.NET generates to view the main application assembly internals? It is very unfortunate that classes and methods I write into my UI controls must always be public! Has anyone met this obstacle in his daily work and found a workaround?
EDIT:
Precompilation is not possible here due to other circumstances.
You can share User Control markup between apps using a Virtual Path Provider (see
http://weblogs.asp.net/scottgu/archive/2005/11/27/431650.aspx and http://msdn.microsoft.com/en-us/library/system.web.hosting.virtualpathprovider.aspx).
You can pull the markup for the control from anywhere - SharePoint uses VPP to get markup from the database, and I use it in some projects to pull from a non-standard location on disk (which is shared between projects).
If your base class is internal, the derived class that ASP.NET generates at runtime will not be able to extend it.
However, I don't understand the issue that you're running into in the first place. Two distinct web applications will always run in different AppDomains (even if they're in the same app pool), and there should be no type conflicts between the AppDomains.
I probably need more details about what you are doing. e.g. what assembly are you compiling your base class into, and why does it end up in two different assemblies?
I'm onto a real head scratcher here ... and it appears to be one of the more frustrating topics of ASP.NET.
I've got an assembly that implements a-lot of custom Linq stuff, which at it's core has zero web functionality. I have an additional assembly that extends this assembly with web specific behaviour.
The web specific behaviour comes with a couple of user controls marked up inside ASCX templated UserControls.
I'm having trouble putting a nice finish on this assembly so that it is simple to redeploy for use in other applications. Let me run through what I've tried so far:
Copied the ASCX files to the consuming web application using build events; far from ideal and quite a deployment nightmare.
Implemented a custom VirtualPathProvider and embedded the ASCX templates within the assembly as embedded resources. Unfortunately when using the Register directive in the consuming application it creates the designer declaration as a UserControl, where I would require a declaration of the actual control type; unforeseen (typically) and undesirable.
Created a Web Deployment Project to compile the UserControls, but the compiled user controls then become part of another assembly, and no longer descend from the class definitions in my web assembly--the assembly needs to instantiate them dependent on the request context.
So number 1 is just crap, number 2 doesn't give me the type support I desire and number 3 I think I'm about to produce a reasonable solution with:
Lump all non-control classes into the App_Code folder, prepare a factory class that will construct an object of the desired control type using reflection and the expectation that the type being reflected will be present in the deployment output (hopefully guaranteed by the presence of the ClassName attribute in the Control directive).
Theres also always the other option of rewriting the ASCX controls into custom controls, but just don't have the resources to consider it at the moment, and we've got no expertise in doing that, and they work fine as UserControls.
Am I missing something obvious, something maybe much simpler, or is this just purposefully difficult? I've read stories of the ASP.NET compilation process being very unfortunate in it's design on my travels across this topic.
Well I think I've done it ... by being mindful of a few of a few annoying pitfalls with my last approach, I recommend the following when compiling ASCX user controls in a Web Application Project using a Web Deployment Project:
Avoid putting classes in App_Code unless they're standalone or helper classes, ASP.NET treats this as a speshul folder, the meaning of which is lost on me, mayhem, confusion and chaos follows. Code in this folder does get output in the Web Deployment Project, though.
Pay close attention to your assembly names, their root namespaces and deployment output assembly name- you'll get access is denied errors if you have any naming conflicts during the aspnet_merge process.
Ultimately you'll most likely end up deploying 2 assemblies, I tried to create only one but the deployment output was still pointing to type definitions in the source assembly. This isn't a problem if you don't have any other types in your Web Application Project--I have so it was a problem for me. In my case, my final output was:
<Organisation>.<TechnologyName>.Web.DLL - Compiled Web Application Assembly (containing the ASCX templates)
<Organisation>.<TechnologyName>.Web.UI.DLL - ASP.NET Compiled UserControl assembly, created by Web Deployment Project
Clean often, and check that the Web Application Project's bin and obj paths are cleared of any previous junk built when you perhaps hadn't finalised your namespace or assembly naming scheme--the Web Deployment Project will be quite keen to include these, causing a fine mess.
Check your imported namespaces, the ASP.NET compiler likes to refer to the Import directive in the ASCX template, and it also considers imported namespaces present in web.config's <configuration><system.web><pages><namespaces> element, tweak if you get unknown definitions appearing during the deployment process.
Have some patience spare, it's quite tricky! But you do get some nice re distributable UserControls at the end of it!
Phew!