We have a customized version of the Agile template that we've been using since TFS 2013. I have upgraded the template for 2015, which was no big deal. But when I go to upload it I get error "VS402479: You can't overwrite the Agile process template, because it's locked".
I have followed the instructions from MSDN to upload an updated process template. I have changed the name, description, and minor version strings as described in the documentation.
Here are the values from the metadata node in my ProcessTemplate.xml file:
<name>Custom Agile</name>
<description>Custom Template based on MSF Agile</description>
<version type="ADCC42AB-9882-485E-A3ED-7678F01F66BC" major="14" minor="20" />
I have tried changing the major version and the minor versions to different, higher increments, and receive the same error.
If I change the type to a different Guid, the template loads just fine. The instructions imply that the Guid should be the same. I'm assuming this is so TFS knows the relationship between the built-in templates and custom templates they are based on.
I have a bunch of team projects to update the features on once the upgrade is complete and do not want to break the relationship to the built-in Agile process template if I can help it.
You can no longer edit or delete the built in templates in TFS 2015 so you'll have to change the Guid if you want to upload your template.
Process Template changes to TFS 2015 RTM
In TFS 2015, the system templates are locked and cannot be changed. That change allowed us to overwrite the templates we ship, and with that we were able to rename the templates to Scrum, Agile and CMMI.
To create a custom process template based on a shipped template, simply export an existing template, give it a new name and version, and then reimport it by using the Process Template Manager. Existing projects are unaffected by this change, which means that they can continue to have their process customized by using witadmin.
We have determined that this issue is not a bug. To upload a custom process template, not only the Process template name needed to change, but the version id also needed to change.
In the ProcessTemplate.xml file, find the following settings:
<version type="ADCC42AB-9882-485E-A3ED-7678F01F66BC" major="15" minor="10" />.
Change GUID string to another value. Then try to upload the custom template again.
You can generate a new Guid by using this C# code:
Guid g = Guid.NewGuid();
string s = g.ToString();
Related
What is the standard way to handle web.config files during major upgrade.I'm aware how the unversioned files are handled during upgrade,the file will not be replaced if the file has been modified by the user.
Is there a way to deal with the scenario where in there are new entries added to config file bundled with the latest installer that needs to be installed,and also retain the existing entries modified by the user during major upgrade in Wix.
The simple solution that a lot of my customers have liked is to not put user data in the web.config. Instead we use the AppSettings#file and ConnectionStrings#ConfigSource elements to specify an override file and keep the user data there. What MSI doesn't know about it won't tamper with. Now you don't have to be an MSI component rules wizard.
https://msdn.microsoft.com/en-us/library/ms228154(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource(v=vs.100).aspx
I know the question is for Wix, but just wanted to point out how much time commercial tools can save in such scenarios.
For example, using Advanced Installer you can read and load into an MSI property any XML values and then use the XML Files updater to write dynamic content in the files, at install(upgrade) time. (check the videos at the end of each article for a quicker overview)
Disclaimer: I work on the team building Advanced Installer.
Set the component to always overwrite and write a custom action to add the needed information to the config file.
The only way that seems possible is a custom action to merge the entries in the new file into the existing file, because you want data from the existing a new files. You would also need the upgrade scheduled late (after InstallExecute) so that the upgrade isn't an uninstall of the old product followed by an install of the new product.
If you are doing an upgrade (the WIX_UPGRADE_DETECTED property will be set by a MajorUpgrade element), so update the existing file, otherwise install the new one.
There might be a way to express the updates as an Xml transform, so something in the WiX util:xml tools might help do an update.
Installers of previous versions of our software include a Component File that was NOT marked with Permanent="Yes". Now, we wish to read the pre-upgrade contents of this file during the upgrade process, which will overwrite the file with different contents. Is there a good way to do this?
It would help if you said exactly what you were doing that would cause the file to be overwritten. Some major upgrades (is that what you're doing?) will do a complete uninstall of the product first, followed by a complete install of the newer product. If that's the situation then use a custom action sequenced before RemoveExistingProducts to back up the file somewhere so that your application can retrieve the content, or get the content you need before it's ovewritten.
If you are doing a major upgrade sequenced later (such as afterInstallExecute) or you are doing a patch then it is by no means certain that the file will be overwritten because file overwrite rules will not replace a file that has been updated since it was installed. If the application altered the file then this type of upgrade will not overwrite it:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx
Or in the case that the file is unchanged since it was installed, change the dates so it appears to be modified, as described here:
https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/
It's also not clear that Permanent=yes is what you want anyway - that would glue the file to the system forever. You may be thinking of NeverOverwrite, but it's typically not required if the app changes the files, and easier to decide at upgrade time (by changing dates) instead of committing to NeverOverwrite when it's sometimes unclear what the product may need in the future.
A comment refers to retrieving the previous version of the product during the upgrade. There are a number of ways to do this:
If you know the ProductCode of the previous version, MsiGetProductInfo (and equivalents in script etc) will return product version values or strings:
https://msdn.microsoft.com/en-us/library/aa370130(v=vs.85).aspx
Or if you'd rather not hardcode the value, MsiEnumProducts passing the UpgradeCode will return a list of installed ProductCodes. This technique is most useful if you have your own bootstrapper or UI where you want to show the user the current installed version.
In a WiX major upgrade the associated property (WIX_UPGRADE_DETECTED) is a list of the ProductCodes detected (usually a list of one) so you can use that to get the version of the product being upgraded. In a small vbscript example, something like:
set installer = CreateObject("WindowsInstaller.Installer")
and:
prodversionstring = installer.productinfo(WIX_UPGRADE_DETECTED, "VersionString")
will get you close.
Assuming this file is a configuration file such as an XML file, I find this is just a tough area of Windows Installer. You ship file version 1, the end user modifies certain attributes and then you ship file version 2 to which you want to preserve those customizations.
The problem is this is a very complex merge. It works somewhat OK if you only care about 1-2 attributes but if the answer is I need to preserve all of it then you are stuck between losing all the customizations or not getting the changes from version 2 of the file.
You could write extensive custom actions to do all this during the installer but I propose there is a better way: Have 2 files.
1 file that is owned by the installer and can always be safely overwritten and 1 file that is owned by the application that overrides are stored in. Think of it like a transformation file. The installer doesn't know about this file so it never overwrites or deletes it. (The very definition of user data from an MSI perspective.)
For example the .NET framework Web.Config schema AppSettings element has a file attribute that was designed to support this nicely.
Specifies a relative path to an external file containing custom
application configuration settings. The specified file contains the
same kind of settings that are specified in the , , and
elements and uses the same key/value pair format as those
elements. The path specified is relative to the main configuration
file. For a Windows Forms application, this would be the binary folder
(such as /bin/debug), not the location of the application
configuration file. For Web Forms applications, the path is relative
to the application root, where the web.config file is located.
Note that the runtime ignores the attribute if the specified file can
not be found.
After (or before) we convert from TFS 2012.2 to TFS 2015.3 (which we have done just fine in a test run) we would like to revert our team project to the standard TFS 2015 Agile process template, and no longer use the customized agile process that we had modified from TFS 2012. We are quite willing to delete all of our work items and start over, but need to keep the team project history and change sets. Anyone know how to do this? Answers to prior questions on this did not address this situation. Thanks.
There is no easy way to do it. Basically the steps require you to use a lot of witadmin commands. Start by deleting any work item types that were added and don't exist in the default template.
Then push the standard work item definition for each work item type.
Then push the categories
Then push the process configuration
Then delete any fields that are no longer used
That should bring you back to the standard template.
An alternative you could try is to use the WitMorph project. You can write a set of rules to migrate your data back into working order.
I have a WIX Installer and in the installer i also copy a tutorial project created in VS 2012. What i want is if user has changed the tutorial project by adding new files in it then i just want to rename the existing tutorial and and copy the new tutorail and if user has not changed the existing tutorial then i just want to replace the existing tutorial with the new tutorial.
Is the first question is, Is it really possible using WIX? (Does WIx gives us some functionality like that)
if its possible can some will guide me how to do that?
It should be possible using the MoveFile element but it's going to be really tricky. I worked for a company that created a .NET SDK and we build custom project types for VS that allowed the user to say File | New | SomeTypeOfApp and then use that for training. We also kept our "tutorial" apps in ZIP files and an application that acted as a front end asking the developer where they would like to extract the sample app to. This greatly simplified the installer requirements.
I have made a ContentType in Visual Studio 2010 for my SharePoint 2010 project and the first time I deployed the wsp through the WSPBuilder there were no troubles but now every time I try to deploy, it keeps saying that it can't activate features because "The field with ID {insert random guid here} defined in feature {60938308-3563-497c-bc55-b2ae847ca8b8} (the feature activating my contenttype on the site) was found in a current site collection or in a subsite."
The contenttype and site columns gets created on the rootweb and even though I try to either deactivate the feature or completely uninstall it, the site columns and contenttype won't be deleted from the ContentType gallery or Site Columns gallery.
How can this be?
I use pure feature and XML functionality. No eventreceivers are involved.
SharePoint will not let you delete site columns and content types that are in use. This makes the upgrade process a little tricky.
If you just want to add a field to your content type you can use the Feature upgrade facilities in SharePoint 2010. This blog post series should help you: http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html
If you need to make any other changes (remove field, change type, etc) then you need to take a different approach. You'll create a new content type that inherits from, and eventually replaces, your existing content type. This strategy is discussed here: http://msdn.microsoft.com/en-us/library/aa543504.aspx
Besides checking out what Rob suggests:
Did you install Visual Studio SP1?
I received that error before installing SP1 and the workaround was closing all Visual Studio instances and starting it up again. After starting up deployment was possible again.