Replies: 3 comments 10 replies
-
|
Personally, I LOVE, LOVE, LOVE what you're proposing! Partly because I think far too many COM-based implementation details have leaked into the toolkit's API itself. The whole idea initially was to have a simpler & more discoverable API than all of the existing complicated COM-based code. The API should help new extension writers to write extensions, but not preclude more advanced or custom scenarios. I was a huge supporter of the toolkit in the early days but I'd hoped that it would remain implementation-agnostic. I expected that the API would be hashed out first, then implementation(s) could follow. Unfortunately it didn't stay that way for very long. There have been a number of very clever code contributors, but I became somewhat disillusioned with some of the directions it was taking. At the same time I also suffered from debilitating chronic health problems. Problems which are unfortunately on-going. I'm already doing something similar to what you suggest (but on a much smaller scale) with my own wrapper classes around the parts of the toolkit itself. Sometimes I just want namespace/class/method names to be more logical, or consistent. I want the code that I write using the toolkit to read well, & not be unnecessarily complicated. I want my method names to tell me what it's doing, not how it's doing it! Other times I need to add functionality that's missing but may not necessarily be a good candidate for adding to the toolkit itself. Most importantly I like code to be consistent. The toolkit should definitely adhere to SOLID principles, but it has strayed from implementing them. A well thought out, user-friendly, extensible API, along with methodology that you're proposing, would enable all of what I've mentioned & more. I especially like how you suggest using dependency injection. Nobody should even need to know how the API is implemented, whether it is based the VS SDK, or not. Sometimes it might be, other times it might not. It should be also able to be extended when required, on a user by user basis, without having to fiddle around with pull requests and then have to wait for it to be accepted and then released. When I need new code, I need it NOW, not multiple days or more later. That's how I ended up doing similar to what you're suggesting on a much small scale, just for what I needed at the time. Don't get me wrong, there have been some amazing technical code contributions; code that I just couldn't have written myself because I'm not a systems engineer. I write business code around a code library (it used to be my own code, now I use the toolkit where I can). The toolkit took what I was already doing on a small scale in my code to the next level. It has, & still does, have a lot of potential. What you're suggesting would take the toolkit itself to the next level, in terms of consistency, simplicity, extensibility, & testability. If nobody else sees the benefit to what you're suggesting, I'd certainly like to be involved in what you create. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @yannduran, Thank you for your enthusiastic response! I'm glad you liked my proposal. My main goal behind the abstraction was to better organize extensions in projects, have the ability to flexibly extend the existing concept (as you also mentioned), and be able to write unit tests. I will incorporate your thoughts into my approach to the best of my knowledge. Of course, you are welcome to contribute to the project. However, I haven't started yet as I wanted to wait for feedback first. What do you think? PS: |
Beta Was this translation helpful? Give feedback.
-
|
If it were me, I don't think I'd use a fork of the existing toolbox. I'd create a new project, add the interface abstractions for the desired API (method by method, see below), then look at the implementations. Even better would be to use TDD to create the API & unit tests together. That way the API grows organically & always has a unit test for each method. |
Beta Was this translation helpful? Give feedback.
-
The idea behind the fork was to allow me to work freely without having to create pull requests. Of course, it will need to be merged afterwards.
I'm not a big fan of TDD, as I believe it involves a lot of work without significant benefits that couldn't be achieved more easily. What do you think about exchanging roles in this project? You take the lead in implementing the idea, and I'll participate where I can. From what I've seen in my initial steps, this kind of abstraction is quite a challenging project that I cannot tackle alone, especially without someone who is well acquainted with the project and if we aim to maintain a broader range of functionalities. Alternatively, we can wait until someone else who knows the project better joins in. |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to have a video chat (or even audio if video is undesirable to you)? It'd be great to be able to share screens too. It's not that I want to hide what we might discuss from anyone, in fact it'd be a good thing to come back here & summarise what's been discussed to get opinions/suggestions from other people too. I'd just like to make sure we're basically on the same page, & that'd be much easier for me to do in a conversation than constant writing back & forth. Personally I'm far more interested in the shape of the API than how it's implemented. To give a very basic example, there are currently a number of methods in the toolkit that I really wish returned information about whether the method was successful or not - even just a Note that I've differentiated between an error & an exception. For me an error is expected (a business logic error, or parameter not correctly specified, or some other kind of soft error), whereas an exception is not expected (this is usually handled by thrown an exception & leaving the calling code to deal with it - the toolkit could soften the burden of having to write so many try/catches everywhere). In the simplest cases, the code wrappers that I've written around such methods can _only_ return
What I like about TDD is the inversion of write some code then write a test (if that ever actually gets done) to write a failing test (because no code has been written yet) then write some code to make the test pass (using the simplest code to make the test pass). Writing the test first forces you to think about how it'll be used, not how it's going to be implemented. It also encourages better naming of methods & classes, because you get to see them being used in the tests. It takes more up front thinking, but saves a lot of hassles later. The tests also usually tend to get named in such a way that it becomes a sort of auto-documentation of the API. |
Beta Was this translation helpful? Give feedback.
-
|
I have responded to that in the other thread. I believe we share the same opinion on certain aspects. The public interface is the core and needs to be well-designed, while the implementation details can and should be subject to change. I also like using Try methods that return a boolean value, but I would always provide both options: a Try method and a method that throws an exception in case of failure. Additionally, it could be expanded with suitable logging based on Microsoft.Extensions.Logging.Abstractions. Regarding TDD: |
Beta Was this translation helpful? Give feedback.
-
|
Can you guys explain to me in simple terms what would be the benefit when using this approach? What I personally like about the current approach is that the toolkit also includes (most of) the VS SDK packages, so my list of dependencies is relatively short. If the toolkit "surface" would be VS version independent, then I would have to add packages myself whenever I want to do something that is not handled by the toolkit. |
Beta Was this translation helpful? Give feedback.
-
|
I do not want to abolish packages 14-17; they are fine as they are and should remain as they are. My proposal is "only" an abstraction that will be implemented by all four packages as a common denominator. The problem I have with the current approach is that I am "stuck" using Shared Projects, and I cannot use regular projects. This is an issue for me because I find the new SDK project files to be well-designed, and I prefer using multiple modular and organized projects. Although it is possible to achieve this with multiple Shared Projects, I often encounter minor errors that can be quite disturbing. My second issue is that I greatly value the use of Dependency Injection, both as a concept for architecture and to enable unit testing. However, currently, everything with this toolkit is happening statically (the VS class), which makes unit testing without a dedicated facade impossible. Therefore, my proposal is to develop an abstraction that will be implemented by all four packages. Additionally, a factory (or an AsyncPackage base class) can be created to provide an instance for the correct version and register it in the DI container. As a developer, you can continue to use the versions separately as before, but you also have the option to develop projects that work with the abstraction. The choice of the specific implementation will be determined during package initialization. |
Beta Was this translation helpful? Give feedback.
-
That's a good question Robert. It's quite possible that @loop8ack & I are not in fact thinking of the same thing at all (that's why I've asked for a video call to determine if we're on the same page).
After reading @loop8ack's reply above, I think that what he has in mind is actually an internal reorganisation of the existing toolkit's code where users of the current toolkit would carry on as they are now, and wouldn't need to be aware of the changes unless they wanted to take advantage of the ability to extend it with new functionality via dependency injection. I'm not sure exactly how that would work. I realise now that what I had in mind was more of a Toolkit 2.0 kind of thing, where a lot of the existing code might well be able to be re-used, but it would involve breaking changes because the public API would change, hence the semantic versioning of
If you're content with an all-in approach, as we have now, then I can see how the possibility changing that could be potentially disruptive for you. If the 2.0 approach can be put together how I envisage it in my head, then it might be able to be more of a take only what you need approach. I'd like to see the toolkit more in line with other community toolkits are organised (Windows Community Toolkit, .NET Community Toolkit, which includes things like the MVVM toolkit etc). But it's a bit up-in-the air right now until @loop8ack & I sort out the direction he wants to take and/or if the two ideas are totally incompatible with each other or not. |
Beta Was this translation helpful? Give feedback.
-
|
If you guys have decided on a moment for your video call, I might want to join (if possible, I am on CEST (GMT+2).) |
Beta Was this translation helpful? Give feedback.
-
|
No time has been decided yet. I'm AEST (GMT +10). |
Beta Was this translation helpful? Give feedback.
-
|
I think you summarized it quite well, @yannduran. Ideally, I don't want to make any changes to the toolkit, as it is already widely used, and I understand from my own experience how challenging extensive changes can be. Therefore, my proposal should lean more towards an extension without altering the existing toolkit too much. However, I also share your opinion (as far as I can see) on how the toolkit should be modified. But that would make it very difficult for existing users and may result in many users not updating. I want to avoid that. Alternatively, we could completely redesign it under a different name and offer a compatibility version under the current name to warn existing users. I agree that an all-in-one solution is likely not feasible, as the SDK itself is not suitable for that. Regarding the phone call: I'm open to having a call, although my spoken English is not very fluent, so it would be a challenge for me. Additionally, I will be starting with a new employer in a few days and will have less time during the week. I'm also in CEST (GMT+2), specifically in Germany. |
Beta Was this translation helpful? Give feedback.
-
|
Someone else that I hope might like to participate here would be @reduckted (Dave), who has contributed the greater part of the code for the current toolkit, including the very creative was of including the correct SDK classes etc. Very clever man! |
Beta Was this translation helpful? Give feedback.
-
Hello all,
This entire project already serves as an extensive abstraction over the Visual Studio SDK. Might we consider taking it one step further to its logical conclusion?
Here's the proposal:
We could create a new project providing a comprehensive abstraction over all classes, enums, etc. used in the toolkit, accessible without the need for the original SDK installation. We have four versions of the toolkit, each implementing these abstractions, with the VS class available in both static and instance implementations.
At another location, all we would need to do is extract the Visual Studio version, enabling instantiation of the correct VS instance implementation, potentially via Dependency Injection.
We could also contemplate the introduction of another base package class, capable of identifying the version and setting up accordingly.
An alternative approach could be:
Creating another project that encompasses both abstraction and wrapper classes, each selecting the appropriate version. Although I must admit, I find the initial proposal more appealing :)
So, the objective is that I can create a regular .NET 4.6/4.7/4.8 or .NET Standard 2.0 project, install the abstraction package, and work with it as usual. As long as I only need the features provided by the toolkit, there is no need to develop against a specific Visual Studio version. The specific Visual Studio version being used would then only be determined at the package initialization stage, from which the toolkit version would be identified.
Indeed, it would not only simplify the process for extensions that aim to support multiple Visual Studio versions, but also unlock more possibilities for development and implementation.
I'm also prepared to take on the task of implementing this, but I'm interested in hearing your opinions before moving forward.
So - what are your thoughts on this?
Beta Was this translation helpful? Give feedback.
All reactions