TFS/ MSBuild Add ChangeSet Number to Web.Config - msbuild

Does anyone know of a good solution for adding the changeset number of a build (in TFS 2012) to the web.config of a web site being built?
We don't want it as part of the assembly version, but as a completely separate entry.
Thanks,
Kieron

You will have to add a Custom Workflow Activity to the build process template to do this.
Ewald Hofman has a great blog series on how to do this. Part 5 has a tutorial on editing the Assembly Version, you can use this as a template but instead edit your web.config.
You should find the Changeset Id in: the BuildDetail.SourceGetVersion property.
N.B. as this is TFS 2012, you will probably have Local Workspaces on by default, so you don't need to fiddle the Read Only flags on files.

Related

Update and retain web.config file during upgrade in wix installer

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.

How to permanently save a build variable as a build step?

I have the following variables defined:
Now once a build is complete (the last step in the build process), I want to update the VersionRevision variable, basically increment it.
So I'm looking for an API I can call from C# and create a console application or a powershell script to edit the build definition (if I have to do this)?
You can use VSTS Rest API to update the variable value in Build Definition. Both Console Application and Powershell Script is OK for this.
If I understand correctly, you want to get these build variables and them assignment them as your version number.
After the build completes, update and increment the VersionRevision. It's not a good way and seems not available to achieve it.
In TFS build there is a $(Rev:.r) which means
Use $(Rev:.rr) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
Source: Specify general build definition settings
To version your assemblies you could just add an powershell script in your build definition, detail ways to achieve please follow this link from MSDN: Version your assemblies
And usually we only define and assignment variables with the Major and Minor version. If you want to change the value of them. You may need manually edit the build definition.
More related link about how to manage version numbers as part of your vNext builds.
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext

TFS 2015 won't upload custom process template

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();

Renaming the existing files during MSI installation WIX

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.

WIX Installer for Test/Live Environment

I have to create a set up file for a client app for LIVE/QA/UAT environments and the only difference between them is the app.config file. Can you please suggest an easy way to accomplish it?
A good approach is modifying a template app.config based on user input:
configure your app.config file to use installer properties: http://wix.sourceforge.net/manual-wix2/wix_xsd_xmlfile.htm
create some custom dialogs which retrieve the element information from the user and save them in your custom properties
If you need to update just certain value in app.config based on user input, then the solution outlined by #Cosmin would work best. There are a couple of other options depending on your requirements:
in case you can define the app.config differences at buildtime, and if it's fine to have 3 different MSI packages (one per environment), it's better to author 3 components holding the app.config for each environment wrapped in the preprocessor logic. As a result, you'll end up with an MSI package for a specific environment depending on how you build
in case the choice depends on a certain user input, you can still author 3 different components with mutual exclusive conditions, and this conditions will depend on the user input
I've solved this before by using something along the lines of this in my main wxs file:
<?include $(sys.CURRENTDIR)Properties$(var.Configuration).wxi?>
(It points to e.g. C:\MyProjectDir\PropertiesDebug.wxi, C:\MyProjectDir\PropertiesUAT.wxi, etc. depending on the active solution configuration).
However, I now prefer using the new Microsoft method of having the web.config and app.config transforms for each platform, because it can help to shift the burden of maintaining these settings onto the developers who create them as they go, rather than just leaving it all to the guy that writes the installer app at the end.
The app.config transforms are not built into VS2010, but there is an add-in available:
http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5
The web.config transforms are built in already:
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx