I have a surface controller that interacts with a form that has been built in a partial view. Everything works fine on my local machine and if I access our non-load-balanced admin server. When I attempt to use the form through our load balancer, I am getting an odd error:
The model item passed into the dictionary is of type 'Elements.Models.ContactUsModel', but this dictionary requires a model item of type 'Elements.Models.ContactUsModel'.
As you can see, the expected type and the actual type match, so I'm not sure why this error is being generated. My only thought right now is that they are coming from different compiled versions of the same class.
I currently have all code files in App_Code and being compiled with application start up (I presume). If I precompile into a DLL, will that remedy the problem?
Anyone know what might be happening? Any other thoughts?
It does appear to have been related to the use of App_Code vs. a DLL. Having the files in the code folder was likely leading ASP.NET to create duplicate classes in multiple DLLs because of updates applied on the fly in the code. After compiling to a DLL, the forms work fine behind the load balancer.
On the other hand, I appear to have broken my custom section in the back end by putting the code in a DLL. I may have to separate out the backend stuff and leave that in App_Code, but now that I've got it all in a DLL, I'm wondering if there's just a quick fix I'm missing -- maybe an assembly reference somewhere? Anyone have thoughts.
I realize I'm changing the subject, so I'll post separately if I can't find the answer myself and no one offers one here.
In case anyone ever reads this, I solved my second problem with an update to trees.config in the Config directory.
My custom section had two trees. Umbraco automatically adds some configuration to Config/trees.config to load those trees. One of the attributes of my custom trees is "type." It was to something like:
Hi George,
I am currently having the exact same error message as you had. Could I ask you to clarify a couple of points for me please? I'm brand new at using Umbraco so any help you can give is gratefully received!
You said that you had files in the App_Code folder, do you mean the controller .cs c# files (which are used in VS)? I oo have these files in my deployed site.
I have got a compiled DLL for my site also, and I'm assuming IIS / VS will use that when I run the website?
My plan is to follow your advice and:
1. Compile the DLL again
2. remove the .cs files from the deployed App_Code directory
3. restart the site and app pool.
does that sound about right? Obviously you bear no responsibility here, I'm just trying to find a solution to this awkward issue!
I tried you solution of removing the files and it worked, the app was getting confused by the 2 sets of files, there must be some sort of hierarchy being applied.
Thanks very much for posting your answer, much appreciated, I will attach it to my post.
Invalid model when rendering through SurfaceController behind a load balancer
I have a surface controller that interacts with a form that has been built in a partial view. Everything works fine on my local machine and if I access our non-load-balanced admin server. When I attempt to use the form through our load balancer, I am getting an odd error:
The model item passed into the dictionary is of type 'Elements.Models.ContactUsModel', but this dictionary requires a model item of type 'Elements.Models.ContactUsModel'.
As you can see, the expected type and the actual type match, so I'm not sure why this error is being generated. My only thought right now is that they are coming from different compiled versions of the same class.
I currently have all code files in App_Code and being compiled with application start up (I presume). If I precompile into a DLL, will that remedy the problem?
Anyone know what might be happening? Any other thoughts?
It does appear to have been related to the use of App_Code vs. a DLL. Having the files in the code folder was likely leading ASP.NET to create duplicate classes in multiple DLLs because of updates applied on the fly in the code. After compiling to a DLL, the forms work fine behind the load balancer.
On the other hand, I appear to have broken my custom section in the back end by putting the code in a DLL. I may have to separate out the backend stuff and leave that in App_Code, but now that I've got it all in a DLL, I'm wondering if there's just a quick fix I'm missing -- maybe an assembly reference somewhere? Anyone have thoughts.
I realize I'm changing the subject, so I'll post separately if I can't find the answer myself and no one offers one here.
In case anyone ever reads this, I solved my second problem with an update to trees.config in the Config directory.
My custom section had two trees. Umbraco automatically adds some configuration to Config/trees.config to load those trees. One of the attributes of my custom trees is "type." It was to something like:
I updated it to:
Hi George, I am currently having the exact same error message as you had. Could I ask you to clarify a couple of points for me please? I'm brand new at using Umbraco so any help you can give is gratefully received!
You said that you had files in the App_Code folder, do you mean the controller .cs c# files (which are used in VS)? I oo have these files in my deployed site.
I have got a compiled DLL for my site also, and I'm assuming IIS / VS will use that when I run the website?
My plan is to follow your advice and: 1. Compile the DLL again 2. remove the .cs files from the deployed App_Code directory 3. restart the site and app pool.
does that sound about right? Obviously you bear no responsibility here, I'm just trying to find a solution to this awkward issue!
thanks very much! Any help is appreciated.
Regards,
Mike
Hi George,
I tried you solution of removing the files and it worked, the app was getting confused by the 2 sets of files, there must be some sort of hierarchy being applied.
Thanks very much for posting your answer, much appreciated, I will attach it to my post.
Best Regards,
Mike.
is working on a reply...