Extending Visual Studio, do you prefer VSIX extensions or scriptable/batchable CIL tools?
-
To be fair these tools target developers, not end users.
Real programmers use butterflies
Doesn't really matter - the developers are the users of the tools. And a thousand CLI apps with easily forgotten switches is one of the reasons why people abandoned DOS and switched to Windows - including developers! Remember the old days and creating batch files to compile you project(s) because the switches were so "memorable"? I do ... I only create CLI apps now that don't need any inputs even as a one off because it's easier to create, test, debug, and use a GUI app than remember what to type! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
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
honey the codewitch wrote:
What do you prefer?
The correct answer of course is "it depends". :)
- If you expect the tool to be used in CI process, it must be a command-line tool.
- If you want to ensure wide adoption, it should (also) be a VSIX plug-in with an appropriate UI, if applicable.
/ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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
It appears that the opinion is to use Visual Studio extension. I'm mostly a lurker around here so take this with a grain of salt. I've always been partial to the command line. Used to be that if you really wanted to take control of Windows you needed the command line. The GUI never offered the same level of control and some things had to be done via the command line. Linux is command line centered. I've used Visual Studio since around 2003. It always seemed bloated. Don't get me wrong, it is amazing, especially for free, but it still suffers. I have 3 or 4 extensions that I use but I try to steer clear of them normally. In the end I'd use what was easiest to use. I don't have a Mac but I assume that any VSIX will work on both Mac and Windows. Would the VSIX file transfer to VsCode? Command line? Just a thought, you could do both. Probably could share code between the two, but it might take a bit of thought about implementation. Just my 2 cents.
Jack of all trades, master of none, though often times better than master of one.
-
It appears that the opinion is to use Visual Studio extension. I'm mostly a lurker around here so take this with a grain of salt. I've always been partial to the command line. Used to be that if you really wanted to take control of Windows you needed the command line. The GUI never offered the same level of control and some things had to be done via the command line. Linux is command line centered. I've used Visual Studio since around 2003. It always seemed bloated. Don't get me wrong, it is amazing, especially for free, but it still suffers. I have 3 or 4 extensions that I use but I try to steer clear of them normally. In the end I'd use what was easiest to use. I don't have a Mac but I assume that any VSIX will work on both Mac and Windows. Would the VSIX file transfer to VsCode? Command line? Just a thought, you could do both. Probably could share code between the two, but it might take a bit of thought about implementation. Just my 2 cents.
Jack of all trades, master of none, though often times better than master of one.
I could share code between them but that would mean doing away with the only technical advantage of using an extension - a rich project model used for gathering all of the files in the project. With the command line i have to do things by hand - that means parsing the XML for the solution and project files. I already have code to do this because I wrote it for another project[^], but it's probably not as reliable, because the file format could change, or simply I'm not aware of all of the tags that can be in those xml files.
Real programmers use butterflies
-
honey the codewitch wrote:
What do you prefer?
The correct answer of course is "it depends". :)
- If you expect the tool to be used in CI process, it must be a command-line tool.
- If you want to ensure wide adoption, it should (also) be a VSIX plug-in with an appropriate UI, if applicable.
/ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
For this particular project, and for good reason, they can't really share code. The way they work despite doing the same thing, is entirely different under the covers. The reason why is that the VSIX project has access to the EnvDTE project model. The CLI code has to read the solution and project XML files manually. That works (for now) but it's not as reliable. The format could change, and I'm not even sure I know all of the tags that can be present. This means that the preference, from a technical standpoint, is to use the project model EnvDTE exposes that's only available inside a VSIX extension. Sharing code would mean having to use the less preferred method, less reliable method even from inside a visual extension where a better option is available. I hope that makes sense.
Real programmers use butterflies
-
Doesn't really matter - the developers are the users of the tools. And a thousand CLI apps with easily forgotten switches is one of the reasons why people abandoned DOS and switched to Windows - including developers! Remember the old days and creating batch files to compile you project(s) because the switches were so "memorable"? I do ... I only create CLI apps now that don't need any inputs even as a one off because it's easier to create, test, debug, and use a GUI app than remember what to type! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
You make very good points. I've always felt however, that a build should be able to be accomplished from a command line script, for testing, source control/build control, and sometimes even deployment reasons. I do prefer to be able to actually *do* everything from a GUI, but I do use CLI prebuild and postbuild steps, which only need to be typed into a project once, are saved with the project (persistent), and after that they are automatic any time the project or containing solution is built. They also are easier to distribute along with the source for the project itself, because they don't require an install. Basically, if I enter pre/post build steps into the relevant projects, and those get performed by exes that are in the solution folder somewhere then all someone has to do is copy my source tree to be able to build it. Using the VSIX option means they A) Need vstudio to build B) more importantly perhaps, they need to run an install! before they can build I really don't like that. Consequently, in this case I prefer CLI methods.
Real programmers use butterflies
-
honey the codewitch wrote:
What do you prefer?
The correct answer of course is "it depends". :)
- If you expect the tool to be used in CI process, it must be a command-line tool.
- If you want to ensure wide adoption, it should (also) be a VSIX plug-in with an appropriate UI, if applicable.
/ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
If you expect the tool to be used in CI process, it must be a command-line tool.
Sure, that is a heavily promoted myth. I've been through I-don't-know-how-many disussions over the years with people who insist that the driver must be a command line thing, and therefore all the components must be, too. Often, there are specific counter-examples, systems acutally available that are configured through a GUI, the configuration is saved in a database or configuration file, and the GUI may e.g. leave the configuration to a be run by a service at regular intervals - this is quite common for backup systems. One of my earlier employers ran nightly incremental and weekly full backups through a system managed that way. Lots of the developers insisted that the only way to do regular jobs automatically was to write a shell script and supply it to cron. I dragged them one by one over to the GUI based backup configuration and monitoring / management system for the backup: It provided all the facilities they insisted that they needed a command line for, everything managed in a user-friendly GUI and without having to typy all those nasty options on every invocation. "Well, of course you can do it that way, but... Oh well, you can!" Later, I have been using several other example systems. And hyphotetical back-of-envelope sketches when people argue "but no CI systems are like that". Or network management systems. Or systems controlling all sorts of physical equipment. Or whatever. The main reason why we still use the command line is that we haven't sat down to build a proper GUI. We could have done it; we haven't. One example: The Docker engine interface. It could very well have been a GUI where you select objects from lists, delete them with the delete button, create new ones with proper prompts and help information. For a while we were considering making extensive use of Docker (it turned out to be less suitable than we thought), and after failing to find a good ready-made alternative I was seriously considering to write a Docker GUI myself, but the activity cooled down before I got a round tuit. Lots of systems like Docker, or Jenkins / Bamboo, git, ... are activated and controlled through a communications interface. In some systems, the interface is "telnet type". Lots of sytems are e.g. REST based: Command line guys insist on making a shell friendly (but user unfriendly) command interface translating text commands
-
You make very good points. I've always felt however, that a build should be able to be accomplished from a command line script, for testing, source control/build control, and sometimes even deployment reasons. I do prefer to be able to actually *do* everything from a GUI, but I do use CLI prebuild and postbuild steps, which only need to be typed into a project once, are saved with the project (persistent), and after that they are automatic any time the project or containing solution is built. They also are easier to distribute along with the source for the project itself, because they don't require an install. Basically, if I enter pre/post build steps into the relevant projects, and those get performed by exes that are in the solution folder somewhere then all someone has to do is copy my source tree to be able to build it. Using the VSIX option means they A) Need vstudio to build B) more importantly perhaps, they need to run an install! before they can build I really don't like that. Consequently, in this case I prefer CLI methods.
Real programmers use butterflies
honey the codewitch wrote:
I do use CLI prebuild and postbuild steps, which only need to be typed into a project once
In which way is that specific to command line interfaces? The great majority of GUI based systems I use let you configure preferences, options, execution plans and whatever in a useer friendly GUI, saving it in a database (the Registry is one such option, but others may be more suitable) for your next use. Look at VS. You configure prebuild and postbuild steps, and you don't have to retype them every time. Of course you may pull up some GUI that does not do things in a proper way, so you have to respecify things every time. There are bad command line applications out there, too.
-
honey the codewitch wrote:
I do use CLI prebuild and postbuild steps, which only need to be typed into a project once
In which way is that specific to command line interfaces? The great majority of GUI based systems I use let you configure preferences, options, execution plans and whatever in a useer friendly GUI, saving it in a database (the Registry is one such option, but others may be more suitable) for your next use. Look at VS. You configure prebuild and postbuild steps, and you don't have to retype them every time. Of course you may pull up some GUI that does not do things in a proper way, so you have to respecify things every time. There are bad command line applications out there, too.
Member 7989122 wrote:
In which way is that specific to command line interfaces?
I'm not saying that particular aspect is different. My point, and my only point in that is you only need to fiddle with the CLI once if you're using devstudio/VS
Member 7989122 wrote:
Look at VS. You configure prebuild and postbuild steps, and you don't have to retype them every time.
That was my point. It wasn't a complaint about visual studio. The other things I listed in my comment (like avoiding requiring an install in order to build source) are specific to the command line.
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
-
Definitely the second - I often create batch files ( and call them from the post build event ) that copy files to folders and zip them up ready to upload them to Dropbox etc...
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
That's where I'm at as well.
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'd do both. Have a CLI that does the work then run that from your VS extension. That way people can use whatever version they prefer.
-
I'd do both. Have a CLI that does the work then run that from your VS extension. That way people can use whatever version they prefer.
Normally I would, and when I make VS extensions this is typically what I do but there's a better way to gather project and solution files that's more reliable from within visual studio. It looks like I may provide both, but code both methods of gathering files - one for the devstudio extension and one for the CLI. It's not ideal from a maintenance perspective, but it's better in terms of app reliability.
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
honey the codewitch wrote:
What do you prefer?
Having been gifted an iCue keyboard, I assumed it would be easy to change the color depending on the build-result. Not even going to try.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
VSIX - it works me perfectly so never looked for other solutions...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
VSIX - it works me perfectly so never looked for other solutions...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
One issue I've found with VSIX, and YMMV because it really depends on how you use it, but let's say you have some sourcecode that is generated by a tool as part of your build process. With a CLI you can copy the tool into your source directories somewhere, and reference that. That way anyone who copies your sourcetree can rebuild the project (including the the custom build steps that invoke your tool) With a VSIX extension that doesn't work. First, they're huge, so copying it to a sourcetree folder is not necessarily feasible. Second, and perhaps more importantly, they need to be installed. The upshot of that is another developer cannot build your sourcecode without running an installer first. That's why I'm heavily in favor of a CLI for build tasks in visual studio. For other VS productivity tools, that may not be my preference. Just my $0.02
Real programmers use butterflies
-
One issue I've found with VSIX, and YMMV because it really depends on how you use it, but let's say you have some sourcecode that is generated by a tool as part of your build process. With a CLI you can copy the tool into your source directories somewhere, and reference that. That way anyone who copies your sourcetree can rebuild the project (including the the custom build steps that invoke your tool) With a VSIX extension that doesn't work. First, they're huge, so copying it to a sourcetree folder is not necessarily feasible. Second, and perhaps more importantly, they need to be installed. The upshot of that is another developer cannot build your sourcecode without running an installer first. That's why I'm heavily in favor of a CLI for build tasks in visual studio. For other VS productivity tools, that may not be my preference. Just my $0.02
Real programmers use butterflies
I have about 15 different tools as part of my building process - including code generators (called Custom Tools in VS), all implemented as VSIX package... With that said - it is not code to share and those extensions are only part of the build in the development process and not there for the final build, so I'm on the easy side... And yes - I had a case when I had to create a CLI version of the VSIX package to participate in command line build (part of DevOps agent)...
honey the codewitch wrote:
they need to be installed
This is the only problem with them... Size never was a problem... I have one for instance that generates JavaScript code from ASPX page and it is only 140 KB... Or an other that enable you to visually design a Bootstrap grid based HTML page inside VS, and it is less than 700 KB... So obviously - and as always - it depends... :-D
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
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
While I'm not strongly opposed to adding custom build steps just because they are custom build steps, I don't like it. It feels hacky and bad and dangerous and it always goes wrong half a dozen times before the command is right. Also, a build step is really a bare-bones kind of "integration". For example I'm currently running Coco/R that way (because the proper extention hasn't been updated), and it's much more annoying than the extension was: it doesn't run "on save" so the parser code is out of date until I do a rebuild, there is no syntax highlighting, errors appear in some stupid log that I have to go check manually if I suspect there were any (the only indication is that the previous version of the parser keeps being used).
-
While I'm not strongly opposed to adding custom build steps just because they are custom build steps, I don't like it. It feels hacky and bad and dangerous and it always goes wrong half a dozen times before the command is right. Also, a build step is really a bare-bones kind of "integration". For example I'm currently running Coco/R that way (because the proper extention hasn't been updated), and it's much more annoying than the extension was: it doesn't run "on save" so the parser code is out of date until I do a rebuild, there is no syntax highlighting, errors appear in some stupid log that I have to go check manually if I suspect there were any (the only indication is that the previous version of the parser keeps being used).
I haven't had problems with build steps being out of date since they run whenever the project is built. I mean, at worst all it means is if I change a grammar in Parsley (my parser generator similar to Coco/R) i have to rebuild before intellisense will pick up the new constants or methods i added (changing the grammar can change constants and methods available) I had nearly the opposite problem integrating it as a custom tool in VS. But then that extensibility interface has always been kludgy. There are better ways. Syntax highlighting is technically a separate issue. You should be able to install that part without installing the rest of the extension - or maybe I'm wrong? depending on how it's implemented - there's more than one way to skin the highlighting cat in devstudio. The way I'm thinking of works without an extension as well - you just have to create the right files in the right places
Real programmers use butterflies
-
Ravi Bhavnani wrote:
If you expect the tool to be used in CI process, it must be a command-line tool.
Sure, that is a heavily promoted myth. I've been through I-don't-know-how-many disussions over the years with people who insist that the driver must be a command line thing, and therefore all the components must be, too. Often, there are specific counter-examples, systems acutally available that are configured through a GUI, the configuration is saved in a database or configuration file, and the GUI may e.g. leave the configuration to a be run by a service at regular intervals - this is quite common for backup systems. One of my earlier employers ran nightly incremental and weekly full backups through a system managed that way. Lots of the developers insisted that the only way to do regular jobs automatically was to write a shell script and supply it to cron. I dragged them one by one over to the GUI based backup configuration and monitoring / management system for the backup: It provided all the facilities they insisted that they needed a command line for, everything managed in a user-friendly GUI and without having to typy all those nasty options on every invocation. "Well, of course you can do it that way, but... Oh well, you can!" Later, I have been using several other example systems. And hyphotetical back-of-envelope sketches when people argue "but no CI systems are like that". Or network management systems. Or systems controlling all sorts of physical equipment. Or whatever. The main reason why we still use the command line is that we haven't sat down to build a proper GUI. We could have done it; we haven't. One example: The Docker engine interface. It could very well have been a GUI where you select objects from lists, delete them with the delete button, create new ones with proper prompts and help information. For a while we were considering making extensive use of Docker (it turned out to be less suitable than we thought), and after failing to find a good ready-made alternative I was seriously considering to write a Docker GUI myself, but the activity cooled down before I got a round tuit. Lots of systems like Docker, or Jenkins / Bamboo, git, ... are activated and controlled through a communications interface. In some systems, the interface is "telnet type". Lots of sytems are e.g. REST based: Command line guys insist on making a shell friendly (but user unfriendly) command interface translating text commands
I completely agree with you, I hate CLI tools! Where a GUI is intuitive and at least gives you a gist of what a tool can do, a CLI tool does nothing of the sort. You need to read documentation or it's completely unusable. I have lately found one good use for the CLI though. And that's when writing articles. Instead of describing a GUI and saying things like "press the 'x' button in the button-dropdown in the top right of the screen" you can say "use the 'mytool x' command." The GUI might change (in fact some GUI-based stuff I've written became outdated the moment it was published) and adding a dozens screenshots of the GUI also isn't a viable option because you'll be out of pages in a minute. So in those scenario's I'm glad there's a CLI available :D
Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
