Visual Studio Add-in suckage - part deux

As you can see, I have managed to slap together some rudimentary integration of JIRA with Visual Studio. You can log in to JIRA, download saved filters, run them and display filtered issues. Adding other functionality exposed by JIRA SOAP and RSS interfaces should not be a problem.

But there is another problem: integration as it looks right now is pretty useless. And it seems that due to Visual Studio's automation interfaces being somewhat limited in functionality there is not much I can do about it.

See, the whole point of integrating JIRA (or whatever other external tool) with IDE is automation of workflow. For JIRA, that would be mostly task flow automation. You would want to:

1. select a task from some list of tasks
2. work on it for some time, potentially finishing the task
3. commit files you have modified during your work
   
4. report time spent on a task (if you are one of these old-school project management enthusiast and don't believe in agile ways, for which individual effort tracking is sort of pointless)

We already support this in our IDEA plugin, mostly by means of:

• standard and very potent VCS interface
• built-in support for change sets (sets of files modified after being checked out of the repository), into which we could plug in

We are still far away from the completeness and automation of Mylyn's task support, but even today you can:

1. list issues based on some filter
2. assign an issue to yourself
   
3. create a change set based on an issue key and make it active
4. modify a bunch of files, which will land in this change set
5. commit the whole change set in one go, automagically using the issue key as a part of commit message, so that information about committed files lands in JIRA

Now, with Visual Studio, the last three steps seem to be absolutely impossible to implement using its extensibility interface. The crucial window - Solution Explorer, does not expose any automation interfaces, and does not support filtered views. The only way to "filter" files is to exclude them from the project. Which is an absolutely dumb thing to do, because then they will not be a part of the build! Moreover, Visual Studio's VCS interface (MSSCCI) is not used by two of the most popular Windows Subversion clients - TortoiseSVN and AnkhSVN! I could theoretically (although it would be as pleasant as pulling teeth) use a command line SVN client. But without some way to show sets of modified files (like in IDEA's changesets), I don't think I can do anything.

It would really really (and I do mean realy) suck if I had to create my own source file tree views, detect file modifications (especially because of non-standard SVN client APIs) and synchronize these views with main "solution explorer" view somehow.

On the positive side, C# continues to be quite decent. Also, the whole System library has been quite nice to use so far. My only nitpick is that I would make public member variables first-class properties. It is dumb to have to write a getter and setter for a read/write int-type property (not that Java is any better in this respect mind you).

Oh, by the way, you can grab sources of the visual studio plugin here