Razor-based view doesn't see referenced assemb

Question

I'm attempting to create a strongly-typed view based on a class from another assembly. For whatever reason though, my Razor view doesn't seem to have any visibility of other assemblies referenced on my project. e.g.

@model MyClasses.MyModel

results in the error in Visual Studio 2010, "The type or namespace name MyClasses could not be found (are you missing a using directive or an assembly reference?)."

The same class referenced in the standard view engine works fine. I have the same trouble trying to reference the class in the body of my view.

Am I missing something about Razor or do I need to reference the assembly some other way?

Answer 1

Your Project FOLDER name needs to be the same. If your Project or Solution name is different, then MVC will hurt you.

Example : If you create a new Application and it gets the default name Webapplicaiton1, then this namespace will be created. So, let us say that you dont want to have this namespace, so from the VS you change everywhere you can see to "MyNamespace". You also search and replace all code from "Webapplication1" and replace it with "MyNamespace". This also changes web.config file, so that it inculdes

Now everything will work, except Razor views.

RazorViews cannot find it, because there is some kind of strange dependency on the FOLDERNAME of the project. It is terrible design.

I have tested this semi-thoroughly by copying my files into a new solution, and the only difference being the foldername.

Answer 2

in spacename models, yourClassModel, add public before name class

public class yourClassModel{
    prop
}

Answer 3

In ASP.NET Core MVC the solution is to add a using in _ViewImports.cshtml, instead of putting it web.config in the View folder when working with ASP.NET MVC 5.

_ViewImports.cshtml

@using mySolution
@using mySolution.ViewModels // <-- Add this, and place your ViewModel (e.g. LoginViewModel) in here.
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

View

@model LoginViewModel // Add to _ViewImports to make this line work
<div>This is the View for the login screen.</div>

Answer 4

include the entire namespace

@model namespace.myclasses.mymodel

Answer 5

I had the same problem: MVC3 Project MyCore.Web was referencing to MyCore.DBLayer namespace from another project in the same solution (with assembly name MyCoreDBLayer). All objects from MyCore.DBLayer worked perfectly in Controllers and Models but failed in Razor views with an error 'The type or namespace name 'DBLayer' does not exist in the namespace 'MyCore' (are you missing an assembly reference?)' which was obviously not the case.

• Copy Local option was set to true.
• Adding "using..." statements in Razor views was useless
• Adding namespaces to system.web.webPages.razor section was useless as well

Adding assembly referecene to system.web/compilation/assemblies section of the root web.config file fixed the issue. The section now looks like:

<system.web>
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
        <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        **<add assembly="MyCoreDBLayer" />**
      </assemblies>
    </compilation>
...
</system.web>

Omitting version, culture, token was OK for now, but should be fixed in the future.

Answer 6

In addition to making the web.config changes for <assemblies> and <namespaces>, I found that GAC'ing the assembly made a big difference. You can apply culture and public key token like any core .NET assembly that is registered globally.

Some may shudder at the mention of the GAC. But as a BizTalk developer I've grown to embrace it.