|
Yes but that "standard" was created long before the days of XML, and used by other manufacturers. And, to be fair to Microsoft, they have used XML in many other places, including Visual Studio project files.
|
|
|
|
|
This is in devstudio 2019.
I know that people probably "shouldn't" use equals in their filenames, but they *can*.
Meanwhile, devstudio silently fails when it happens.
There's really no excuse. Not even for an ancient file format being used as a primary file format for devstudio files.
Real programmers use butterflies
|
|
|
|
|
Not heard of devstudio, is that a Microsoft product?
|
|
|
|
|
devenv is the executable name for Visual studio and devstudio has been a nickname for visual studio since at least as far back as visual studio 6.0
Real programmers use butterflies
|
|
|
|
|
I worked on 6.0 but don't remember what it was called. But then at my age I don't remember what i had for dinner last night.
|
|
|
|
|
well, i like the name because it's shorter than Visual Studio, and "VStudio" is dumb.
Real programmers use butterflies
|
|
|
|
|
I see the basic problem as caused by a "command line philosopy". There is a strong correlation between textual command line input and textual configuration files as input to a program system.
Configuration (and similar) info should be stored in some "binary" format. If you don't want to use a fullblown database, at least the configuration file should be built from Tag-Length-Value records, with an unrestricted Value field.
If, say, MS had promoted a basic TLV structure common to all system needing configuration info, a general reader/editor for this forma could be written, by MS or by anyone else. Such an editor could of course provide various export formats for use in Linux and other legacy systems, adding quoting as required by that format. But the authoritative file should be in the TLV format with no values - file names or others - being restricted by configuration file formats.
|
|
|
|
|
My only problem with a binary format is I've never found an IDE I can trust entirely with my source. If it corrupts it, I'm hosed.
Real programmers use butterflies
|
|
|
|
|
Have you tried creating a file named CON, with any extension, on Windows?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
|
Daniel Pfeffer wrote: and how many stowaways?
Careful ... Mars will start building a wall, and getting us to pay for it ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
MAGA - Make Ares Green Again?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's actually brown, extremely sweet and sticky: Milky Way, as seen from Mars[^]. I would not like it very much if it turned green.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
At a time when governments are urging us to use car sharing to "save the planet", perhaps a bit of rocket sharing might be in order...
|
|
|
|
|
|
Well ... it'll only be seen by people who might want to use it ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
God Is an Iron
"If a person who indulges in gluttony is a glutton, and a person who commits a felony is a felon, then God is an iron." — Spider Robinson
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
I've seen that ad on YouTube for quite a while now, probably the last year or so.
|
|
|
|
|
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 - 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
|
|
|
|
|
Yup!
Get me coffee and no one gets hurt!
|
|
|
|
|
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...
"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.
|
|
|
|
|
To be fair these tools target developers, not end users.
Real programmers use butterflies
|
|
|
|