The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
I bolded the bit that's the problem. Spot it yet?
There are no quotes, and = is a valid filename character.
The upshot is this. If you add a file to your "Solution Folders" (a feature that has always been kludgy) and then rename it to include an = then the file will not get saved as part of the solution, meaning it won't be listed under solution folders next time you load.
I only discovered this because I needed to write a tool that could read the solution folder items from a solution file.
Probably someone that got moved from the Windows Update department?
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
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?
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.
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...
So obviously - and as always - it depends...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
I consider command line tools to be a close relative of assembly programming.
Some people really take pleasure of demonstrating that they know by heart every single command line option / flag for two dozen different command line tools (the description of all the options for gcc comes in three hardcover volumes...).
Sorry, that is not for me. I more and more get a feeling that "fully mastering advanced tools" takes a strong precedence over "mastering the design of a good problem solution for the customer", especially among young programmers. Command line affectionados should by law be forbidden to develop end user applications.
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!
"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.
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.
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
Last Visit: 7-Jul-20 22:49 Last Update: 7-Jul-20 22:49