I've recently copied a Kentico 10 environment to a new development environment, and upgraded it to Kentico 12. I believe the problem occurred after the upgrade, not after the copy (of the site and database). The new environment is also using a different URL than the original, and I have a valid license key for the new URL.
The site functions correctly, except for images. Unfortunately, all media library images that are loaded using GetAzureFile.aspx are failing to load. Attempting to access one causes a redirect to
/CMSMessages/accessdenied.aspx?resstring=dialogs.badhashtext&hash=...
I assumed the problem might be a different CMSHashStringSalt in the new environment's web.config, but it is the same as that of the original environment.
Per this documentation, I have attempted to re-save some of the images to see if they would begin loading but that did not help.
Does anyone have any suggestions on how I might tackle this problem?
Thanks
I don't believe that GetAzureFile() is something you should be using "publically", I believe that's meant to be an internal handler. You should be using the permanent URLs for media libraries hooked up to external storage.
Also, your provider code could need to be updated. Check out the documentation.
Related
I am in the process of upgrading from Orchard 1.7 to 1.8. Everything seems fine locally, but when I deploy my site, 1 of my custom modules is disabled. When I click the "Enable" link in the modules section of the dashboard, the page refreshes, but the module is still disabled. My local instance is connected to the same database and shows the module enabled so not really sure what is happening. I don't see any details in the standard error logs.
Is there any way to see any errors that could be causing a module to fail being enabled?
Thanks
This turned out to be due to a case mismatch in my feature name vs my module folder name. My module was originally named in Pascal case ie. 'MyModule'. Somewhere along the way my folder had gotten renamed to 'Mymodule' while the Module.txt file still listed the primary feature as 'MyModule'.
I finally hunted this down by copying the Orchard.Modules.pdb file into the bin folder of my precompiled web application and attached the VS debugger to it to see what was going on. The issue presented itself inside of Orchard.Modules.Controllers.AdminController.Features() where a comparison of FeatureDescriptor.Id == ShellFeature.Name failed to match on account of the case mismatch. The result was that my feature was being shown as disabled even though it is enabled in the database.
Not a direct answer to your question but did you do a complete rebuild before publishing your orchard site (assuming that is how you deployed it)? I have found that sometimes you have to do a rebuild all before publishing.
When I call use AzureReader to resize an image I get a 404, yet if I don't do a resize the passthrough call works perfectly.
I think it is due to the problem stated on the /resizer.debug.ashx page:
"Precompilation is enabled. Image providers may not work as expected."
The problem is I'm deploying through GitHub and don't know how to control precompilation.
So my question(s) are:
1. Am I right in thinking this is precompilation related? If not then what?
If so
2. how can I block precompilation on GitHub based deploy
3. how can I work around precompilation problem? (i've seen http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/ but am not able to see how to apply to my problem)
On other point... incredibly similar code deployed fine to AAzure via Github 6 months ago and worked... has Azure Websites changed something with deployment in last 6 months or so?
Many thanks,
RIchard
Microsoft's VirtualPathProvider framework does not work in Precompiled mode.
Typically, this manifests as failure on direct access (without resizing).
However, AzureReader2 is unique among the blob providers in that it redirects to the original blob instead of directly serving the image when no changes are required.
You may be able to set vpp=false on the <add name="AzureReader2 vpp="false"/> element an get it to work.
Problem
I uploaded an image using the inbuilt tool and added it to a blog post. All this on the production server, across the pond in Montana, US.
It displays fine (using the correct absolute path it should: "/Media/Default/BlogPost/...") in the preview of the blog post. But once I publish it, I get a broken image in the live site. The reason being that the path renders as:
http://localhost:[port number]/Media/Default/BlogPost/...
Obviously, if running on a Dev machine, this will still work, but once on the live web server, this no longer works.
History
I downloaded WebMatrix onto my machine, downloaded orchard, installed the Minty theme, made a new theme that uses Minty as the BaseTheme. Then, once everything was almost there, uploaded onto the live web server.
I can't see how this can affect how the server interprets an absolute path, but maybe I am missing something?
Fudged solution
I can fudge a solution by using the URL of the site i.e. I open the image picker and in the URL for the image resource text box I put:
http://blogs.mysite.co.uk/Media/Default/BlogPost/...
With this full URL, the problem goes away, but it is a fudge and I shouldn't need to do this.
Any suggestions?
#gelistir from the Orchard discussion pages answered this.
It is caused by a module, the Vanderlay Relative URL Filter module. Disabling the module (that I wasn't using anyway, not even sure what it does...) solved the issue.
For whatever this is worth, more than 2 years have passed since the question was asked. Anyway, if the problem described here happens to you, on the dashboard go into Settings and under "General", set your base url to your "http://www.yourdomain.com", instead of to "http://localhost[portnumber]". This is where the Vanderlay module gets the url to rewrite from.
Regards,
I have a small solution that is composed out of 2 main projects a Mvc4 Web Api and a silverlight 5 Application. I've configured and deploy the application initially on the Azure platform and it all went great, but ever since when I deploy again the silverlight project does not get pushed and the online site has the old version.
I should mention all works great with the azure simulator on my local dev machine.
Anybody had a similar issue?
Regards,
I would suspect first (as Simon suggests) that the browser likely still has the previous client cached and loads that instead of downloading your new client.
You can use the version number in the code on your page that hosts the silverlight app to help. While it's easy for you to clear the cache - you don't really want to have to tell users to do that whenever you update.
Set the version to whatever your latest assembly version is (silverlight client project assembly), this will force the browser to download the client if the cached version is a lower number.
<param name="source" value="AppPath/App.xap?version=2.0.0.6"/>
Ok,
So after pulling my hair out, I finally figured out.
I have to change the build configuration to release in VS do a rebuild and then do publish because apparently the azure project does not do rebuild on the project when you publish it.
To solve this issue you'll need to identify the source of the problem (is it a client side problem where you have a caching issue or not). Even though you say caching isn't the problem we'll need to be sure about this first.
What I suggest is that you do the following first:
Activate Remote Desktop on your role
Connect through RDP and save this file to the role: http://support.microsoft.com/kb/841290 (fciv.exe)
Find the *.xap file (usually in E:\sitesroot) and get its checksum (using fciv.exe)
Modify the Silverlight project locally (maybe change a label or move around an element) to make sure its hash has changed.
Redeploy the application
Connect through RDP and use fciv.exe to get the checksum of the *.xap file once again
Compare both checksums
If the checksums are different, then it means that the deployment worked correctly and the Silverlight xap has been updated. If the checksum is the same, the problem lies with the deployment.
Please let us know the result so we can help you find the solution.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH