6 ms·

The Lazy Developer's Guide to Command Line Building with C#

28 points by JeremyMorgan 10y ago

flukus 10y ago
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.
- maxxxxx 10y ago
  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.
  - flukus 10y ago
    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-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.
  - digitalpacman 10y ago
    Those are msbuild settings, not visual studio settings.
    - maxxxxx 10y ago
      My point was that, in a team, the output of the build depends on Visual Studio settings of each developer.
  - digitalpacman 10y ago
    Those are msbuild settings, not visual studio settings.
  - groovy2shoes 10y ago
    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.
- titanix2 10y ago
  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.
  - amorphid 10y ago
    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.
  - jamra 10y ago
    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.
  - douche 10y ago
    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...
divbit 10y ago
"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).
kalyanganjam 10y ago
I use LinqPad[1] as my C#/F# scratchpad. Works wonderfully well and I can't imagine living without the magic ".Dump()" feature. [1] - http://www.linqpad.net http://www.linqpad.net
- kupiakos 10y ago
  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.
  - Solarsail 10y ago
    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/ 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.
    - shakna 10y ago
      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.
- douche 10y ago
  LinqPad is so worth the relatively paltry sum it costs to get a license for the full version.
digitalpacman 10y ago
Or use LinqPad. I am confused. I'd never recommend use another tool.
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 ago
  This article seems to be assuming no use of Visual Studio. Are there useful command line utilities for _editing_ solution files?
  - groovy2shoes 10y ago
    Text editors?
    - shakna 10y ago
      Project("{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 ago
        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 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...

28 points by JeremyMorgan 10y ago

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.

maxxxxx 10y ago
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.
- flukus 10y ago
  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-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.
- digitalpacman 10y ago
  Those are msbuild settings, not visual studio settings.
  - maxxxxx 10y ago
    My point was that, in a team, the output of the build depends on Visual Studio settings of each developer.
- digitalpacman 10y ago
  Those are msbuild settings, not visual studio settings.
- groovy2shoes 10y ago
  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.
titanix2 10y ago
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.
- amorphid 10y ago
  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.
- jamra 10y ago
  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.
- douche 10y ago
  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...

divbit 10y ago

"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).

kalyanganjam 10y ago

I use LinqPad[1] as my C#/F# scratchpad. Works wonderfully well and I can't imagine living without the magic ".Dump()" feature. [1] - http://www.linqpad.net http://www.linqpad.net

kupiakos 10y ago
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.
- Solarsail 10y ago
  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/ 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.
  - shakna 10y ago
    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.
douche 10y ago
LinqPad is so worth the relatively paltry sum it costs to get a license for the full version.

digitalpacman 10y ago

Or use LinqPad. I am confused. I'd never recommend use another tool.

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 ago
This article seems to be assuming no use of Visual Studio. Are there useful command line utilities for _editing_ solution files?
- groovy2shoes 10y ago
  Text editors?
  - shakna 10y ago
    Project("{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 ago
      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 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...