We Keep Coding

Upgrading Application using InstallShield

This is the situation I have:
I created an installer. It has python scripts, executable, and other file types. In the installer, I run a C# executable as a custom action, after registering the product. The C# executable moves the files into different locations (i.e. a text document will be moved to My Documents). I understand I can do this without the custom actions, but I was not aware of that when I created the installer.
Now, after I have distributed the software, users are running into small bugs. For instance, there is a bad if check in one of the python scripts.
Question Is there a way to fix the portion of the python script/executable/text document that is broken, and simply update those files (without having to redistribute the software to the users, and having them reinstall it)?

A patch probably won't help you. If the locations are fixed within the install, a minor upgrade could do the trick, if you make all the files that need to stay the same "never overwrite" (unless the custom action ignores this, then things might get difficult).
If the locations are determined during the execution of the custom action, or the locations are based on user input during the install, then you have a problem if you haven't saved the location paths (in the registry, for example). I don't think you want a custom action to scan all the drives of the computer just to find the files.
If the files are put in their new locations by the custom action, windows installer probably won't see them as key files and probably won't "repair" them in any scenario. If the fixes are few, you might be better of distributing the files separately with a clear instruction, in stead of spending many hours on a difficult new custom action.
Cheers, B.

I'm sorry, apparently I missed the trigger that you had placed a comment.
If this is this something you would like to know, look at this table. It shows when to use major, minor or small fix (patch).
Hope it helps.
Cheers!
http://helpnet.installshield.com/installshield17helplib/MajorMinorSmall.htm

What happens the Files when i update the app?

I'm developing a simple Windows Phone 8 game and suddenly a question popped up in my mind? What happens to files (ex: Score.xml) when i update the app. Update overwrites all the files or keeps them or what?
Say you have an xml (Score.xml) file which keeps the scores. This is the orginal file:
<Score>
<LevelOne Score="0"/>
<LevelTwo Score="0"/>
</Score>
User keeps playing the game, as you guess those Score attributes increases. After few months later, think you will gone update your game with new xml file (Score.xml):
<Score>
<LevelOne Score="0" HowManyTimesPlayed="0"/>
<LevelTwo Score="0" HowManyTimesPlayed="0"/>
</Score>
What happens in this situation? Now we have old Score.xml that keeps users current score information and we have new Score.xml in the update that starts from scratch with new attributes? I made my apps with database before but in this game i don't need it. I need simple xml files. Very confused right now and don't know how to search even this situation in holly google. Did i misundestood something? Guys i really need your help :/

Your data will be preserved during the update procedure - MSDN:
When you update your app, any data in the isolated storage is preserved. However, data in the isolated storage is deleted if the user uninstalls and then reinstalls your app. For more information, see Data for Windows Phone 8.
It's your responsibility to correctly handle all old files.
I would advise you to publish (after succefull testing with deployment via VS) a beta version (for example limited only to you) and test updating procedures. From my experince it is very important thing to do - there may be many pitfalls and there is nothing worse than the app that fails after the update - so check as many times as possible.

As Romasz said, you have to handle all old files in IsolatedStorage yourself. I just wanted to add a few suggestions/hints about how to do it:
Know when the version has changed.
Keep the app's previous run version in a file. When you run the app, check if the new version is higher than the one from the file and if so - update what you need and then update the version stored in the file.
In some cases it's good to know by which version of the app was a file last modified. You can store the app version in that file and add some logic when the file is deserialized and the version in it is old.
In some cases you may need to make changes that will make the new class incompatible with the old file. Of course, you will still want the data from the old file, so here are two ways (I can think of at the moment) that you can handle this:
On update, open the file as XmlDocument/XDocument and modify it accordingly to make it compatible with the new class.
If there are a lot of changes, create a completely new class with the new data that you want to serialize, and leave the old one untouched. Then, on update, convert the old files to the new files. (You'll be deserializing the old file as the old class and then saving a new file with the new class.)
Triple check everything in the update. Deploy the old version, use it for a little and then deploy the new version to see if the update is handled correctly. (Okay that's not about handling but it's very very important.)
I hope this helps someone. :)
Update //Thanks to Romasz
You should keep update code for previous versions. Someone may for example update from version 1.3 to version 1.6, without going through versions 1.4 and 1.5. In this case, you may have several things to do on update.
Basically the code for update ends up being something like:
if (oldVersion < new Version(1, 4)) {
//update what changed from version 1.3 to version 1.4
}
//no need to update anything from version 1.4 to 1.5
if (oldVersion < new Version(1, 6)) {
//update what changed from version 1.5 to version 1.6
}
So, when someone updates from 1.3 to 1.6, both update procedures will be executed, with the older one being first, as it should be.

It really depends on where and how you are storing the XML file. But because you are modifying the file at runtime I am assuming you are storing it in the isolated storage. In that case the file will not get overwritten when you update the app.
If you want to be 100% sure,
- deploy the debug version of the app, using Application Deployment tool, to your test mobile/emulator
- use the app for a while so that the xml file gets updated
- recompile (not Rebuild) and redeploy.
If the changes remains intact after redeploy, you are good!

Auto Merge Code from Shelfset in TFS

Was working on new functionality in a code file... ManageTime.cs.
Had a bug fix request come in for a bug in the same file.
Used Visual Studio TFS to Suspend My Work.
Fixed bug in ManageTime.cs.
Now What?
Do I Check in ManageTime.cs, then can I resume my shelf set and will it handle merging the shelfset with the new feature code?
Afraid to try without some direction for fear of losing code.

Yes, if your team's policies say that you check in the code after your bug fix, go ahead and do that. If you aren't ready to check in or don't want to check in at this time, but are worried about losing work, you can always create another shelveset just in case (keep the Preserve Pending Changes box checked so you keep your bug fix changes).
Once you are ready, find and unshelve the shelveset. Just like getting the latest version from source control, VS will try to automerge the changes. If there's a conflict that it can't resolve, you'll get the same Resolve Conflicts window that we're used to seeing from time to time to manually resolve the conflicts.

Your assumption appears to be correct. Suspending your code essentially shelves the code along with a few Visual Studio settings such as window location, open files, and similar things. As long as you shelved (suspended) your in process work, then checked in a different bug fix, you should be able to merge with your updated source code once you resume and get latest version.

How to create Application.exe.config in application directory

So I recently updated my application to support a new feature. In the past if the configuration file was deleted by the user it wasn't a big deal. This new feature requires it to exist, and one of the requirements is that, the file exists in the application's installation directory.
I have notice when the file is deleted ( depending on variables I have not figured out ) I get a .NET notification that the configuration file is missing or corrupt. Currently my program then crashes ( I still have to figure out how to duplicate this behavior ) which is the reason for this question.
I am familar with ConfigurationManager. I am having trouble writting the file once the default values are loaded. Forcing a Save for some reason does not seem to recreate the file, at least not in the installation directory, which is a requirement.
I am looking for guidence on how to handle this corner case in an elegant manner. I would post code, honestly its just all failed attempts, which while my attempts do generate a file the contents are not the settings I am looking for.
I am willing to post anything that might be able to help.

Stop using the built-in config support and just use write/read to a file called something.exe.config using the standard XML classes and if that gets deleted, just re-create it from values hard-coded in the executable.
The config file support is supposed to make things easier, if you need to do stuff where it makes things difficult, don't use it.

Something like
var wcfm = new WebConfigurationFileMap();
Configuration newConfig = WebConfigurationManager.OpenMappedWebConfiguration(wcfm, "/");
newConfig.Save();
doesn't work?

You dont. Under normal conditions the program can not write into it's install directory - this is a standard windows security issue and the reason why app application data should reside ni external (from the exe's point) driectories.
If an admin deletes the config file, crash, ask for reinstall. There is nothing you can RELIABLY do, as you can not assume you can write into the folder at runtime. A message followed by an event log entry is the best approach here. Users are not supposed to delete parts of the application.

Releasing WinForm Program Updates

I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.

I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/

ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.