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
Related
I would be most grateful if anyone could help me solve this problem with ClickOnce Web deployment.
I have read all the threads on this subject and I have also read through all the Microsoft documentation on the subject. They seem to say a lot without actually being direct or providing helpful examples. However, perhaps I am wrong and I have not looked in the right places.
I have already used ClickOnce successfully to deploy an application on the local area network.
It works well and really isn't that complicated. However, my goal is to deploy this application to customers, who are not connected to my local network.
I have set up a web site (www.mydomain.co.za), which I can access directly or via the ftp protocol.
I have created a sub directory off the root where I intend to publish the files created by the publish function. The publish function of the application requires a Publishing Folder Location and a Installation Folder URL I don't really understand the functional difference between these two locations. If I set the Publishing Location to ftp://www.mydomain.co.za/MyProductName and the Installation Folder URL to http://www.mydomain.co.za/MyProductName, then the publish process succeeds and when I check on the web server, the files have been published successfully it would seem. A further Application Files/MyProductName subdiectory with the version number information appended was created where all the output was placed.
My next step is to then grab the URL of the setup.exe file and to run it from a browser. This downloads the setup.exe file to my downloads folder which I then try to run but I get an error
Deployment and application do not have matching security zones.>
I have seen this come up in other threads but These threads don't seem to relate directly to what I am trying to do. These threads make mention of using Internet Explorer to achieve some degree of success, but all the browser did was to download the file.
I have also noted with interest that a web page is created in the root with a button that prompts the user to install the application. This does not work either.
Does anyone know of an article that I can read on this subject which is more helpful or if anyone can offer more insights into this I would be very grateful.
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
My site is hosted on Azure. I need to programmatically turn off Internet Explorer's default enhanced security configuration settings whenever I repave or redeploy a new box on Azure.
How do I do this?
I found this article on another site http://jetlounge.net/blogs/teched/archive/2009/10/25/fix-ie-esc-won-t-turn-off-internet-explorer-enhanced-security.aspx. It included the following command line syntax, but on my local box I couldn't find the IEHARDEN.INF file it referred to. I also don't think this solution is Azure-specific.
rundll32.exe setupapi.dll,InstallHinfSection IESoftenAdmin 128 %windir%\inf\IEHARDEN.INF
I need to turn off these default hardening settings under Azure because I have a 3rd party IE screen capture DLL that needs to execute Javascript on webpages.
I think that this approach, shaped in a Windows Azure StartupTask running in Elevated execution context will help you.
Just remember that the .bat or .cmd file you create needs to be UTF8 encoded. There used to be some issues with the batch files if they are not UTF8.
UPDATE
I decided to update the answer, because it would have been too long for a second comment. I want to first make clear that I do not intend to offend anyone and the next is just mine personal view and thoughts.
Well, I mine vision might be (is) distorted through mine prism. But, I think that these specifics has nothing to do with Windows Azure itself.
These are OS related configuration specifics and the approach would be one and the same (with some variations) regardless of a (hosting/cloud) provider. If you had to deploy your solution to a dedicated (or virtual) server, you would had to create some kind of scheduled task, or startup task to make these configuration changes. Or even interactively login to make these changes.
Since Windows Azure offers the StartUp Task, it is up to us (developers) to decide what to do and how to shape the OS according to our needs.
The OS configuration changes that one can possibly need are only limited by the total ammount of all available Windows Server 2008/R2 configuration options. I personally do not believe that these needs to be reflected in Windows Azure documentation by any means. They have their place in Windows Server documentation. It is arguable which are "commonly used", because what might be common for one, might also be "never needed" for others ...
I just deployed a website into IIS 7 (about which I am woefully ignorant), and upon trying to build the site, I receive this error. I did a little googleing and I saw an article that said I should put system.web.extensions.dll into the /bin. But, I also saw an article saying not to do that. I tried it anyway, but I just received a different error ('Resource cannot be found').
I am totally clueless as to what else to try
Can you use the "Publish" command in Visual Studio to publish directly to the site? If not, then use that command to publish to a similar site on your machine, then copy it to the customer site.
You should also look into the IIS Web Deployment Tool. It can copy an entire site, including IIS settings and any databases. It will be built into VS2010.
Go to control panel, then programs, turn windows features on or off, scroll down to Microsoft.net framework 3.5.1 expand, make sure both sub options are selected, this might help your issue.
So I figured out that by adding the ResetWebServer="FALSE" attribute to the solution manifest prevents SharePoint from recycling any app pools.
However, when upgrading a solution that originally did not specify ResetWebServer="FALSE" or when retracting a solution that does specify ResetWebServer="FALSE", the application pools are still being recycled. Is there a way to prevent any auto-recycling of app pools?
This does not seem possible given the document on MSDN (see below), note that I included Deploying a Solution over Upgrading a solution as underneath it is effectively doing a file replacement. I believe the restart/recycling is necessary as a result of how IIS functions. An option to explore if you wanted to manage when this occurs is to ensure that all deployments are done via timer jobs and execute when their impact will be minimized.
Deploying a solution
Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).
Retracting a solution
On each front-end Web server, the following occurs:
Microsoft Internet Information Services (IIS) is disabled.
Files are removed from the system.
IIS is re-enabled and Windows SharePoint Services is reloaded when
a user browses to a page.
You might also take a look at the "-local" switch. Didn't try it yet but it seemed that it allowed deployment server per server when you are in a load balanced situation.
Might be a good lead.