Nie ma to nic wspólnego z typami anonimowymi, które mają właściwości wewnętrzne
Jest całkowicie możliwe przekazanie anonimowych typów z widoku do częściowego widoku
Napotkałem dziś ten sam problem i nie miał on (bezpośrednio) nic wspólnego z problemem przekazywania anonimowych typów i ich nieodłącznych internal
właściwości.
W związku z tym, w odniesieniu do pytania PO, odpowiedź @Lucas jest nieistotna - mimo że obejście zadziała .
W pytaniu PO anonimowy typ jest przekazywany z widoku w zestawie X do częściowego w zestawie X , dlatego problem, który przedstawił David Ebbo, dotyczący właściwości wewnętrznych dla typów anonimowych, nie ma żadnego znaczenia; typy skompilowane dla widoku, typ częściowy i anonimowy są zawarte w tym samym zestawie .
Więc co powoduje nagłe niepowodzenie w przekazaniu anonimowego typu z widoku do częściowego?
Przynajmniej w mojej sytuacji odkryłem, że było to spowodowane innym widokiem w TYM SAMYM FOLDERZE, który określa typ modelu, którego nie można rozwiązać . Widoki są kompilowane w czasie wykonywania, więc miałoby to sens, ponieważ kompilacja widoków w czasie wykonywania oznaczałaby również niepowodzenie kompilacji typów dynamicznych, a częściowa po prostu otrzymałaby plik object
. Nie jest od razu oczywiste, co się dzieje, ale w konkretnym przykładzie PO (i moim) jest to najprawdopodobniej przyczyną problemu.
Warto zauważyć, że jeśli typ modelu jest poprawny, ale inna część widoku nie kompiluje się, to nie wpływa to w ten sam sposób na typy anonimowe. Musi to wynikać z tego, jak Razor rozbija dynamiczną kompilację części składowych widoku.
Po poprawieniu nieprawidłowego widoku odbuduj całe rozwiązanie lub wyczyść i odbuduj projekt przed sprawdzeniem, czy został naprawiony.
Aby upewnić się, że nie zostaniesz ponownie zaskoczony, możesz włączyć kompilację w czasie kompilacji widoków Razor, dodając to do swojego csproj
pliku:
<PropertyGroup>
<MvcBuildViews>true</MvcBuildViews>
</PropertyGroup>