Develop Office Client Applications using Visual Studio
Have you used the new ClickOnce Publish and Deployment feature in Visual Studio 2008 for Office 2007 solutions? If so, we need your feedback now - and we need it before May 8th (which is an internal deadline for our team)! We're working on Service Pack 1 for Visual Studio 2008 and would like to know your opinion on a specific feature:
<Start of current scenario:
Currently the end-user is unable to cancel an Automatic Update most of the time. When the user starts an Office application (e.g. Excel or Outlook) then the VSTO Runtime checks the registry to see if it's time to check for Addin Updates. Then if it's time, it will go and download the ClickOnce Manifests (which is the .vsto and the .manifest files) from the deployment location. If this process of downloading the manifests takes longer than 7 seconds, then the user is presented with a dialog that gives them the option to click Cancel, which halts the download. Most of the time no one will see the Cancel because the downloading of the manifests is almost always faster than 7 seconds.
If the user doesn't click Cancel, then the system makes a trust decision. If the update is trusted, then it starts to download the actual assemblies. While downloading the assemblies, the user is unable to work with the Office application. They have to wait for the download to complete, the addin to get loaded, and then the user can start using the Office application. Keep in mind that this process usually takes less than 20 seconds.
If the user does click Cancel during the manifest download phase, then the side effect is that the addin is now DISABLED. If the end user wants to re-enable the addin, then she needs to open Trust Center and go through about 3 clicks to enable it again.
End of current scenario>
So our question is, would you like to ALWAYS get the option to click Cancel during the process of downloading all the stuff? Keep in mind that sometimes the whole process might be as short as 5 seconds, or as long as five minutes on sloooooow networks.
Next question for your feedback: And then if you cancel, should we leave the existing "out of date version" of the Addin as Enabled?
The reason we disable the "out of date version" of the addin is because we received feedback from many companies saying that they want to enforce updates within the update time window. Unfortunately we don't have the ability in Service Pack 1 to make the Enable/Disable feature a option for the developer (or IT department) to specify. We're realizing that we have far more customers from companies who aren't as concerned about "enforcement" of updates. Your feedback here and now will help us validate the needs of our customers.
You will be happy to hear that we are planning to include lots of enable/disable and cancel options in the next version of Visual Studio. Your feedback today will help us craft Service Pack 1 for Visual Studio 2008.
I don't know what you're talking about, but I and everyone at my company would surely like the service pack to make Visual Studio 2008 little less slow and a lot more stable (i.e. not crash or freeze as often). Everything else is acceptable the way it is, so stop working on new features and fix your old stuff instead.
Haven't ran into this issue yet, but I'd like to see more support for the ClickOnce update API from within Office add-ins (i.e. the ability to programmatically kick off an update).
OSIsoft does not use ClickOnce for Office add-ins...yet. However, when we do, our customers would likely prefer the option to click Cancel. If they click Cancel, then the user would prefer to leave the existing outdated add-in available, since that add-in should continue to function correctly.
Question1: Not a problem for us, so this is not a major need.
Question2: Yes, I think so, otherwise users will loose previous functionality (this is like "skipping an update" in normal clickonce for winforms)
Question3/feature request: We like to be able to add other files to be distributed (third party compents used in addin ui)
1. In my opinion the end user should always get the option to cancel an operation that is not triggered by the user.
2. The AddIn should not be disabled by default (this implies the end user is skipping the update) except in the scenario where the update is marked as a minimumrequiredversion and the local version is a version earlier than the required version. You can imagine a scenario where the database on the backend is changed and only to be used by a minimum addin version.
In the 2. scenario (and most likely not for SP1) where a database change is planned it would be great to have some sort of 'scheduled' update option where you can define at what time the update occurs (time definition in GMT/UTC mode where everyone will get the update independent of the timezone right on time!)
IT controlled ClickOnce deployment (in combi with SMS) ... another feature request if you want to and there is more where that comes from :-)
The add-in should not be disabled automatically if the end user clicks cancel. Better to mark the tool as "old version" and continue to try to update the tool each time it is re-launched.
Usually we want end users to employ the latest version of our tools, but if there is some problem, say with network connectivity, it's better to let them continue to use the old version until they have a better opportunity to allow the update.
Other than that, I think the present configuration makes sense: offer a cancel option if the deployment of an update would take longer than 7 seconds.
This bug is a real pain for me:
The current redist tries to store DLLs in C:\ root which is protected against writting... so I couldn't deploy any VS2008-compiled project.... so my suggestion for SP1 is to solve the plethora of bugs that VS2008 has, pls.
Also you could add SSE3/4 real support into the compiler optimization(not only intrinsics support).
And add XAML-dialog-editor for C++ and VB.
Thank you for the feedback here. We're taking your comments into consideration as we implement some changes in Service Pack 1 and run those changes through a set of tests. If we can implement a very reliable Cancel feature, then you will see it in SP1. We will also work to ensure the addin remains enabled. Your continued feedback is very helpful. Thanks!
Hi, have tried to create an MSI package instead of click-once and its a pain in the ass. I created a support-case for this one and a month later we still hav'nt fixed it. So, please - make the msi-package as easy as the previous versions. I am now waiting for a code signing certificate for about $500 to use the click-once as msi..
You can contact me if you want more information at firstname.lastname@example.org
Pelle - Did you use the sample code for making your MSI package? The samples are described in this blog post:
and the code is posted on Code Gallery here:
-Christin Boyd, Program Manager
Das Visual Studio Tools for Office Team bittet um Feedback für das kommende Visual Studio 2008 Service