How could Visual Studio 2012 be set to use a custom tool to customise the Reading/writing of existing editors?

Question

---

Update: It appears that VS doesn't have the hooks needed to do what is needed in my use case. However there are a couple of options that could work for other people and as such I'm marking the question as answered but I would love to find a solution that works for me.

---

We have encrypted files that are routinely kept in encrypted form within source control (TFS). When I want to compare versions I use Beyond Compare and have added the encryption/decryption tool as filtering on the read/write process to allow plain text viewing and editing.

However if I just want to open the file for reading/editing it's a bit tedious using a dummy comparison just to view/edit the file.

As such as I wondering if there is a configuration setting or way in Visual Studio that would allow me to insert a filter on the read/write so that it could display/edit/save files that would otherwise be unreadable.

Edit: *NB: The encryption aspect is just single use case *, I'm actually looking for a generic answer that doesn't require writing an editor to replace the editors within VS that already exist such as the MS supplied XML editor or the custom third party ones.

I have both custom and non custom files that are encrypted. Each file type already has an editor. We have no access to the source for any of these editors. The problem is that the file is encrypted in TFS, and all I need is the filtering on the read and write for all files regardless of editor.

I want to use all the existing features of the installed editors without change. Only the reading and writing need to be customised.

Answer 1

Here's a potentially hacky way to achieve what you are trying to do, if there is no other easy option.

TFS stores data in a SQL database. Therefore you can theoretically modify the read/edit command that is used to extract the data from TFS and send it to the editor/viewer. This might involve modifying a stored procedure, or putting a trigger in place to modify the data before it is presented to the editor.

You would need to run a Profiler Trace on the TFS database when you click on edit/view or browse to the node in the source control tree. This will help you to figure out what data TFS is accessing and what functions/stored procs/tables etc it used to extract said data.

The same in reverse; you'd need to modify the 'writing' of the data to use your custom tool before putting it in the DB.

SQL has the ability to call CLR code, so you could use your tool if it's written in .NET.