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.
Related
I have just started a new site where I am using 2sxc version 11.11.4 (started with 11.7.3 and upgraded to see if that would fix it). I have the data and views set up just like I have done on another site using version 10.25.2. On the newer version though, I'm unable to use the remove button/action. I did some searching and found a few references to adding lines to the web config file (https://github.com/2sic/2sxc/issues/1654, https://github.com/2sic/2sxc/issues/2205). I tried this and it worked great.
So, my question: will a fix be implemented for this or will we have to add these lines of code to the web config file on any site we use 2sxc on?
Also, could these lines of code affect any other DNN features, other modules, etc.?
I think you are talking about my solution here
https://github.com/2sic/2sxc/issues/2205#issuecomment-705647892
This is specific to a server where the WebDAV features have been added/enabled in Windows. I do not think its an issue that can or will be fixed in 2sxc.
I do know that it is safe to add those two items in web.config. All its doing is telling ASP.NET to NOT make WebDAV available in this application's (DNN's) context. I am not aware of any DNN feature or modules that need or use WebDAV. Its just something handed down from the server because its installed and its causing a weird change in behavior that makes the DELETE (and other) command types get ignored (IMHO, presumably because they are handled before they get to DNN).
I have a windows application where I am creating an installer for it with InstallShield. The installer will be posted in a login-secured location on the internet. When the program starts up, I am going to have it check the download site to see if it needs to be updated, and if so direct the user to the site to update the app.
The problem is the version numbers. The app knows its own version number, and I can create an API to put on the site that can read the version number of the installer, but how can I keep them in sync? I'd rather not have to do it manually every time there's a build.
The installer is required to be behind a login wall and it can't have any way to direct link to it, so the site will feed it to the user with a binary stream. I had been experimenting with ClickOnce, but I couldn't find a way for it to create a single-file installer and it doesn't allow for authorization when updating.
The best approach depends on how you're building things. This answer assumes you are using a build system to come up with each version number, and specify it downstream to all the built items.
IsCmdBld ... -z "ProductVersion=1.2.3.4" can be used to specify the version at the command line. Be sure to consider that the (optional) fourth field of the ProductVersion is largely ignored by Windows Installer, and adjust your version numbering scheme as necessary.
Alternately the automation interface can be used to edit the project, and set the ProductVersion on the ISWiProject object. This is more flexible, but requires modifying the project before subsequently building it.
By the end of last week our central IT Department introduced SCCM and applied it to a bunch of clients in our division. My colleagues and I work as so called "IT-Partner" in a 1st level support for a few hundrets of colleagues. Now we're facing some problems with our new SCCM System (installed packages do not work etc.) Now we'd like to "reset" applications so the SCCM Agend will reinstall them. I've read something about the detection methods but unfortunatelly I do not really know how they work nor I know where those methods are saved. I want to "analyse" those methods so I know which file to modify / delete that the agent will reinstall the application.
By the way, how much time does SCCM take from "assigning" a package to applying to the client?
Assuming you only have the client and no access to the SCCM Console the detection methods can be found using WMI. They are stored in root\ccm\CIModels in the Class Local_Detect_Synclet.
The format is XML in one column and it is designed so that all kinds of detection methods can basically be represented in the same style so it's not very readable but you should be able to get some basic understanding about the detection method used.
Keep in mind this is only true if the software was deployed in the "new" (introduced in sccm 2012) application format and not for the "old" package/program format.
If you want more detail I once tried to automate the process of triggering a reinstall for any given application but ultimately failed due to problems with the chache/distribution point. I posted all my findings here.
So from an application POV. When you deploy an app the detection method is setup in SCCM to determine wether or not the application installed successfully. This detection method could be configured a variety of ways. For example, it could check to see if the msi code is installed to determine success, it could check the .exe and compare it to a specific version, or even check a registry file for existence. In order to change/modify these detection methods you should be an SCCM admin and be able to login to the console. From there you would select the specific application or package you want to analyze and click through the properties of the deployment.
A recent question in the Codename One discussion forum raised a question I often face when I'm waiting for a fix.
Sometimes the Codename One team indicates a fix would be coming in a couple of weeks and other times they indicate that its already fixed. Some of that opacity obviously relates to the update of the cloud servers but its unclear for me whether its just the cloud server & the plugin or is there something that I'm missing. Why isn't there a single update process?
I'd really like a more definitive answer like How does Codename One work?
for this.
Codename One is comprised of several different pieces and an update usually means we update only one of them. At a high level there are really just 2 major types of updates: libraries & servers.
We update libraries once every 3-5 weeks we update servers all the time (sometimes more than once per day sometimes ever 3-4 days).
Here is a slightly more accurate overview of what it means to update Codename One:
Plugin & related tools - the plugin itself provides the project properties, server connectivity and designer/gui builder tools. It updates as part of the native IDE update process once every 3-5 weeks. You need to explicitly accept an update prompt from the IDE in order to get this update. Bugs in the plugin itself or features for the designer/GUI builder need to go thru that process...
Build.xml - this is technically a part of the plugin update but you need to actually accept changes that we make to the build.xml to get some functionality. On occasion a new feature (e.g. the new GUI builder) needs to update the build.xml code but this will only happen if you go into project properties, click OK and accept the prompt to update the build.xml (if such an update exists).
Client libraries - these are the API's you use when writing Codename One code (typically CodenameOne.jar and related ports). We usually issue an update to those once every 3-5 weeks together with the plugin update. The plugin ships with these but they are only applied to new projects... When you send a build we implicitly update your libraries to the latest version using a separate update process, you can also use "Update Client Libs" within the Codename One preference to update these manually without sending a build.
Device libraries - when you send a build to the servers we use the latest version of the client libraries that might be newer than what you see in the client libs but might not be the latest git master. This allows us to rapidly deploy & test device fixes. This also allows you to work with the code and use newer features that weren't pushed to the Client Libraries. The process of updating the servers is a bit adhoc so there is some opacity around that, we are looking at making this more transparent.
VM & builders - The builder code and VM relate to the server side scripts that generate the code. When you have a compilation error on the servers or need an enhancement there we need to deploy it in a process similar to the device libraries deployment.
Certificate wizard update - this tool is updated in a completely separate update process despite shipping in the plugin. We had a lot of concerns about Apple changing things suddenly when initially creating this so we decided to allow this to update instantly.
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.