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.
Related
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
We're trying to figure out how to automate our website deployment. We've picked an existing project, and started playing around.
First, I used the Publish wizard from with VS2012 to create a Web Deploy Package. We then tried deploying the package as a website, through the IIS Manager, and that succeeded without a problem. We thought we were nearly there.
What was next was to learn how to run this from the command-line, so we could script it. And that's caused us no end of headaches.
We've been playing around with msdeploy.exe, and with the .cmd file that the publish wizard created, and while both methods seem to install the package as a virtual directory just fine, neither will install the package as a root website.
Browsing around on the web, I've run across this:
Web Deploy iisApp Provider
In a sync operation, the iisApp provider copies content to a folder under the destination site that you designate and marks the destination folder as an application. The iisApp provider cannot create a site. The iisApp provider will not create applications under sites that do not exist.
And
If you want to synchronize a Web site and its related configuration, use the appHostConfig provider.
At this point, we don't know beans about iisApp, or appHostConfig, or whatever. We didn't create a package that used one or the other, VS2012 did. We haven't a clue, at this point, how to convince VS2012's web publish to create an appHostConfig package, and for that matter, I don't know if we want to.
Here's the thing - whether a given website is installed as a root application or as a virtual directory is not something the developers control - it's a decision made by the implementation team. Or testing team usually installs any given website both ways, to ensure that both work.
And since IIS seems to be able to manage to install this package as a root site, there must be a way to get msdeploy to do it.
But how?
I'm trying to set up an Orchard site to deploy to Azure, but have fallen at the first hurdle. I've downloaded the source code and opened Orchard.Azure.sln, but when I run it I get the error:
Access to the path 'C:\APPG\src\Orchard.Azure\Orchard.Azure.Web\App_Data\Dependencies' is denied.
What am I doing wrong? I'm a complete noob with Azure, so please forgive my ignorance.
This isn't actually Azure related, but you need to ensure that the identity that your website is running under has write access to the App_Data folder. Either give the IIS user access, or change the application pool identity in IIS to Network Service. When Orchard starts for the first time, it writes a whole bunch of stuff to folders below App_Data.
Bear this in mind if you need to install fresh at any time. Simply deleting the contents of that folder and creating a new, blank database (or using the compact option) will start afresh.
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
I'm trying to deploy a winform application with IIS and ClickOnce. I can access the publish.htm page and the install even starts when I click on the provided link.
However I get this error during the installation process:
Downloading http://MyWebSiteUrl/.../Interop.SHDocVw.dll did not succceed.
The remote server returned an error: (500) Internal Server Error.
Can anybody help me out on this ?
Thanks,
Bruno
I found out that I needed to check "use .deploy file extension" (under properties>Publish>Options>Deployment
[Answering this old question because it comes up as the best match in my case and the accepted answer was of no use to me].
Background, in an IIS hosted ClickOnce scenario, the downloadable components are itemized in a manifest file at the root of the deployment (that's how you can specify a single download link and deploy all the supporting components).
I was converting a tested application from a WiX installation to a lightweight version with ClickOnce and received the HTTP 500 error without anything else in the logs. Naturally, I failed to think it through and instead found myself getting dragged down the rabbit hole on the internets, with instructions for detailed logging, magic spells, etc.
Upon more sober reflection, the problem was simple and I should have been able to tell immediately from the IIS log: a 500 followed by a 0 is shorthand for 'you're an idiot, the content isn't where you said it was' and it had almost nothing to do with ClickOnce.
I had copy/paste/edited an existing download link template in MVC that was in use for simple apps and it happened to cater to only two levels of subfolders in the manifest. When I ported a more complex project structure, I ended up leaving items in a Resources sub-sub-subfolder that looked fine in the manifest but the path was being truncated in MVC so that the related item could not be found.
Moral of the story - if you get a 500 error always check first to make sure your non-functioning appliance is plugged into a working outlet...