Extending Visual Studio, do you prefer VSIX extensions or scriptable/batchable CIL tools?
-
I'm just curious because I feel like I'm in the minority where I really don't care for using extensions where a CIL tool will do. I find them more flexible. They don't require an "installation" into visual studio. You don't have to worry that they won't work from inside a build script. Like for example, I was just thinking about creating a tool that will package your current solution for distribution on the codeproject. My two options are to: 1. write it as a VSIX visual studio extension/add in that will provide a button or menu option to package the solution for code project. It would work using the Project/ProjectItem stuff in EnvDTE. You use it (in theory) by right clicking on the solution and clicking "package for codeproject" 2. write it as a command like tool that simply parses the project files out of the csproj xml files and by reading the directory tree. You use it by making it a post build step on one of your solution projects. I lean toward the latter. I think a lot of people would prefer to use the former. What do you prefer?
Real programmers use butterflies
_definitely_ as a stand-alone tool, command-line or otherwise. Extensions for IDEs are great, but mean that you're requiring that people use that IDE. I can quite happily write C#/.NET with VIM on a Linux machine -- why would I need to use VS? As a bonus, if you find that this kind of thing _would_ be great from your favorite IDE, the extension becomes as simple as a button which invokes your CLI app. /2c
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
-
_definitely_ as a stand-alone tool, command-line or otherwise. Extensions for IDEs are great, but mean that you're requiring that people use that IDE. I can quite happily write C#/.NET with VIM on a Linux machine -- why would I need to use VS? As a bonus, if you find that this kind of thing _would_ be great from your favorite IDE, the extension becomes as simple as a button which invokes your CLI app. /2c
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
(and if someone else decides it would be nice as a VSCode / Rider / Sublime / DeadBadger plugin, they can do the same wrapping, so everyone wins)
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
-
_definitely_ as a stand-alone tool, command-line or otherwise. Extensions for IDEs are great, but mean that you're requiring that people use that IDE. I can quite happily write C#/.NET with VIM on a Linux machine -- why would I need to use VS? As a bonus, if you find that this kind of thing _would_ be great from your favorite IDE, the extension becomes as simple as a button which invokes your CLI app. /2c
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
Yeah that's my view as well. CLI is ultimately much more flexible.
Real programmers use butterflies
-
(and if someone else decides it would be nice as a VSCode / Rider / Sublime / DeadBadger plugin, they can do the same wrapping, so everyone wins)
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
Now I really want an IDE named DeadBadger. :-D
Real programmers use butterflies
-
I'm just curious because I feel like I'm in the minority where I really don't care for using extensions where a CIL tool will do. I find them more flexible. They don't require an "installation" into visual studio. You don't have to worry that they won't work from inside a build script. Like for example, I was just thinking about creating a tool that will package your current solution for distribution on the codeproject. My two options are to: 1. write it as a VSIX visual studio extension/add in that will provide a button or menu option to package the solution for code project. It would work using the Project/ProjectItem stuff in EnvDTE. You use it (in theory) by right clicking on the solution and clicking "package for codeproject" 2. write it as a command like tool that simply parses the project files out of the csproj xml files and by reading the directory tree. You use it by making it a post build step on one of your solution projects. I lean toward the latter. I think a lot of people would prefer to use the former. What do you prefer?
Real programmers use butterflies
I really do not get the trend of those who want to revert to command line tools like we had 40 years ago, instead of more productive UI tools. I'll choose a VSIX add-in anytime over some caveman-level command line tool.
-
I'm just curious because I feel like I'm in the minority where I really don't care for using extensions where a CIL tool will do. I find them more flexible. They don't require an "installation" into visual studio. You don't have to worry that they won't work from inside a build script. Like for example, I was just thinking about creating a tool that will package your current solution for distribution on the codeproject. My two options are to: 1. write it as a VSIX visual studio extension/add in that will provide a button or menu option to package the solution for code project. It would work using the Project/ProjectItem stuff in EnvDTE. You use it (in theory) by right clicking on the solution and clicking "package for codeproject" 2. write it as a command like tool that simply parses the project files out of the csproj xml files and by reading the directory tree. You use it by making it a post build step on one of your solution projects. I lean toward the latter. I think a lot of people would prefer to use the former. What do you prefer?
Real programmers use butterflies
50/50 for me. I do a LOT of automation using JenkinsCI, so for that I like to add things to my dotnet command line, or even just write a plain old separate CLI tool. When I'm actively developing however, I do like the convenience of having everything right there in VS19 ready to just click on, I very often don't have a CLI open when I'm working in VS.
-
50/50 for me. I do a LOT of automation using JenkinsCI, so for that I like to add things to my dotnet command line, or even just write a plain old separate CLI tool. When I'm actively developing however, I do like the convenience of having everything right there in VS19 ready to just click on, I very often don't have a CLI open when I'm working in VS.
I hear you. Most of my CLI tools are pre or post build steps anyway so they're already automatically executed in visual studio. However, some aren't and I like to provide both options. In fact, I just wrote this: CPPkg: Create Zips of Your Source Code From Visual Studio[^] It has both a CLI tool and a Visual Studio add in. It creates a zip of your source code so unlike most of my tools it is not really appropriate for use as a post build step although it's a quick and dirty way to automate the zip creation (installing it as a build step that is). Normally you have to click a menu. *gasp*
Real programmers use butterflies
-
I hear you. Most of my CLI tools are pre or post build steps anyway so they're already automatically executed in visual studio. However, some aren't and I like to provide both options. In fact, I just wrote this: CPPkg: Create Zips of Your Source Code From Visual Studio[^] It has both a CLI tool and a Visual Studio add in. It creates a zip of your source code so unlike most of my tools it is not really appropriate for use as a post build step although it's a quick and dirty way to automate the zip creation (installing it as a build step that is). Normally you have to click a menu. *gasp*
Real programmers use butterflies
Nice. Might have to have a look at that, I can actually think of a use for it on my current project. Another thing I'm fond of is "Git Hooks", not the GitHub kind but the old proper original way of doing them. If you use NuGet packs like LibGit2Sharp, you can actually run dotnet CLI tools direct from a git-hook, and access just about anything you need or want to know about the repo in question. I've used them for processing everything from project code, through to book and blogpost manuscripts :-)
-
Nice. Might have to have a look at that, I can actually think of a use for it on my current project. Another thing I'm fond of is "Git Hooks", not the GitHub kind but the old proper original way of doing them. If you use NuGet packs like LibGit2Sharp, you can actually run dotnet CLI tools direct from a git-hook, and access just about anything you need or want to know about the repo in question. I've used them for processing everything from project code, through to book and blogpost manuscripts :-)
I'll check it out. The tool I wrote above is primarily for submitting code to code project easier, or at least that's why I wrote it. It's by no means limited to that, of course. :)
Real programmers use butterflies
-
I'm just curious because I feel like I'm in the minority where I really don't care for using extensions where a CIL tool will do. I find them more flexible. They don't require an "installation" into visual studio. You don't have to worry that they won't work from inside a build script. Like for example, I was just thinking about creating a tool that will package your current solution for distribution on the codeproject. My two options are to: 1. write it as a VSIX visual studio extension/add in that will provide a button or menu option to package the solution for code project. It would work using the Project/ProjectItem stuff in EnvDTE. You use it (in theory) by right clicking on the solution and clicking "package for codeproject" 2. write it as a command like tool that simply parses the project files out of the csproj xml files and by reading the directory tree. You use it by making it a post build step on one of your solution projects. I lean toward the latter. I think a lot of people would prefer to use the former. What do you prefer?
Real programmers use butterflies
VSIX are a pain to maintain (enable install for Community/Professional, 2017/2019), CLI is much simpler. I have been using nuget for packaging but it's changed and now is a pain to deliver tooling by. Admittedly if I merged all my .NET binaries into one it would probably work. Rather than complain and do an uninstall I tell the user to download from the website and unzip the file.