3 ms·
Uhhhh I don't use _any_ of those commands. ### Build this project msbuild ./path/to/some/Solution.sln ### Build this project for release m
by xpaulbettsx 10y ago
Uhhhh I don't use _any_ of those commands.
### Build this project
msbuild ./path/to/some/Solution.sln
### Build this project for release
msbuild ./path/to/some/Solution.sln /p:Configuration=Release
- kupiakos 10y agoThis article seems to be assuming no use of Visual Studio. Are there useful command line utilities for _editing_ solution files?
- groovy2shoes 10y agoText editors?
- shakna 10y agoProject("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1", "Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}" EndProject Just a small part of a solution file, and not exactly the easiest thing to write by hand. Where do the hashes come from, what do they represent, and what kind are they? Take a look at the example file here: [0], almost half of it is hashes... But are they necessary? Or automatable easily? Is it well documented? Does it break between VS versions? I know VS has "updated" my solution file between versions, and isn't always backwards compatible. That story might have changed. But... Solution files seem to be machine readable, not human. It just seems like a bad idea to do it yourself. [0] https://msdn.microsoft.com/en-us/library/bb165951.aspx https://msdn.microsoft.com/en-us/library/bb165951.aspx
- groovy2shoes 10y agoWhoa, the GP asked what to use to edit the files, not what to use to write them from scratch :p Yeah, they're plain text, but they're pretty nasty, for sure. I'm not a Windows developer anymore (haven't been for over a decade now), but my understanding is that if you're going to be doing a whole project from the command line, you're going to want to use MSBuild[1], FAKE[2], or perhaps nmake[3] (which is old-skool and not particularly compatible with the usual %nix makes, but will at least be familiar for many developers coming from %nix). Of course, there's no (technical) reason you couldn't use some other generic build tool with the Visual Studio command line tools, but other Windows developers will likely not be prepared to deal with them. [1]: https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx [2]: http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/ [3]: https://msdn.microsoft.com/en-us/library/dd9y37ha.aspx https://msdn.microsoft.com/en-us/library/dd9y37ha.aspx P.S., I don't think those are hashes—just UUIDs. I've edited the solution files by hand before without touching the UUIDs and they continued to work fine. IIRC, the various %.%proj files are also plain text (XML, I think, but I could very well be wrong). Unfortunately, I don't know how to answer your other questions, other than that I think you can usually open solution files for older versions in newer versions, but not vice versa. EDIT: P.P.S. Pretend the various '%' characters are asterisks. Couldn't get them to stop italicizing everything...
- shakna 10y agoSorry to hit you with that one. More a comment on you basically have to deal with Visual Studio if you want a solution file. There have been others in this thread, and on major projects, you work with C# without either. csc, etc. (Which you of course, pointed out). Working with solution files is painful without the IDE they're made by, and fairly undocumented in places where it matters. It worked for editing by hand, this time, but you don't have guarantees for the future. The solution file docs I linked to sort of assume that Visual Studio is the author of the file, to populate it correctly. Just wanted to say that working with Solution files outside of Visual Studio is somewhat unsupported, and could be more difficult than expected. (And you are indeed right that %proj files are indeed XML [0], and incredibly verbose, even for XML.) [0] https://msdn.microsoft.com/en-us/library/5dy88c2e.aspx https://msdn.microsoft.com/en-us/library/5dy88c2e.aspx
- groovy2shoes 10y ago> Sorry to hit you with that one. Don't worry about it. I had it coming ;) Sometimes when I don't have a lot of time to comment, I'll make a shitty (snarky, snide, abrupt, or cetera...) comment, then come back later when I have the time and provide a more detailed comment. It might not be the best thing to do, but anecdotally I get more engagement from others if I do it that way than just waiting to write the longer comment in the first place. I don't expect anybody to know that, though, so I know that I run the risk of coming off as abrasive and I don't expect people to necessarily be super nice about that... > More a comment on you basically have to deal with Visual Studio if you want a solution file. ... Working with solution files is painful without the IDE they're made by, and fairly undocumented in places where it matters. ... Just wanted to say that working with Solution files outside of Visual Studio is somewhat unsupported, and could be more difficult than expected. Agreed on all counts. These things can be pretty frustrating. The saving grace is that the information you'd need to build the project can be identified in the file and extracted for use in some other format. Far from ideal, to be sure, but it means you're not completely out of luck if all you have with the source files is the solution file. The situation could be much better, though. > (And you are indeed right that %proj files are indeed XML [0], and incredibly verbose, even for XML.) I thought so, but it's been a while since I've had to deal with a VS project. And, yeah, Microsoft's record with XML in general has always seemed to be pretty damn verbose to me.