I've been toying with the ideas related to adaptive "AI".  The basic idea is:  If you could play a game where the content is adaptive, the game would seem "fresh" longer and you would have more incentive to play the game for an extended period of time.  You can use Genetic algorithms to produce “solutions” to problems automatically….can you then apply genetics algorithms to make games that adapt to the players?  (The answer is “yes”, this isn’t actually a new idea and I’ve already seen research in this area).  However I want to play with some of this stuff, because you learn best by doing things and sometimes you discover things new when you make mistakes doing things you’re trying to learn.

One of the basic requirements of this is to have a “game” that we can control the results of (we want to control the environment and see what the “genetic” aspect will do within it).  So lets define a game where the goal is to "predict" the best move.  One such game we play today is "Rock/Paper/Scissors".  However I want something that can scale to include 5+ players so I've defined the game "Elements".

Elements:  Goal - Choose the element that is opposite of the most popularly chosen element.

Element Choices:

Basic Round Example

5 Players make a choice: E, A, A, F, W

Result:  The players that chose "Air" lose points, the Player that chose "Earth" gains points. 

The goal:  Over a "set" of rounds, maintain a positive score.

So given this kind of game:  If we create a genetic algorithm for making choices, can we make "smart" players (players that are able to react to predictable patterns, and then adapt when changes in those patterns occur). 

So I developed the game and first produced “dumb” players.  Players that that I could dynamically create, but once created would only choose a predetermined choice.

Then I started working on the Smart players:  I wanted a dynamic command set, so I needed to define the command, which then caused a bunch of refactoring because I realized I didn’t just want simple commands like “Choose Fire” but I also wanted complex commands like “Choose the Opposite of the Last Popular Choice”.

So Once I hooked up the command system, I started by creating “random” entities.  And then finally I included the work to do mutation, rewrite an reproduction.  As part of this work I had to write a “fitness evaluation system”.  Basically you need to know when to stop mutating the genetics because you’ve found a solution.  For this particular program, I want something dynamic so I came up with a “generalized” fitness check.  You can be in one of 3 states:  Postiive, Negative, Neutral.  Also we don’t do full evaluation and mutation every round, but rather at the end of a “set” of rounds.  Due to the nature of the game, in most cases any particular player is more likely to have a negative or neutral score rather than a Positive score…so we really only want to make “incremental” mutations if we’re actually keeping neutral.

Mutations and Reproduction:

There’s any number of ways to do this, I chose the “lazy” route, I have a minor and major mutation option:  Minor mutation includes adding (1 or 0) new commands to the (front or back of the) List.  Major mutation involves reducing the size of the list or adding multiple elements. 

Finally we have a “third” case of mutation which is total replacement.  At the point a command set is replaced, in a genetic sense, those genes “died off”.

Hooking up evaluation and mutation:

I decided that I’d track 2 phases of results and during every evaluation phase, I would look at the past results to determine how much to mutate the command set.  If the current and previous results were negative, we have a “dead end” genetic sequence, it dies (replacement).  If either the current or the previous results were negative, we introduce a major mutation.  If we have only neutral and positive results, we introduce a minor mutation and if we only have positive results we don’t change (though we may reproduce if we run a reproduction phase).

And finally, if a command set gets too big, we cause a major mutation (which will reduce the size). 

The final results from initial testing show that given some time, the genetic algorithm can usually stabilize on a solution if there is a stable solution available (simple solutions like “don’t pick Element X or do pick Element X”.  If there are multiple “dynamic” entities involved, it’s possible that they may extend the length of time or make the system unable to stabilize. 

My test app is a bit ugly, but here’s a screen shot of what it looks like:

Possible Future investigation:  Can I get a smart player to predict complex patterns (like all of the “dumb” players play the sequence: Earth, Air, Fire, Water.

I hope you enjoyed my story about delving into genetic algorithms, thanks for reading.

-Kris-

But what does it mean?  Most likely for for those who read my blog to hear about VSTO deployment for at least a year or two, not much, VSTO is still a very interesting technology to me, and I maintain contacts with members of that team, so as I have time I will still write about interesting VSTO related information.  I may actually have an easier time blogging because I won’t have to try and remember what is “new and secret” and should not be announced yet.

On the other hand, I now also have access to a whole new area of information, and I may occasionally post interesting stuff about what I’m doing there.  So what am I doing now?  I’m not testing products as my main focus today, rather I’m building stuff for those who do test products.  I’m working as part of an internal group that develops and supports the base test automation tools we use for driving Visual Studio.  So while I am no longer a “Tester” I lost the “t” in my title in the transition, in many ways I'm still very much in the test field.  As for what I will write about?  Most likely I’ll start talking about interesting experiments, interesting automation related bugs and stuff about the fundamentals of smarter automation design.

Before I get into any interesting code projects, I’m going to share some thoughts about some of the interesting tidbits that have come across my plate:

This section references statements made in the following post:  https://blogs.msdn.com/krimakey/archive/2008/04/18/click-once-forced-updates-in-vsto-ii-a-fuller-solution.aspx

In a previous post I explored what it would take to duplicate some of the functionality that the ClickOnce deployment API provides.  One of the things that was far from my mind at that point was “what happens in the next version”.  Well, one of the really big changes that has occurred is the location of VSTOInstaller.exe.  If you were to write a VSTO 3.0 solution using my example today, and your customer were to install the next version of VSTO Runtime, there is a good chance your background updates would be broken.   But all is not lost!

One option is to simply extend the solution to also check for the newest version of VSTOInstaller.  This isn’t ideal since you really don’t want to update your solution every time a new version of VSTO is released to the world.  Unfortunately I can’t provide you with a bulletproof option to handle the next version of VSTO.  What I can do though, is provide enough information that you are more likely to be successful in predicting what the next version is going to look like.

If you install a Beta version of the Visual Studio 2010 Tools for Office Runtime you may note the following installation key:

This key is the key to figuring out which (copy) of VSTOInstaller you should be using to install/update your solution.

[DISCLAIMER] Anything in the next section is based on a “best guess” approach based on observation only.  I make no guarantees to the future validity of the method against future versions of the VSTO Runtime.

It’s very likely the next version of the VSTO runtime is likely to follow as similar pattern.  Based on this assumption, you should be able to write a fairly resilient bit of code that might reduce the need to make updates to your solution based on changes in the VSTO runtime installation.

The safest method would be to grab all of the sub keys under [STO Runtime Setup] and iterate through looking for sub keys that contain an InstallerPath value.  Take the highest version you find, and you _probably_ will be safe using that path to invoke VSTOInstaller. 

[/DISCLAIMER]

The reason you would want to do this is simple:  VSTO 4.0 was designed to replace the functionality provided by VSTO 3.0.  If you install VSTO 4.0, and then attempt to install VSTO 3.0, VSTO 3.0 will detect that it does not need to be installed. This means you can no longer make the assumption that your customization will be running only against the VSTO 3.0 runtime.  Additionally, even if your customer installed VSTO 3.0 and then installed VSTO 4.0, installing with the older VSTOInstaller may produce unexpected effects (you may incur some extra processing on the first run (post update) of your customization as some new meta-data that VSTO needs won’t be written).

[Correction 2/3/2010]  After a bit of investigation, it turns out I was incorrect in stating VSTO 4.0 prevents VSTO 3.0 from being installed.  You can install VSTO 3.0 on a machine with VSTO 4.0.  This doesn’t change the basic fact that once VSTO 4.0 ships, you should “plan” for your customizations to be installed on VSTO 4.0 only machines also.  While the Bootstrapper will always cover installation of prerequisites (such as VSTO 3.0) there isn’t a guarantee that it will get run on machines that have VSTO 4.0 on them.  VSTO 4.0 does install the mime handler that makes .vsto files “installable”, depending on the situation, it’s reasonable for a customer to skip running setup.exe program and go right to installation of the customization.

The Setup

If you haven’t heard yet, we are in the midst of shipping the Beta for VS 2010.  You can read more about it here: 

https://blogs.msdn.com/somasegar/archive/2009/05/18/visual-studio-2010-and-net-fx-4-beta-1-ships.aspx

There are many exciting new features and changes occurring in this cycle.  As a product of some of these changes I’ve been seeing a lot of questions about some of the changes being made.  I’d like to answer at least one of them now.

The Question

“I went to customize my zone permissions and noticed that the control that lists the zone permissions is missing!  Is this a bug or is this control moved somewhere else?  I need to know how to customized the internet zone so my application will work.  How do I do this in VS 2010?”

Here is a screenshot of said control in VS 2008 (on Vista):

Here is a screenshot from VS2010 Beta 1 (on Server 2008):

The Short Answer

This is not a bug, we intentionally removed this control within VS 2010. 

The Long Answer

So the question itself is just one of the reasons that this control was removed.  As it turns out there is an implied functionality/design in this control that confuses developers about how the security model works.  Conceptually it is easy to look at this control and assume that you can set a “zone” and then customize the permissions that should work within that zone.  But this is not the case and this is where the confusion comes into play.

What this control essentially does is create a Custom Permission Set and compare it to the permission set of a “well known” zone.  If you change the setting element to anything other than Zone Default, you’ve defined a “custom” permission set and that is what your application will request.  In VS 2008 and VS 2010, this same functionality can be achieved by adding the individual permissions to the <TrustInfo> element in the app.manifest file.  In VS 2010, this will be the only way to define a “custom” permission set.  You can find an older MSDN article on how to do this here: https://msdn.microsoft.com/en-us/library/6ad1fshk(VS.80).aspx.

Our belief is that most customers that use this control are under the impression they get some benefit from using the custom sets, but in most cases they are not getting the benefit they believe they are getting.  The misconception comes about because the impact of changing things in this control are non-obvious.  So let’s break this down into 3 scenarios and describe what happens, why, and alternatives that get the same effect.

Target Internet Zone:  Do not change anything.

If your application really does need only the internet permission set, it will work without a trust prompt as long as you run it from the following zones:  Internet, Local Intranet, My Computer.  You do not see a trust prompt (assuming your application is signed with a “known” certificate that chains to a Trusted Root Authority) because you have provided “evidence” (the permissions you requested,where it is run from, and a “known” certificate signature) saying your application will only execute within the confines of the functionality allowed for applications that execute within that zone.  If your application needs any permissions outside of this zone, it will fail with a “trust/security” error.

In VS 2010, we support this scenario with the current UI, the “Zone your application will be install from:” control is what determines the permissions set. 

Target Internet Zone:  Remove a Permission.

You are no longer targeting the “Internet” Permission set but rather a custom set.  If your application is published on the internet, local intranet, or my computer zones, it will function without a trust prompt exactly like targeting the internet zone.  There is a caveat here, but I will come back to it (See Caveat:  Least Permissions).

In VS2010, there are 2 options to achieve this:  You could have simply targeted the internet zone or you can define the custom set your application needs in the app.manifest file manually.  Our general recommendation is to target the well-known-zone that your application runs from rather than defining custom permission sets.

Target Internet Zone:  Add a Permission.

In this scenario, your customers will get the ClickOnce trust prompt.  We believe users of the permission set control fall into this bucket.  The reality of the security model is that at this point once you have incurred a trust prompt of any kind you might as well be targeting “full trust” since your end user will not see a difference.

In VS2010, if you cannot run under the permission set of the zone you are targeting, we recommend that you switch your application to requesting full trust.  Functionally to the end user, this is exactly the same as if you had targeted a custom set that exceeds the permissions of the zone your application is installed or run from.  You can manually configure the custom set using the app.manifest xml file within the project.

Caveat:  Least Permissions

Our team is aware there is a segment of our developer customers that prefers to target the “least” number of permissions required in which to run their application.  While we do understand this UI made it much easier to do this, we believe that this segment is familiar enough with permission sets that they are capable of achieving the appropriate settings using the app.manifest xml file.  Please continue reading if you would like to understand the other justifications for why this UI was removed.

How we came to this final decision (or rather “other aspects involved”):

Generally we don’t remove UI or features without good reasons.  In this case, we discussed at length with the Security Team about this specific piece of UI.  They have indicated to us that they believe the general focus of their customers should be to move away from “custom” permission sets and more to targeting only the well-known permission sets or fully trust.

Beyond the general “this is the direction we want to take this feature,” VS 2010 includes some changes that made removing this UI desirable from a technical perspective.  If you have not noticed yet, VS 2010 allows you to target/build and debug solutions against both CLR 2.0 (.NET version 2.0, 3.0 and 3.5) and CLR 4.0 (.NET version 4.0).  Visual Studio itself runs against CLR 4.0.  In previous cycles, the assumption was that VS would only run against the CLR version it targets, but that assumption is no longer true.  As a result, many elements of VS have had to change because VS cannot always rely on the CLR it is running against to provide the correct information for the project (if it targets a different CLR).  Our permission set control falls under the bucket of things that functioned on this basic assumption.  When we looked at what the cost of changing the design was and how it would impact the overall user story, we determined that it was better for our customers that we removed the UI and focused on improving the other aspects of the product.  We feel that the loss of improved functionality (how easy it is to setup custom permissions) did not outweigh the gains we could apply elsewhere.

Thank You for reading.

Kris

Generally I focus on more of the technical aspects of what you can do without really talking much about some of the other considerations that should go into make your deployment design decisions.  This post is going to be a little different.  I won't have any nuggets of deployment code or advice on how to achieve specific deployment actions, rather I'm going to cover some of the details that you might want to include into your evaluation before you decide "how" you will deploy your solution.  Essentially this post will be about how to go about designing your deployment (what factors you may have to consider and how they will impact your deployment implementation).

First, some terminology:  I have been known to throw around the following terms and haven't really defined them in any consistent way, so I'm going do so now.

Customer level solution (customer solutions, customer deployments):  Solutions in this class of products that are released to the general public.  Generally as far as deployment goes, Customer solutions are deployed by some kind of opt-in methodology.  Customer solutions have constraints unique to not always having control of the system in which the solution is installed into.

Small Business level solution (smb solutions, smb  deployments) :  Solutions in this class of products that target user bases encompassing 10 - 200 clients.  Deployment and installation state may be controlled by a central organization or individual.  SMB solutions generally have some moderate to low-level infrastructure such as an intranet and UNC servers.

Enterprise level solution (enterprise solutions, enterprise deployments):  Solutions in this class of products will target a set user base of 200-100,000 clients.  Heavy infrastructure is available and both deployment and installation state are controlled by a central organization (IT department) with dedicated resources for management and support.  Constraints on this level are often defined by such issues as infrastructure constraints, machine state preservation and maintenance impact.

I'm going to focus on the enterprise solutions and some of the specific details that an IT department may impose on deployment configuration and maintenance decisions.  Enterprise solutions should have 4 specific phases of a solution's lifetime that should be considered before making deployment design decisions.  These phases are initial rollout, solution maintenance (updating), emergency response and uninstall.  

Initial Rollout:

When considering Initial Rollout, there are a number of factors that should be considered.  One of which is the bandwidth-to-client metric (versus solution size) and the window of opportunity for rollout.  Simply put, how long is it going to take to for every client to download the solution the first time.  Here are some numbers and math.

First, assumptions and caveats:

All numbers here are idealized, actual networking is never as nice as this idealized form.  The assumption for the following graphs is that you are hosting all of the data at 1 machine and the network bandwidth is the idealized out-bandwidth of the publish server.  VSTO solutions may range in size from 100KB to 50MB or more depending on any number of factors involved.  As a reasonable medium point I'm choosing 5MB with the assumption that most solutions will sit somewhere within this upper bound. 

Next, the formula:

Rollout Time = Amount of Data / Speed of Data

Rollout Time (minutes)  = ([number of installs] x [Installation Size]) / ([Bandwidth] x 0.125  x 60)

Bandwidth is generally stated in megabits per second (mb/s), but we need to calculated based on megabytes (MB) and minutes thus the multiplication by 1/8 and by 60.

Finally, Data:

Solution only installation (no prerequisites)

100 megabit network

1 gigabit network

However these are the "best case" roll out scenarios give that you may not have all of the prerequisites.  Consider that the following are common prerequisites that you may have to also install:

Office 2007 PIA redist:  6.82 Mb

VSTOR 3.0 SP1 redist: 3.27 Mb

Solution, Runtime and PIAs

100 megabit network

1 gigabit network

What we can draw from these numbers? Nothing specific, these values are based on idealized networking and don't take into consideration a lot of factors that may have a greater impact on your deployment design.  What they do give us though is a basic framework to use as a basis for further discussion.

Specifically, as your organization is bigger or has less infrastructure, there may be value in breaking up the initial roll out into waves or separate deployment sites.  If you have an organization of 10k or more employees, there is a pretty high chance you can use geographic based division to save a lot of pain and allow you to handle the initial rollout in a controlled manner.

Let's move on and talk about some of the other factors that should influence the rollout.  One things that comes to mind in particular is the prerequisites.  By default VSTO publishes a Setup.exe file that is meant to be used to pull prerequisites down to client machines that don't have them installed.  If the prerequisites are not present you may want to roll them out first and possibly even rollout a "dummy" solution that allows you to track the number of successful prerequisite setups.  When you then push out the "real" solution, you only need to worry about the solution itself and not the problems that would be caused by failures in the prerequisites. 

Work habits is another factor you have to consider for initial rollout.  You may consider pre-registration of an Add-in as possible Rollout mechanism, but if you do you should be aware of the impact this specific factor may incur.  Specifically if your clients all connect at the same time or if it is staggered over a period of time there may be a much higher bandwidth cost.  An example graph below compares relative network usage versus Initial connection of clients (the data is made up but it demonstrates the basic idea).

In this example:

In this example we have a case where the bandwidth usage of installing the solution on all clients exceeds the capacity of the network infrastructure.  In both "scenarios"  the bandwidth speed and data served is the same, but the final results (and subsequent customer impact)  differ because of usage patterns. 

Scenario A is where a natural Bell curve occurs between 8:00 and 8:30.  Initially only a couple of clients start the installation process at 8:00, at 8:05 more connect, at 8:10 the highest number of clients are connecting (about 50% of the total) and then as time progress fewer clients are connecting. 

Scenario B is where All clients connect at the same moment (at 8:00)

The key take-away from this example should be the effect that spreading out the install step can have.  In both cases the network usage peaking is causing a delay, but in one case the delay is at least 15 minutes in length for some clients.  If you're in a situation where your clients have common peak times (specifically around startup) you will want to reduce the amount of potential impact your rollout will have.

Now that we've established some of the factors, lets talk about some specific design choices you might make based on how these factors impact your specific deployment story. If you're in an enterprise that is just beginning to rollout .NET 3.5 (or 3.5 SP1) and the VSTO prerequisites, you probably specifically want to roll out the prerequisites ahead of time to ensure that when you finally do roll out your specific solution code there are fewer kinks to work out in both steps.  Using a "test" add-in (specifically on the Application you plan to customize) may help flush out any issues related to initial prerequisite installations.

There are 2 basic paths you might take to propagate the solution out to your clients. 

The ClickOnce method may be used by forcibly installing the prerequisites (which are machine level and require administrative access) and then pushing a ClickOnce registration (of and Add-in) to all user accounts  (for documents, simply making the documents available is the same as registering the add-in).  The first time your solution consumers login on a client machine and start the customized application (or open a customized document) Clickonce will pull down the solution (from the location you specific in the registration) and store in the cache on that machine.  Depending on your user statistics this can result in a installation really bad peaks.  If you find that you might have this kind of peaking behavior there are some specific options you might employ to reduce the rollout impact.  One option is to stagger the registration step.  By introducing the registration in waves you can reduce the "height" of the peaks to something that doesn't significantly impact your user base.  Another option with particularly large rollouts might be to host the solution on different servers.  Doing this breaks up the load but keep in Mind VSTO ClickOnce doesn't really have a good mechanism to allow you to load balance these solution.  Once an installation points to a specific deployment (publish) server, it will always point to that server.  An uninstall and reinstall (on each client) would be necessary to migrate client installations.

The vstolocal method would be the alternative.  Similar to (or possibly using) MSI installations you would copy the customization contents to a specific location on the machine and then push down a registration with the |vstolocal tag.  Using this method would allow you to be more specific about "when" the solution is installed.  With the vstolocal method, the "hard" work is all in getting the client computer properly configured once you've achieved that, the subsequent rollout should just be a matter of "when".

On trusting the solution:

In both cases, you may want to use certificate trust since it allows you to trust the solution for all users on that machine.  If you do not use a trusted publisher certificate approach, each of your users will incur a trust prompt on the initial execution of the solution on each client (example: Joe would see it on Client A and Client B but Bill who only uses Client B for the customized app only sees the prompt on Client B (though both will see it on Client B)).

Solution Maintenance:

Depending on the nature of your solution you may be planning regular updates, infrequent updates or no updates at all.  When considering the design of your deployment story, you should consider how updating is going to impact your usage scenarios.

When using "vstolocal", updates are entirely based on a push model where you have to push a new version of the manifests and  executable files to each client machine.  Every update in this model will pretty much have the same impact as incurring a solution only initial rollout.

If you use ClickOnce, there are several options for managing updating.  ClickOnce itself allows for determining the frequency of update checks but there are scenarios with this that you may want to consider.  Generally the cost of checking shouldn't be significant issue, when a check is made, only the deployment manifest is downloaded to the client.  Most manifests should be in the 6k - 10k size which means even with a 100 mb/s connection, a 7 second delay would only occur if around 9000 clients attempted to check at the same moment.  It's not really the update check that is likely to cause problems, its those times when an update actually exists to be downloaded (the amount of data and subsequently bandwidth is a magnitude larger).  The same basic network metrics and usage patterns in the initial rollout may have similar impacts on your usage experience so it's a factor you should consider in your design.

One possible method of reducing spiking on "update days" is to stagger when the update checks occur.  This prevents spiking but it also delays when all clients will have the update and can be problematic if older clients can cause problems with newer clients when they share data sources (ex:  your solution access a Database and an update includes a Database Schema change that causes issues when older clients attempt to manipulate data). 

Another potential flaw with staggering updates is relating to a natural tendency for "bunching".  This is best explained as an example: let us just assume for the sake of this example, profiling indicated that having every client download updates on the same day would over-tax the resources available.  So to mitigate the problem the initial rollout occurred over the course of a week (5 days) and the each client was set to check for updates every 7 days.  So each day of the week, 20% of your clients check for updates first thing in the morning (an assumption that every client opens the application at least 1 time every  (work)day is made here).

The problem occurs whenever vacations or Holidays occur.  Each day that users are not logged into client machines the scheduled checks (for the missed day) to check on the next day.  What this ends up doing is causing bunching up (most likely around the middle of the week).  Here is little example graphic to demonstrate what this might look like:

Initially in the first week all clients are checking in a consistent pattern and no spike in usage occurs.  However on the second week, Monday and Friday are both Holidays.  On Tuesday 40% of the clients are checking for updates since the 20% from Monday were unable to check on their "designated" day.  Additionally on the third week, due to Monday and the previous Friday being holidays, now 60% of the users are checking for updates on Tuesday (and 0% are checking on Friday and Monday).

One mitigation for this is to delay checking for updates by a larger chunk of time (3 weeks for example) and providing a bigger buffer between each "wave" of updates.  There are other methods you might work around this behavior (rather than using automatic checking, using the ClickOnce API and controlling when update checks occur similar to an earlier blog post I had about creating a "check for updates" button).

Emergency Response:

While no one wants to ship a bug or have cases when a solution has been compromised by a virus or hacker, it is important to be aware of what you can do to mitigate the impact when these things occur.  By having a clearly designed response ahead of time, it may be possible to reduce the severity of the impact on your business operations by reducing the response time and window of opportunity for damage.

If you use vstolocal there are 2 specific methods you can take to mitigate a bad customization.  The first option is to disable the solution.  There are 2 methods:  force an uninstall on user startup or an alternative is to simply push the solution certificate into the Untrusted Certificates Store.  One of the subtle behaviors of vstolocal is that trust of the solution is always evaluated at startup.  This works from an administrative (machine) level and doesn't require pushing out any action to specific users.

The other option is to for a registry disable of the customization (set the load behavior to 2).  This works to shut down the solution from automatically starting up and causing further harm but it doesn't prevent users from re-enabling the solution via the com-add-ins dialog in office.  Additionally, disabling the add-in in this method requires pushing the change to every user on every client. 

The second method for vstolocal solutions you might take is to simply force an uninstall of the solution, this prevents the solution from being re-enabled by the user but again incurs a user level action.  This depends on good authoring of your deployment mechanism (I'm assuming this to be an MSI).

If you deployed using ClickOnce, you can't use the Untrusted Certificates store to block/disable existing installs (of the bad update) since security for ClickOnce solutions is only evaluated when we copy the solution contents into the cache.  However you can push out commands to VSTOInstaller to force an install or alter the user level registry to disable the solution (same as described for vstolocal). 

If your solution checks for updates on every run though, you can push out a rollback by simply replacing the "bad" version with the version published previous to it.  Any users who had not updates will not see any effect (they will not have pulled down the "bad" update) and any users who installed the bad version will be rolled back to a working version.

The last option may be to write some code in the initialization of the customization to check for a "halt" registry key in the hklm registry hive.  This allows you to push out a single key to every client machine disabling the solution for every user on that machine...but it does require designing this functionality into the solution immediately. 

Uninstall:

Preparing for the end of life for your solution is part of proper deployment design.  When you are looking at Enterprise level solutions, you need to determine how responsive you want the uninstall process to be.  If you use vstolocal deployment, the work for uninstall is achieved by removing the solution files and then further forcing an deletion of the registration of the add-in for each and every user.  

With ClickOnce Installation, there isn't a specific mechanism built-in for pushing an uninstall out to every user, however VSTOInstaller does support a command line only uninstall.  The command would be something of the format:

%commonprogramfiles%\microsoft shared\VSTO\9.0\VSTOInstaller.exe /Silent /U "{publishlocation...Addin.vsto}"

You probably want to use the silent flag specifically to prevent your users from blocking the uninstall process.

Similar to handling an "emergency response" situation, you may simply want to bake a registry check to cause the solution to uninstall itself.  The problem with this method though is the registry key is left around (assuming it is in the hklm registry hive).

Another possible method for handling the final uninstall:  publish an update that calls VSTOInstaller to uninstall at add-in shutdown.  This this should work because fusion copies the solution executables into a shadow cache during execution (although you may want to ensure no references to (data) files exist at the moment (in execution) you call uninstall).

Thanks for Reading (and being patient enough to stay with me over a long break)

Kris

Adding VSTOR 3.0 and .NET 3.5 SP1 Patch Redistributable's: 

We've added some additional functionality to the base VSTOR 3.0 Runtime that you can actually take advantage with RTM Applications.  As such, if you install the SP1 patch on your development machine, you should be able to include the SP1 patches for both .NET 3.5 and VSTO Runtime 3.0. Adding these patches to the bootstrapper will not upgrade your existing customers but any new customers you have will be able to take advantage of the new functionality without any changes on your end.  Any previously existing customers could re-run the Setup.exe file to receive the upgraded functionality. 

One thing to keep in mind for these changes I'm describing is that the customization itself is not being upgraded, just the runtime it runs on is.  If you have to recompile your customization against the SP1 Runtime to take advantage of a new feature, your customization will not work for your customers who don't install the SP1 patches.

Additional Redistributable Package, the Office 2007 PIAS:

We've authored an Office 2007 PIA installer for general consumption.  In general, Office 2007 will install the PIAs by default, specifically it will install them if you have a .NET Framework installed on your machine at the time you install Office.  The problem with this is that it turns out a lot of you out there still use XP and clean installs of XP do not come with .NET installed.  As such we've included a PIA redist package that you should be able to include.  This package looks for a previous instance of an Office PIA existing on the machine before it does anything that might require elevation. 

Event Logging:

Specifically any deployment errors that occur on your client machines will by default log the error directly into the windows event log.  The functionality here isn't particularly rich, we've basically taken the same information that we display in the "alert dialog" that turning off VSTO_SUPPRESSDISPLAYALERTS enables.  The key here is that you should now be able to excavate what the actual cause of error was even if the issue is resolved before you get a chance to investigate.

Update Cancellation:

In RTM the timeframe in which an update can be "successfully" canceled is very small.  If the user cancels the updated outside of that particular window the VSTO Runtime sees it as an error case and blocks further execution of the customization.  Based on your feedback, we changed this behavior in SP1 such that you should now be able to cancel an update and continue running the previously installed version.   There are still cases where an error will occur (an example would be if you are installing the customization for the first time) but in general this should be a lot closer to what you guys told us you wanted.

Thank You for Reading.

Kris.

PAX is one of those things that helps me recharge once a year, get a bit of a look into what is coming down the pipeline and occasionally just see what other interesting things are going on in the entertainment industries of my choice.  At PAX I tend to focus more on seeing things rather than playing (I usually try a couple of game) there were some very interesting videos of the new stuff coming up and some very compelling demos also.  One thing in particular leapt out at me:  Popfly might be a very inspiring way of easing some of those non-programmer folks into understanding how things are put together.  I completely recommend taking a moment to look at this, especially if you have children you want to get interesting into the whole software industry.  At one point a 12 year old (I think he was 12, may have been younger) was demonstrating his game "apple eater".  Pretty much a Pac-man clone that he put together. 

So enough with the games, I know most of you are probably more interested in VSTO.  So here is something related to VSTO.   I have to admit that for me this is kind of an ego boost.  I don't generally put together videos since I feel like I don't have anything worth saving to a camera but when given the opportunity to create one focused on some of the VS 2008 Sp1 features, I couldn't pass it up.  It's pretty short, but there you go.

Thanks for Reading

Kris

It's nothing too ingenious but it gets the job done.

So...here we are with an MSI but I want to be able to somehow integrate this into the setup.exe file that gets created for my VSTO customization.  The first step to doing this is to author some bootstrapper manifests.  Specifically a package.xml file and a product.xml (for each supported language) needs to be created.  Thankfully the is a powertool that will help you do this. 

David Guyer has produced an exellent simple to use UI Tool to help with creating the bootstrapper manifest.  You can get the VS 2008 version of the tool here: https://www.codeplex.com/bmg/Release/ProjectReleases.aspx?ReleaseId=10652 .  This tool is currently listed as being in Beta and I still had to do some manual work to get everything lined up.  Here are the steps I took:

• Open BMG for VS 2008 (installed it should show up under the Visual Studio 2008 folder).
• Create a new "Package Manifest" Project.
• Right Click on the left pane and select [Add Install File]
• Select the MSI file via the [Browse] button
• Set the Display Name (this will show up in VS)
• You can include a text License Agreement file (this will be displayed before the MSI is ran).
• Make sure to include a "Success" Exit Code on the Exit Codes tab.
• By Default the Hashing method is used under the Security, I did not change this, but you should be aware of it since it means that any changes to MSI after creating the Package Manifests may cause errors.
• Click Build.

As you can see, I get this warning about the Product Code.  I talked to David Guyer about this and here was his comment:

I think once you enter a display name, I try to autogenerate a product code.  Just to help clarify, the bootstrapper’s product code is not the same as the MSI’s product code… so you don’t need to enter the MSI’s product code…  a bootstrapper product code is something typically like “Microsoft.VisualBasic.Powertoys.1.0”

You can manually add this to the files.  If you go to the build output folder you will see all of the files

So the Product.xml file should look something like this:

<?xml version="1.0" encoding="utf-8"?>
<Product ProductCode="" xmlns="https://schemas.microsoft.com/developer/2004/01/bootstrapper">
  <PackageFiles CopyAllPackageFiles="false">
    <PackageFile Name="setup1.msi" Hash="DD8BF9497F8447128E4F6C72C8D30D8E2871E9BE" />
  </PackageFiles>
  <Commands Reboot="Defer">
    <Command PackageFile="setup1.msi">
      <ExitCodes>
        <ExitCode Value="0" Result="Success" />
        <DefaultExitCode Result="Fail" String="Anunexpectedexitcodewasr" FormatMessageFromSystem="true" />
      </ExitCodes>
    </Command>
  </Commands>
</Product>

The last steps are to add a Product code to this file and then copy the files in the Build Output folder to the prerequisites directory.

The path shown here would be: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\My Custom Prerequisite\

Once you've done that you should be able to include your custom prerequisite step as if it was just another standard part of your setup.

I'm going to end with that, it should be enough to get you started on deploying even more powerful and interesting VSTO solutions.

Thank You for reading.

Kris

So first you need to create your custom prerequisite installer.  I believe any executable can be used but for this post I'm going to cover a method where instead of using an "executable" I'm going to build an MSI (Windows Installer).  I might come back to the executable option in another post, but with that lets move on. 

Creating a Custom Prerequisite MSI that does something:

For my first try I actually created a custom .NET DLL that did my prerequisite step (in which I just to display an Message Box to ensure it was working).  To do this I created a C# class library project and added a new "Installer Class" to the solution.   Here's what the code for that class looks like:

namespace CustomAction1
{
    [RunInstaller(true)]
    public partial class Installer1 : Installer
    {
        public Installer1()
        {
            InitializeComponent();
        }

        public override void Install(IDictionary stateSaver)
        {
            base.Install(stateSaver);
                        
            string messageString = "Message Strings: \n";

            messageString = messageString + "Message:";
            messageString = messageString + this.Context.Parameters["Message"];
            messageString = messageString + "\n" + "OtherMessage:";
            messageString = messageString + this.Context.Parameters["OtherMessage"];
            System.Windows.Forms.MessageBox.Show(messageString);
        }
    }
}

I built this action and then created a "standard" Windows Installer Project.  I ripped out all of the steps from the MSI project and then added Custom action.  To do this, I added the "Primary Output" of the dll project to the project and then go to the Custom Actions pane via the view option in Setup Project. 

Once there I was able to add the "Primary output from CustomAction1" (the dll) as an install custom action.  In the properties window for the custom action (you have to select it) I set the following values: 

CustomActionData = /Message="Message1" /OtherMessage="This is the other Message"

InstallerClass = True

And with that I had my CustomAction MSI (I left it labelled "Setup1" in my example).  This is about as simple as it gets and it doesn't nearly cover everything (I didn't implement Uninstall or Update steps).  I believe the "power" in the MSI method is that you can hook into a standardized setup framework and it handles a lot of details you would otherwise need to implement.  This goes a little outside my particular area of expertise and I haven't had time to do the full degree of experimentation to give a definite reasons beyond that yet though.  If anyone is interested in educating me or clarifying anything on this stuff, please feel free to leave a comment.

In the next installment I'll cover how I authored the package manifest files so VS can include this at publish time.  

My post frequency has been a down a bit lately due to being busy with a lot of things but I am responsive to feedback (I've gotten a littler here and there, please feel free to post any comments or questions here so others may also get the benefit of it).  And with that I'm going to wrap up this post.

Thank You for reading.

Kris

https://blogs.msdn.com/vsto/archive/2008/05/29/deploying-office-solutions-with-a-setup-project.aspx

If you're not convinced the ClickOnce deployment model is for you, this is the method you should consider and I recommend reading this paper and looking at the example before proceeding.

That's all I have for the moment, I'm looking for any interesting stories or questions to answer though, so please feel free to send me some feedback.

Thank You for reading. 

-Kris-