11 of the DLLs in my solution must use PFX certificates (very large enterprise application using Click-Once install). The certificates work perfectly, except every time someone pulls down a TFS branch from a different developer/workstation the certificate password is invalid and they receive:
Error Cannot import the following key file: CertificateName.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_DB583A44F66CCF4B AssemblyName
Forcing them to reenter the same password for all 11 assemblies [image below]. What is a solution/fix for this very time consuming rigmarole?
I do understand that entering the same password from a different workstation uses local values producing technically a different key, but I'm sure I'm not the first person to have this problem.
This was solved by blocking the .pfx files from being checked-in and brought down from TFS. Three potential solutions emerged:
Forbidden Pattern Policy using Server TFS Power Tools.
stackoverflow.com/questions/2741412/forbidden-patterns-check-in-policy-in-tfs-2010
msdn.microsoft.com/en-us/library/gg475890%28v=vs.100%29.aspx
TFS 'Cloaking'
stackoverflow.com/questions/29808807/how-to-cloak-directories-in-tfs-command-line
MSDN - Cloaking in TFS
.tfignore (the chosen solution)
AIS Blog - excluding-files-from-team-foundation-version-control-using-tfignore-files
In the end, .tfignore I found to be the best solution. The .tfignore was automatically generated by Selecting the 'Detected changes link' in the Excluded section of Pending Changes Page, then choosing Ignore by extension (*.pfx) from the PFX file's shortcut menu.
The .tfignore was introduced to the root of the mapped workspace so this rule would be immediately applied to every developer's workspace on next pull from TFS.