GetResponsiveCropURL Installation Specific Problem
On a 7.2.2 site we're getting the following error message on the live site. Everything works fine on the dev and test sites. I've recopied DLL's Views and Partial Views, rechecked and saved crops in the Image Cropper DataType, and the Media items themselves, cleared caches and republished the whole site. Just cannot pin this one down. As it's the live site I don't want to do a full upload just yet. Can anyone point me at where else I can look for this fault?
An unhandled exception occurred
Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'Umbraco.Web.Models.PublishedContentBase' does not contain a definition for 'GetResponsiveCropUrl'
at CallSite.Target(Closure , CallSite , Object , String )
at ASP._Page_Views_Partials_accessoryListing_cshtml.Execute() in d:\home\site\wwwroot\Views\Partials\accessoryListing.cshtml:line 13
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at Umbraco.Core.Profiling.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
at System.Web.Mvc.Html.PartialExtensions.Partial(HtmlHelper htmlHelper, String partialViewName, Object model, ViewDataDictionary viewData)
at ASP._Page_Views_AccessoryList_cshtml.Execute() in d:\home\site\wwwroot\Views\AccessoryList.cshtml:line 8
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy()
at System.Web.Mvc.WebViewPage.ExecutePageHierarchy()
at System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage)
at Umbraco.Core.Profiling.ProfilingView.Render(ViewContext viewContext, TextWriter writer)
at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass1a.<InvokeActionResultWithFilters>b__17()
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation)
at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult)
at System.Web.Mvc.Async.AsyncControllerActionInvoker.<>c__DisplayClass25.<BeginInvokeAction>b__22(IAsyncResult asyncResult)
at System.Web.Mvc.Controller.<>c__DisplayClass1d.<BeginExecuteCore>b__18(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.Mvc.MvcHandler.<>c__DisplayClass8.<BeginProcessRequest>b__3(IAsyncResult asyncResult)
at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
I should also mention, I've proved imageprocessor is working by calling a media item with a width querystring.
Can anyone explain the above so I can get the live site working with the same code as the dev and test sites? It looks to me like there's a reference missing, but Slimsy works everywhere else in the site apart from in this partial view so I doubt it's that.
Both test and live sites are hosted on Azure, if it makes a difference.
I tried that earlier with no luck. However, just in case, I tried it again and it worked. Must have had slightly different conditions last time.
Although it doesn't explain why one installation needs it while the others don't, I tend to agree that it looks a more sensible solution to the problem so will mark this as the answer.
GetResponsiveCropURL Installation Specific Problem
On a 7.2.2 site we're getting the following error message on the live site. Everything works fine on the dev and test sites. I've recopied DLL's Views and Partial Views, rechecked and saved crops in the Image Cropper DataType, and the Media items themselves, cleared caches and republished the whole site. Just cannot pin this one down. As it's the live site I don't want to do a full upload just yet. Can anyone point me at where else I can look for this fault?
I should also mention, I've proved imageprocessor is working by calling a media item with a width querystring.
Thanks,
Craig
Hi Craig,
Can you ensure you have the same /Views/Web.config, I think you are missing the namespace that is added there?
Jeavon
Thanks Jeavon, the /Views/Web.config files are identical :(
Strange, could you post the contents of /views/web.config?
Sure:-
Looks fine, you could try adding @using Slimsy; at the top of the view even though it shouldn't be needed
Tried that, no difference. The error is called on the
@if(productImage != null) {
Line:-Just wondering if it's safe to uninstall and reinstall Slimsy on a live site.
Could you double check the Slimsy.dll is in the bin folder?
Could try calling the method directly
Changing
to
fixes the problem on this particular installation. So does that give any clues as to what's missing?
Slimsy.dll is in the bin folder.
Can anyone explain the above so I can get the live site working with the same code as the dev and test sites? It looks to me like there's a reference missing, but Slimsy works everywhere else in the site apart from in this partial view so I doubt it's that.
Both test and live sites are hosted on Azure, if it makes a difference.
Hi Craig,
Could you try changing
to
and see if it makes any change?
Jeavon
Hi Jeavon,
I tried that earlier with no luck. However, just in case, I tried it again and it worked. Must have had slightly different conditions last time.
Although it doesn't explain why one installation needs it while the others don't, I tend to agree that it looks a more sensible solution to the problem so will mark this as the answer.
Thanks again.
is working on a reply...