What is repository.config in modules/_protected?

Vote:
 

This morning I received a TFS merge conflict showing that my local repository.config had a different Guid ID than in the checked-in server version. I had never noticed this file before and I don't know what it is or anything about the modules folder. I noticed that someone had just recently added it to TFS, but we have been running the project for months now without it being in TFS. This led me to find this page: http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-CMS/8/add-ons/Installing-add-ons/, which states, "Important! Because each server's repository.config file has a unique GUID, do not commit the file to source."

Well now I fear I'm in trouble because I now have the checked in version of this file and lost my original Guid. What is this file used for, where does it come from, and how do I get my own Guid back if I remove the file from TFS?

#141361
Nov 12, 2015 23:34
Vote:
 

As far as I remember respository.config file should play its role when installing AddOns via AdminUI. Are you adding AddOns from VS or allowing editors/admins to add them from AdminUI?

#141423
Nov 14, 2015 5:21
Vote:
 

Not that I know of but someone else may have added something. How can I check? There are no Add-Ons listed in the EPiServer admin UI.

#142108
Nov 30, 2015 23:09
Vote:
 

The file is automatically generated for you if it does not exist. It is used to track add-on installation and uninstalls, as each add-on can register code to run in these circumstances. Since the code might add, change or clean up stuff on the server, it needs to be run on all servers in a load balanced environment. This is why the guid needs to be unique per server, and you shouldn't check it in.

Now, if you have checked it in, but you're not using any add-ons, this should be no problem. Nothing will break. Keep calm :-)

If you've got a load balanced setup, or a separate editing environment, the best practice is to keep a copy of the generated repository.config per server, and deploy it together with the site. If you're using Octopus Deploy, this can be automated using a post deploy script to copy the config file from somewhere else on the server after the new version has been copied to disk.

/Steve

#142168
Dec 03, 2015 11:12