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.
Project names appear as file names. Why couldn't a project be called "Algorithmic proof that A^n + B^n = C^n is false for any n greater than 2"? Or "Overloads of ="?
"Overloads of >" would not be valid file/project name, but "Overloads of =" is. So the project file format should handle it. I am happy to see "qouting free" file names - I really hate the umpteen different ways of quoting, character escapes and the like - but that usually takes binary formats to handle. When old traditions and legacy pressures you to remain with the age old "ASCII philosophy", then you must provide the proper quoting and character escaping, no matter how ugly it looks.
At least modern .sln files use UTF-8 encoding, capable of representing arbitrary printable text without resorting to neither backslash escapes with octal codes, backslash with hex codes, backslash with code letters and special chars like \\, HTML character entities, Quoted Printable, base64 or possibly old style UUE, atob/btoa, StuffIt or whatever format you prefer for packing non-ASCII characters into an ASCII representation. I'm happy to avoid that, but why don't we go the full length, and go for binary TLV formats, to avoid all of these problems?
That's a fairly standard format for property files, and has been since the early days of Windows. Unfortunately when they moved to the modern file systems and allowed (more or less) any character in a filename, there were unforeseen consequences.
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.
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.
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?