I have a clickOnce application which is deployed as "Start the Application from the Web or a Network Share". So, fist time a user try to start the application, it will be downloaded and installed to an application cache on the local computer. My problem is that every time I do a release, I update the new files to the network share. But whenever user try to hit the URL, clickOnce will start the application from the cache instead of downloading the new version. I can go for two solutions:
Every time user closes the application on local system, cache should
be deleted.
If there is a way to get notification of new update
even if application is deployed as "Start the Application from the
Web or a Network Share" and next time it will delete the cache to
download new files.
Any other solution apart from above two will be
helpful.
Make sure when you publish that the Publish version is being incremented. I always check the box "Automatically increment revision with each publish".
If you make changes and deploy with the same version, click once will not update. Hope this helps.
Related
I have associated my new app with the old one in the store, then when hitting Local Machine I get the message:
The app ____ is already installed on this machine.
if you continue with the current deployment , the existing app will be
uninstalled and the apps current state will be deleted.
are you sure you want to continue?"
I need to keep the local state folder as that's where I have saved user data in the first version of the app, I don't want my users losing data.
Does any one know of a way to achieve this ?
This will not happen for actual users of your application who download it from the Store. The issue here is that when debugged, the app is signed with a local certificate as opposed to the Store-signed version. If you want to debug this "update" scenario, the easiest way to do so is:
Checkout the older version of your app from Git
Run it with debugger
Add some data
Close the app
Checkout latest commit again
Run app
I deployed a new provider hosted Sharepoint app successfully (I used this tutorial: http://bhanuprakashbysani.blogspot.de/2014/11/how-to-publish-provider-hosted-app-in.html).
However, now I want to deploy the first update of my app. The only way I found out is to deploy it "manually":
Delete app on my SP developer site.
Menu "Apps in Testing"
New app to deploy
Upload ".app" file
This steps have 2 disadvantages I want to avoid:
I always have to delete my app before I upload the new version, else I get an error
These are manual steps, it would be perfect, if the update would work automatically.
Are there any possibilities to set my project up for these "autoamtic" updates?
To update your app you need to create a new version of the app and distribute in the App Catalog where it was distributed.
There are 2 things in the app manifest which controls the installation and upgrade process:
The product ID also called GUID. Do not change the value or
SharePoint will not recognise it as an update
The version number of the app. It's in a standard .Net format, by default it is 1.0.0.0. When you create a new version, you have to
increment this number.
When running Sitecore Setup the following error pops up:
Failed to open XML file, system error:-2147024786
I've tried going through the eventviewer but to no avail.
Not unimportant is that I used the installer but forgot to change my rootdirectory. As a consequence I had to uninstall (using the same installer Sitecore).
Now however it "feels" as though there are some references or remnants left behind somewhere.
Who has a clue or can give me an idea of what is going on?
You are correct, this issue is because the previous Sitecore instance, with the same name, has not been removed completely. You will need to manually complete the following tasks to remove the remnants and be able to run the installer, it has worked for me in past;
Stop the App Pool for the uninstalled site in IIS
Stop the Web Application for the uninstalled site in IIS
Perform an iisreset in command line
Delete the App Pool and Web app in IIS
You should now be able to completely delete the folder containing the Website and Data folder completely
If you are still having trouble deleting it check the folder's Security Permissions, the Users and their Permissions and Read Only checkbox. Ensure you have control to delete
Delete the relating entry in the hosts file
If you also installed Databases access them via MSSQL Management Studio, take all relating databases Offline then delete them.
This will effectively remove all remanants of the previous site. If what ever reason the issue still persists, Sitecore's own Sitecore Instance Manager has a delete option which will completely uproot the site for you. Try installing with SIM then.
I've been using this same Sitecore project, for more than 2 years now. Upgraded to Sitecore 7.0 this spring, and everything just ran like it should.
But yesterday, suddenly out of nowhere, i can't seem to run my project anymore. I'm using Visual Studio 2013 with IIS Express (64 bit). And when i try to build and run my site through localhost, it just hangs. I even tried to let it load for 1 hour+, but it still just loads with nothing happening.
I tried to debug it further with Fiddler, but nothing happens. I even tried to delete a bunch of important files, like web.config. But it still just loads forever, with no error.
If i create a new empty web project, i can start it through localhost instantly. So there must be something weird happening with my Sitecore project.
Does anyone have any suggestions for debugging this or have you ever experienced anything like it?
I've nearly tried anything.
I am not sure what version you upgraded from, but I would do the following (in order) to troubleshoot the issue:
Depending on what version you are upgrading from, you may have been running your app pool on .NET Framework v2.0 instead of v4.0, which is required for Sitecore 7. Open up IIS, go to your app pool for the site and make sure that it is correctly set to run on .NET v4.0 and not v2.0. If it was set to v2.0, change it to v4.0 and try access the site. If the issue persists or if the app pool was already running on v4.0 continue to the next step.
As implied in step 1, Sitecore 7 runs on .NET 4.5. If you are upgrading from an earlier version of Sitecore, it is possible that your site is compiled using an earlier version of .NET. Right click on your project files in Visual Studio, click on Properties->Application and make sure that the Target Framework for each of the projects is set to .NET Framework 4.5. If they were set to a different framework, change them, build your solution again, and then try to access your site. If they were already set to target .NET 4.5 or if the issue persists continue to the next step.
Double check the permissions on your site root. Make sure that NETWORK SERVICE and/or your IIS User has all of the necessary read and write permissions for the directory. If they do not, apply the permissions and try the site again. If the problem persists, continue to the next step.
Delete all of the Sitecore DLLs and the DLLs generated by your projects. Copy fresh DLLs from a clean download of Sitecore 7 back into your bin/reference directory and build your solution again. Try to access the site again. If the issue persists, then the problem is likely in temporary internet files or in a config. Continue to the next step if this is the case.
Delete your Temporary ASP.NET Files from the Framework and Framework64 folders found in the C:\Windows\Microsoft.NET directory. Note that you must go into the directory for the version of .NET that your app pool is running against and delete the contents of the Temporary ASP.NET Files directories. It may be necessary to stop your app pool when you do this. Try to access your site again and if the issue persists, move onto the next step.
Try replacing your web.config with the default from a clean download of Sitecore 7, but be sure to back yours up before-hand so that you do not lose customizations, as you will want to add them back in after. Try your site again. This time, you may get an error if something in your code is dependent on the web.config. It is a good thing if this happens, as it means that your site is now working and you have only to add back in your customizations to resolve the errors. If your issue persists, continue to step 7.
If your site is still hanging, try replacing all of your configs in the App_Config directory, one at a time, with their clean copies (excluding ConnectionStrings.config and DataFolder.config, if you are using them). Additionally, disable/backup and remove all custom configs or configs for modules that you have installed that are not Core to Sitecore. Try to access your site again. If necessary, resolve any config errors by merging your changes/re-enabling your configs one at a time until you find one causing the issue or until all errors are resolved.
If your issue continues, post your the Sitecore version you upgraded to, the version you upgraded from, and any modules you have installed as a comment on this post.
When using Clickonce deployment when the publishing wizard in Visual Studio asks if the application will look for updates online (and if so, to provide a url) what exactly should I point to? Do I simply host the contents of the /publish folder on a server, and enter the url to that folder? Then just update the online /publish folder when I release updates, or should the url point to something else?
Normally the best way to host a ClickOnce Deployment is to deploy from a webserver.
On the first page in the Publish Wizard where it asks Specify the location to publish the application leave this as Publish\
On the second page where it asks 3 options select the top one marked From a Website and type in the url of the web server where you want to deploy from (this needs to be the full uri inc virtual directory).
Then complete the wizard.
What you should end up with is a series of files in the Publish directory, one of which will be publish.htm
You can then upload these files as is to your webserver and give out the link to the publish.htm file to let your users start the installer.
If you re-publish just keep the settings the same and you should roll out a new update to all those people who used the publish.htm link to install.