
The Lazy Developer's Guide to Command Line Building with C# - JeremyMorgan
https://mianlabs.com/2017/01/02/the-lazy-developers-guide-to-command-line-building-with-c/
======
kalyanganjam
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
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
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
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.

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

------
flukus
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
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.

~~~
digitalpacman
Those are msbuild settings, not visual studio settings.

~~~
maxxxxx
My point was that, in a team, the output of the build depends on Visual Studio
settings of each developer.

------
xpaulbettsx
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
This article seems to be assuming no use of Visual Studio. Are there useful
command line utilities for _editing_ solution files?

~~~
groovy2shoes
Text editors?

~~~
shakna

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

~~~
shakna
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](https://msdn.microsoft.com/en-
us/library/5dy88c2e.aspx)

~~~
groovy2shoes
> _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.

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

