The Lazy Developer's Guide to Command Line Building with C#(mianlabs.com)
mianlabs.com
The Lazy Developer's Guide to Command Line Building with C#
https://mianlabs.com/2017/01/02/the-lazy-developers-guide-to-command-line-building-with-c/
25 comments
Is there an FOSS alternative to LinqPad with any of the same features? I'd prefer to support open source but if non-free software's much better I'll probably just go with that.
Well, scriptcs sounds somewhat analogous. Similar REPL for C#, allows for packaged scripts, plays nicer with the filesystem than an IDE (which you'd expect for command-line apps). http://scriptcs.net/
Note: I've tried to use scriptcs, but the extent of my C# knowledge consists of pretending it's Java. But people do seem to compare it to LINQPad, so maybe it fits.
Note: I've tried to use scriptcs, but the extent of my C# knowledge consists of pretending it's Java. But people do seem to compare it to LINQPad, so maybe it fits.
Linqpad's amazing "dump" isn't to be found in scriptcs or anywhere else, so far as I'm aware, however. Which really does make working with a C# REPL a million times nicer.
LinqPad is so worth the relatively paltry sum it costs to get a license for the full version.
"dotnet new -t web" is my favorite lazy command I didn't see mentioned in the article (I think you need to install the cli .net core thing).
I find it really strange that there is no longer a stand alone compiler with dotnetcore. There is also an alarmingly low number of .net devs that even know that csc exists, which is a shame because it gives you a lot more flexibility when building your projects and is a lot faster than msbuild.
Having been taught programming at university with command line tools (Ocaml, then C with GGC on Linux) I've naturally gone the same way when self-learning C# on Windows: notepad + Powershell + csc.exe I found somewhere within .net framework installation folders. I sticked with it for simple programs and started using Visual Studio 2008 only when learning GUI programming.
So I always find strange all the C# tutorials and books starting straight out with Visual Studio: this software is often updated with major visual changes thus rendering screenshots obsolete and there is a lot of visual complexity involved especially for beginners in both C# and programming. On the other hand the CLI interface is pretty stable, simple to use for small programs with few references -- and it's actually force one to understand what a referenced dll is -- and involve less magic.
So I always find strange all the C# tutorials and books starting straight out with Visual Studio: this software is often updated with major visual changes thus rendering screenshots obsolete and there is a lot of visual complexity involved especially for beginners in both C# and programming. On the other hand the CLI interface is pretty stable, simple to use for small programs with few references -- and it's actually force one to understand what a referenced dll is -- and involve less magic.
I did the same thing with Java, for the longest time. Makefiles invoking javac, almost the same as I did for my C/C++ programs. It does start to break down once you start to get into more heavy-weight programs. I wouldn't even want to see what a hand-made makefile for one of my C# solutions that has a couple dozen projects and a few hundred code files would look like...
When I did a bit of programming in Java, I was using Intellij. I found that starting with the IDE made learning the fundamentals harder. I later switched to Sublime and a command prompt, and found the process of pushing through command line errors to be more instructive.
Merging csproj files in source control is also a pain. I think they tried to get rid of sln and csproj files but got vetoed by the community.
A while ago I wrote a batch script that assembled a project with csc instead of using Visual Studio. This was so easy and refreshing to work with. Source control worked, build times were incredibly fast and the result was independent of Visual Studio settings.
I really want my good old makefiles back for C#. For build management Visual Studio adds a lot of complexity and weird behaviors.
I really want my good old makefiles back for C#. For build management Visual Studio adds a lot of complexity and weird behaviors.
I wrote a couple of months ago about using make with .net (the focus is on make):
http://flukus.github.io/2016/11/30/2016_11_30_Rediscovering-...
The problem is that I still need VS for debugging, which means build via msbuild. I've heard .net comes with a cmd line debugger (that's compatible with gdb even), though I've never used it.
http://flukus.github.io/2016/11/30/2016_11_30_Rediscovering-...
The problem is that I still need VS for debugging, which means build via msbuild. I've heard .net comes with a cmd line debugger (that's compatible with gdb even), though I've never used it.
Does Visual Studio not come with nmake anymore? While I prefer BSD make, nmake wasn't half bad. Had all the essentials and then some.
Those are msbuild settings, not visual studio settings.
My point was that, in a team, the output of the build depends on Visual Studio settings of each developer.
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=ReleaseThis article seems to be assuming no use of Visual Studio. Are there useful command line utilities for _editing_ solution files?
Text editors?
Project("{F184B08F-C81C-45F6-A57F-5ABD9991F28F}") = "Project1",
"Project1.vbproj", "{8CDD8387-B905-44A8-B5D5-07BB50E05BEA}"
EndProject
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
Whoa, 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
[2]: http://fsharp.github.io/FAKE/
[3]: 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...
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
[2]: http://fsharp.github.io/FAKE/
[3]: 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...
Sorry 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
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
> 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.
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.
Or use LinqPad. I am confused. I'd never recommend use another tool.
[1] - http://www.linqpad.net