We are experiencing this strange issue with one of our ClickOnce-deployed applications:
On some client machines, ClickOnce when updating the application does not copy the old database in the .pre folder.
ClickOnce updates the application, but it behaves like it is a new installation.
Another strange thing is that despite it is specified a minimum required version to force any client to update the client PCs which have this issue display the ClickOnce upgrade prompt (it also displays the "Restore the application to its previous state" in the control panel "Program and features" item).
Indeed, other client PCs upgrade automatically without prompting and ClickOnce update behaves like it should.
This is a mature application and this is our 30th publication.
Another element is:
Usually we published this application alternatively with two PCs but after installing Visual Studio 2012 we cannot use them to publish ClickOnce and then we create a virtual machine only for publishing this application.
--------------UPDATE----------------
I accepted RobinDotNet's solution because it is DAMN RIGHT to not rely on ClickOnce moving your data reliably.
I also found that you cannot rely on ApplicationDeployment.IsFirstRun.
I changed my code to use my internal check for IsFirstRun and now every updates run smoothly.
As you have found, you can not rely on ClickOnce moving your data reliably. I strongly recommend that you put your data in LocalApplicationData, even if it involves moving a database. Here is a blog article explaining exactly how to do that.
I suspect your problem (and that of not being able to use two different VS2012 instances) is because of the certificate that you use to sign your application. Is it a certificate purchased from a CA, or is it a test certificate created with VS2012? If it's a test certificate, then you probably created a new one on each machine, and each time you publish it, ClickOnce thinks you are changing the certificate, which is part of the identity. When the identity changes, it doesn't carry data forward, and thinks it's a new application. With .NET 3.5, they at least made it stop forcing all of your customers to uninstall and reinstall when you changed the certificate.
Your solution to that is to create one certificate and use it on one machine, then copy it to the other machine. Double-click on it to add it to the certificate store on the second machine, and be sure it's part of the project so you pick up the same one. (In the Signing tab, be sure to select the file, don't select it from the Certificate Store on the machine).
Related
I have deployed a Windows Forms Application (Visual Studio 2013 C#) to a file share and will get my users to run the app from this file share. The app uses Entity Framework 6 and works fine from the file share but there is a delaying in loading the EntityFramework.dll during execution for the first time.
Is it possible to move just this dll from the file share to the local pc and tell the app to use it from the local pc?
As #tede24 stated, before trying to solve this problem, make sure EntityFramework.dll is actually your problem.
Once you make sure it is, here are the options I can think of:
1) Use ClickOnce
ClickOnce is not popular, but it still seems to be the preferred way for deploying intranet applications. Yes, it supports version checking and auto updates.
2) Use some sort of XCopy installation
You can create a batch/PowerShell to copy the application content locally from your intranet. If you want to go futher, you can even verify whether the version is the latest before launching.
3) Try putting EntityFramework in the GAC on the client machine (not recommended)
EntityFramework is not meant to be GACed, but you can still try to do that. I would strongly avoid it because of dependencies and update problems you might run into.
I have a C# Windows Forms project that I created.
When i click "Publish" it deploys this click-once application that is only for a single user. If I run the install on my admin account, then there is a shortcut in my AppData that i can click on to run my program. If I try copying that shortcut to C:\users\Public what happens is that another click-once application gets placed on the users' desktop. That user then has to run the install and is annoying cause If i have an update, each user has to uninstall and reinstall the new application. Is there any way to configure VS 2015 to publish in a way that creates an "regular" install for all users?
RobinDotNet addressed that in a blog post a while back:
Doing an all-users install is counter to the design goals of ClickOnce deployment, so I think it’s going to be something everyone has to live with, at least for now. Using XCopy or a setup & deployment package and rolling your own incremental update methodology would be the way to go if you absolutely have to have an All Users installation
https://robindotnet.wordpress.com/2009/09/07/installing-a-clickonce-application-for-all-users/
There are more alternative deployment methods listed in this SO answer that might work for you.
You can not do this using ClickOnce. You may want to install Windows Installer XML to create regular MSI installers. It nowadays integrates with Visual Studio.
As others have pointed out CO is per user. There is no install for all users on the machine option.
However I feel you are either misinformed or badly misconfigured something regarding the implications when it comes to upgrades. Click Once upgrades don't require the user to uninstall, download, and install a new version. That wouldn't exactly be click ONCE.
You can configure your ClickOnce app to automatically detect, fetch, and apply upgrades as you make them available. This can be done either in code so you can control it programmatically or by configuration (i.e. check for updates every time the application starts).
So yes each user would need to install the application once but that would be the end of their involvement.
I am new to ClickOnce applications. I published my application (locally, on my dev computer), installed the application using the setup.exe inside the published folder, and then ran the program. Everything was good.
I made some updates to the application, and wanted to install the new version on my computer to test it. So I uninstalled the previous version, using Add/Remove Programs. Now when I go to install the next version (from a different directory than the first install), I get the infamous "You cannot start application from this location because it is already installed from a different location." message.
I am looking into using the install-over-the-interwebs option, so that I can just update it online, for my client, but for now, I was just testing using the "From CD-ROM" install.
Basically, I'm hosed. My previous install is uninstalled, so I can't access that. And any new version cannot be installed because the installed is complaining that my previous one is still there.
My goal is to convince the computer that my previous version was indeed uninstalled. Apparently there is something lingering that is confusing it.
Thanks for your help.
So the solution for me was a 2-part fix.
First, I now update my app from a URL. You can use a local folder, or a website for this. The way I did it was publish my app into a folder of a website within the same solution. Then I publish the website to an azure site. Then to download the app I just go to that website/.
Second, I followed some advice found here: http://social.msdn.microsoft.com/Forums/windows/en-US/9e4b714e-bad4-4c62-a7ad-3c80e32d95eb/clickonce-fails-with-value-does-not-fall-within-the-expected-range?forum=winformssetup
The advice was to do this:
Mike, I am one of the previous posters here. I "solved" this (i.e. it rarely happens anymore) by turning off ClickOnce automatic version incrementing, and by making sure at every release I change the version in four places:
- assembly info for both assembly and file version
- ClickOnce version (making sure to keep the automatically increase version checkbox off)
- under Update, making sure I always set the minimum version to the same as elsewhere
I found that my version numbers didn't match in all these places -- specifically the assembly number and file version number weren't being updated inside the AssemblyInfo.cs. Once I had manually set those all to the same new number, published the app to my local folder (inside the website), published my website to azure, gone into my website via FTP and deleted old version folders in the "Application Files" folder, and downloaded the app from my website as described above, I could install and run the app without errors.
I don't know if this fix solves anyone else's problem(s) along the way, but there it is, for what it's worth.
This answer also is very helpful: http://social.msdn.microsoft.com/Forums/windows/en-US/365f8c65-b413-428e-af93-f150059a185f/cannot-runinstalluninstall-a-clickonce-application?forum=winformssetup
Thanks for reading.
We have a prototype application that was originally published to an external server hosted on AWS (for discussions sake assume this was on http://prototypes.mysever.com/MyApp/).
The prototype size started to mount up so for speed we moved it to an internal server (assume http://internal/MyApp/).
I did some clearing out of our IIS server that was hosting the original published app (external) and removed the application. Now if we try to install a copy of the app, it fails, because it wants to talk to the original server even though we published it elsewhere (for like 80+ versions).
In the .application file I noticed a reference to the old server, but changing this didn't solve our problems.
Is there a way to stop it looking for the old server?
Sorry,
I deleted my last answer, because I misunderstood the question. Yes, there is a way to change the update location.
Open the Project properties page, and go to the Publish tab.
Click the Updates... button.
On the updates screen, verify that the update location is pointing to the new location.
I have a small .NET WinForms application, and couple of linux servers, DEV and CL1,CL2..CLN (DEV is development server and CL* are servers which belons to our clients, they are in private networks and it's a kind of production servers)
I want an update mechanism so that
(1) i develop a new version and publish it to a DEV
(2) users of DEV-server install latest version from DEV
(3) users of CL2 (employees of client2) install stable version from CL-2 directly
(4) application checks for updates using server it was installed from (so, if it was installed from CL-2, it should check CL-2 for updates)
(5) i should be able to propogate the update to a selected CL-server (using just file copy & maybe sed; not republishing), if i want that (and if i don't, that CL-server will have an old version until manually i update it)
I tried to use clickonce, but looks like it meets only first two requirements.
What should i do?
ClickOnce should handle 1-4 to be honest. All that would be needed is that for each site you want to deploy/update from, you'll need it to have its own publish, which after looking at your specifications is not incorrect to do.
What you could then do in order to make 5. applicable, is create an automated process to re-publish the file. This could perform a publish and then upload to the correct server.
Remember that ClickOnce needs a new manifest per version, and a new version requires a publish, so I'm not sure that you'll get around 5. with a simple file replacement.
Kyle is right. But for the 5th note, you just need to copy the deployment, and then use mage to modify the installation URL and point it to the new server, and then re-sign the manifests.
I support an app that we deploy to a DEV, QA, PROD servers. The way I handled this is that
I created created a cmd file that has command line calls to MSBUILD. It builds the app once for each server with the appropriate URLs and switches. I give my DEV and QA builds a different AssemblyName that way I can run all 3 environments side by side. This way my build process is automated and I don't have to publish at all.
Here's an article that describes the parameters you can use.
http://msdn2.microsoft.com/en-us/library/ms165431(VS.80).aspx
#Kyle,
For the above solution can the different versions run side by side or do you get errors indicating the app is already installed.