We are currently building a WPF application which is to be deployed via Click Once, the build is currently being handled by a Team City server.
We are noticing that every time someone checks in some code and the CI server builds the deployment package, the “Application Files” directory contains an additional version of the application.
Due to the mounting size of Click Once deployment, this is becoming un-scalable, does anyone have any idea how to limit the number of previous versions that are placed inside the Application Files directory?
The application files directory:
Click Once does not provide any mechanism for handling the published deployments. It would be difficult for Microsoft to do that, because everybody's requirements would be different. I'm sure that's why Team City didn't add that ability either (assuming they didn't, I don't use Team City).
Related
So I was able to publish my wpf application using click once without any problem for a couple of months. But yesterday when I tried I got an odd looking message.
When choosing Yes option the publish stops and fills error list with those errors:
I tried searching online but without any success.
I resolved this issue by unchecking the passive mode check box when prompted for the ftp credentials
This issue started happening to me after I upgraded to Visual Studio 2019 16.7.3. I also updated my application from .NET Framework 4.7.2 to 4.8. (Although I doubt that's the issue, I did not revert to 4.7.2 to test it.)
My solution was to publish to a local folder and then upload those files with a separate FTP application (e.g., FileZilla). Upgrading my existing ClickOnce app worked fine.
Details: In your application's Properties page, select the Publish tab. Change the Publishing Folder Location field from "ftp://whatever" to "C:\publish-MyApp." Click the Publish Now button. VS will create the files pretty quickly. Next, use your FTP application to upload the contents of the C:\publish-MyApp folder to the existing installation folder on your server. This overwrites the existing setup.exe and MyApp.application files and adds a new folder (e.g., MyApp_1.2.3.4) in the Application Files folder.
(One side benefit of this method is that it's faster to publish because FileZilla is a lot faster at uploading than Visual Studio.)
In our current dev. workflow there is main database --> DbMain. There is the process that takes the latest version of the project and automatically deploys it there and after that it triggers unit tests. As we would like to always have working version of the project in the source control each developer should be sure that he checks in the working code and all tests would be passed.
For this purpose we decided to create individual databases for each developers that has following naming convention --> DbMain_XX (where XX are the developers initial). So every developer before the check-in is suppose to publish all the changes to that database manually and run the unit tests. It is useful to setup publish config for this purpose with that is the copy of the main publish config with the only difference in the database names.
That would introduce that we will have a lot of different publish profiles in the solution that is quite a mess.
If we will not add these profiles to the source control, then .sqlproj file would still have reference to these files so the project will have reference to the not existing files.
So the actual question. Can I have single publish profile for all developers where the database name will be changed using variables? For example DbName_$(dev_initials)? Or can we have that each developer would have their own publish configs only locally and it wouldn't break the project?
UPDATE:
According to the Peter Schott comments:
I can create local publish profile, but if I don't add it to the source control, then the still be an entry in sqlproj file, but the file itself will be unavailable.
Running tests locally have at least 2 disadvantages. The first one is that everybody is supposed to install SQL Server locally. We are mainly working via virtual machines and the disk space is quite limited there. Another thing is that developers will definitely forget or not will not run tests manually every time. Sometimes they will push changes to the repo without building it or/and running tests. We would like to avoid such situations and "catch" failed build as soon as possible.
Another approach that was mentioned is to have 1 common build database. And in my case we have one (DbMain). All of developers can use it for it's needs but we will definitely catch the situation when the 2 developers will publish at the same time and that can make a lot of confusion by figuring out what's really went wrong.
A common approach to this kind of thing - not only for SSDT publish profiles but for config files in general - is to commit a generic version of the file with a name something like DbMain.publish.xml.template, and provide instructions to the developer to rename the file to DbMain.publish.xml - or whatever - and .gitignore this local copy of the file, allowing the developers to make whatever changes they want, but inherit the common settings from the .template version of the file.
Publish profiles don't need to be added to the .sqlproj to be used at deploy time, this is merely a convenience in Visual Studio to make them easier to find and edit, so you don't need to worry about broken references.
You are right in wanting to avoid multiple developers publishing to a common "build" database, this is a recipe for frustration.
Really, you want the "build" database to be published to as part of your CI process, meaning after the developers have pushed their changes.
We have an net 4.0 winforms application that we publish with clickonce to the client pc's. The installation is about 80 MB. The application is offline available and the update occurs in the startup of the app using
ApplicationDeployment.CurrentDeployment.Update
Each time we do an update of the application everything works fine and each client gets udpated. However the application cache keeps growing in size... We noticed that more then two versions are kept in the LocalAppData folder. The size of the clickonce installation folder is more then 1GB.
ClearOnlineAppCache works only for online applications and we don't find any information to clean the LocalAppData for offline application.
Is there any way to manage previous versions of our application in the LocalAppData folder from our client pc's?
Update:
We removed our custom update code and used the update mechanism of the Clickonce framework. Now old versions are removed properly and only two versions are kept in LocalAppData. I have still no idea why all versions are kept when we update through the custom update code.
I've seen this issue before, but I clarified with the ClickOnce lead at Microsoft before answering.
It keeps two versions of the deployment plus there are extra folders for each assembly. When processing an update, ClickOnce figures out which files have changed by comparing against the assembly it has already cached, and it only downloads the ones that have changed. The deployment folders have hard links to the assemblies in the separate folders. So you might see additional files, but it's not actually the file, it's a link to the files in the assembly-only folders. Explorer will show it as a file, but it's not. So unless you're running out of disk space and are just concerned about the folder size, be aware that the information reported by Windows Explorer may not be accurate.
There is an answer to this problem here
I wrote a function to clean old ClickOnce versions in the client side.
In my machine I've freed 6Gb of space. I don't want to even know the total space used by old versions org wide...
I have created a Silverlight 4 application, that is running out of browser. As you will know, there is a function that is checking if a new version of the app is available and installing it.
But what if I want to only check for the update and not installing it?
Personally, I do not like applications that silently update themselves, downloading something from the internet. So I'd like to have the following mechanism.
- when the app starts, it checks if updates are available
- if so, I show a messagebox to the user, telling her that there is an update and that she can download and installing it via the update-button
- the user can now decide to update
Unfortunately, there seems to be no option to just checking for updates without actually downloading and installing it. Any ideas, how to achieve this?
Thanks in advance,
Frank
You can roll your own update detection, by having a small file on your server next to the XAP for your app, that contains the latest version. For example:
http://localhost/myawesomeapp.xap
http://localhost/myawesomeapp.xap.ver
When you want to check for updates without downloading them, you can always hit the .ver file, check the version listed in it and if newer then the current running app, show the Update button to the user.
Note that this approach also would allow you to create more advanced scenarios, like prompting the user to upgrade to a different version of the app (Pro for example) or that they need to upgrade their Silverlight to get the latest.
And if you have multiple apps, you can list all of them in that file and do cross-promotion between your apps.
Is there any utility that will copy the "official" build of a windows forms app from a central network share and launch it (from a client desktop)? I want to make sure users get the latest version when I update the binaries on the central network share.
ClickOnce is user un-friendly so I'm looking for something else...
Is it possible you could revise your question to describe what it is you find unfriendly about ClickOnce? In my office we have found ClickOnce to be the most efficient and user-friendly way of updating and distributing applications desktop business apps that we have ever had. I'm wondering if the best way to resolve your question might be to address the issues you have with ClickOnce, rather than integrating/rolling another solution.
I've done this before by the following method:
1 - Keep the "official" build at a specific network location
2 - User launches program from their local machine
3 - At launch, program compares its' own file version # to the one on the server.
4 - If the two versions are different, copy the new version down from the server and relaunch.
Pretty simple, and it works as long as you are in an intranet environment.
Step 4 is the only tricky part. You can't replace a file while it's in use, so you have to either
1 - first rename the current (in-use) file and then copy down the new one. Since you will be updating many times, you'll also want to delete any existing renamed copies that are hanging around.
or
2 - Have the user launch a "helper" application that does the version check, updates if necessary, and then launches the real app. Of course then you have to deal with updating the helper app.
We have a tool that would do that, which has been in use before there was such a thing as Windows Update (or any other update.)
The problem with any sort of update of this fashion is the security level of the user. Many times you need to be administrator to perform certain functions.
Our solution is two part/one executable: 1. a service mode that runs local system or admin to perform such operations. 2. an executable which can be called by an app to fetch via UNC, HTTP, FTP the updates for an application and apply them.
The basic process is this:
1. Application checks its version number; we use a central database to list all applications and their version numbers.
2. If the application is a minor revision we give the user an opt out on the install; if it is a major revision we require an install.
3. Once the update is confirmed, we call the updater executable which in concert with its service mode product, retrieves the updates, installs them, and relaunches the application.
If you are interested, go to the website listed in my profile and send us a support request address to me and I will give you more details and the codebase if desired.
Check out this one:
.NET Client Applications: .NET Application Updater Component
It is a white paper which discuses in detail on what it takes to make an application auto-updatable.