Part 2 : Decide Approach
In previous post I pointed out where I would be focussing on to achieve a better DX with VSX integration package:
- Refactoring MPF in context of usability
- Writing a new integration package project
Now, after some considerations made, I’ve decided to change my approach. What I realy want to achieve is to be able to present tools to fasten up the development and lower the threshold. Herefore I only need a integration package for the VSX integration package to automate common tasks.
Refactoring the MPF is a good plan, but actually, the only thing that should be refactored is the top-layer, the way MPF organizes itself. I’ve looked into refactoring it and notice that it tantamounts to change the way it registers components (commands, toolwindows, services). Also, the core of all is enclosed in one file, namely the Package class.
Refactoring would take a massive part of my time, so I looked around to see if someone else would have made the effort. I found a need project, http://vsxtra.codeplex.com/. This project does all the refactoring. I considered to use it as a base to create my own integration package. I will not use it because of an extra dependency into my package.
It is still my intention to write a new integration package project. I can start with an Integration package to later migrate to a seperate project template.
So to conclude: I will focus on wrap the most of the MPF with a thin layer to automate small pieces of functionality. This way of working allows me to gradually increase the scope and leverage very fast small pieces of automated task without impacting existing VSX packages.
I also named the project VSXL. So from now on I’ll will use this to address the Visual Studio Integration Package Integration Package.
Recent Comments