Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

The model item passed into the dictionary is of type ‘mvc.Models.ModelA’ but this dictionary requires a model item of type ‘mvc.Models.ModelB‘

I have this annoying mistake in some of my builds.

There is no error in the project, because if I build again, then the problem disappears. The message only appears, when the site is deployed to a Windows 2008 Server.

I first thought that it might be an issue with temporary files, but thats not the case. I deployed the build to a different web and the error still appears.

The error appears on random actions of the site. Most of the time builds are ok, but each 3rd or 4th build produces runtime errors.

I build using a WebdeploymentProject in release mode. Views are precompiled.

It's not In ASP.NET MVC I encounter an incorrect type error when rendering a page with the correct typed object, because views have totally different names.

How I can debug this problem or how I can get help for this?

Here is my WebDeploymentProject

    <!-- 
      Microsoft Visual Studio 2008 Web Deployment Project 
      http://go.microsoft.com/fwlink/?LinkID=104956

    -->
    <Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
        <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
        <ProductVersion>9.0.21022</ProductVersion>
        <SchemaVersion>2.0</SchemaVersion>
        <ProjectGuid>{E5E14CEB-0BCD-4203-9A5A-34ABA9C717EA}</ProjectGuid>
        <SourceWebPhysicalPath>..\B2CWeb</SourceWebPhysicalPath>
        <SourceWebProject>{3E632DB6-6DB3-4BD0-8CCA-12DE67165B48}|B2CWeb\B2CWeb.csproj</SourceWebProject>
        <SourceWebVirtualPath>/B2CWeb.csproj</SourceWebVirtualPath>
        <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
      </PropertyGroup>
      <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
        <DebugSymbols>true</DebugSymbols>
        <OutputPath>.\Debug</OutputPath>
        <EnableUpdateable>false</EnableUpdateable>
        <UseMerge>true</UseMerge>
        <SingleAssemblyName>B2CWeb_Build</SingleAssemblyName>
      </PropertyGroup>
      <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
        <DebugSymbols>false</DebugSymbols>
        <OutputPath>..\B2CWeb_Deploy\</OutputPath>
        <EnableUpdateable>false</EnableUpdateable>
        <UseMerge>true</UseMerge>
        <SingleAssemblyName>B2C_Web</SingleAssemblyName>
        <ContentAssemblyName>
        </ContentAssemblyName>
        <DeleteAppCodeCompiledFiles>false</DeleteAppCodeCompiledFiles>
      </PropertyGroup>
      <ItemGroup>
      </ItemGroup>
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets" />
      <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
           Other similar extension points exist, see Microsoft.WebDeployment.targets.
      <Target Name="BeforeBuild">
      </Target>
      <Target Name="BeforeMerge">
      </Target>
      <Target Name="AfterMerge">
      </Target>
      <Target Name="AfterBuild">
      </Target>
      -->
    </Project>

EDIT

After some months this problem disapeared. I haven't had problems for over 1 year now. I guess the issue will strike again when nobody expects it.

EDIT 2

… for over 2 years now. I am such a lucky dude!

EDIT 3

I just read an article on MSDN, and it sounds like the problem I had. I have debugging disabled, but still the compilation was "sometimes wrong". The behaviour of the old provider could be the issue. But this is just guessing.

Very large pages containing long spans of HTML with no server blocks (e.g. <%= %>) can cause a stack overflow when debug compilation is enabled that will crash the application. Note that in our testing it’s taken a page that’s ~4x as large one that would’ve produced a similar issue in the old provider, but in this case it crashes the entire application, whereas with the old provider it just fails the offending page

like image 308
Mathias F Avatar asked Feb 22 '10 23:02

Mathias F


4 Answers

Even if the types match, you can get this error when a null is passed to a partial view.

You can fix this by calling RenderPartial with an empty ViewDataDictionary like this:

helper.RenderPartial("~/Views/Player/PlayerName.ascx", player, new ViewDataDictionary());

For reference, I found this solution at:
renderpartial with null model gets passed the wrong type

like image 104
Maslow Avatar answered Nov 05 '22 15:11

Maslow


ASP.NET MVC Partials

NULL model was passed!!!

@Html.Partial("PartialView", model: Model)
like image 25
Andrei Avatar answered Nov 05 '22 13:11

Andrei


This error can occur (and does) when there is a mismatch between the data that the controller action method is supplying to the view and the type of data the view is expecting. This will not normally show up as a build error, even with precompiled views.

For example, if I have a method...

public ActionResult Create()
{
    // Do something
    return View(new CustomerCreateViewModel());
}

...and a Create view with a Page attribute...

<%@ Page ... Inherits="System.Web.Mvc.ViewPage<CustomerDetailsViewModel>" %>

...this will compile and build without error. However, when I call the Create action, I'm going to get a yellow screen, because the Create action method is throwing data of one type and the view is expecting data of a different type. You might want to verify that your types are matching...

like image 7
Neil T. Avatar answered Nov 05 '22 14:11

Neil T.


Are you absolutely sure that this has nothing to do with the data being passed to the view? Are you performing a full rebuild each time?

These errors typically occur because a partial view tries to use the view model passed to the ViewPage when the view model passed to the partial view is null. I realize that you are implying that the error is somehow caused by the build process, but I don't see how that would be possible. Could it be that the deployed site uses a different database than the site you run on your development machine, and could the data (or lack of data) in that database be the cause of the problem?

like image 3
Rune Avatar answered Nov 05 '22 14:11

Rune