7 ms·

Ok, it's another release so let me ask this again: can you manage .NET projects without dealing with an IDE like Visual Studio or MonoDevelop or whatever? And f

Ok, it's another release so let me ask this again: can you manage .NET projects without dealing with an IDE like Visual Studio or MonoDevelop or whatever? And for whatever solution you recommend, do people actually use it in the wild or is it just a technical preview thing? I'm really looking for something like `cargo build` or `go build`, but it looks like .NET just loves their IDEs and XML based configuration files.

steverb 10y ago
I know with previous versions of .NET you could, using MSBUILD. That's how we actually built things on the CI server. There were .csproj files and other XML files to deal with, but you can edit those by hand if you feel the need to. I wouldn't want to have to do things that way though.
sakopov 10y ago
Our CI build server has been building .NET 4.5, 4.6 and .NET CORE components via msbuild.
Locke1689 10y ago
It's still in preview, but you can build .NET Core apps with the .NET CLI tool: https://www.microsoft.com/net/core#windowscmd https://www.microsoft.com/net/core#windowscmd
michaeldwan 10y ago
Right on the dotnet core getting started page: https://www.microsoft.com/net/core#linuxredhat https://www.microsoft.com/net/core#linuxredhat dotnet build dotnet run dotnet test updated: formatting
- tree_of_item 10y ago
  Thanks, I don't understand why people were recommending csc.exe and msbuild if this was a thing...
  - ungzd 10y ago
    Microsoft is deprecating project.json and recommending to move back to msbuild xml files: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t... Or maybe they deprecated this deprecation later? It's all very confusing.
    - Locke1689 10y ago
      It is quite confusing (sorry) but the format of the project files won't change the command line interaction -- you'll still do dotnet build dotnet run
      - ungzd 10y ago
        Installed .NET core 1.1.0 and it still looks for project.json (and not uses msbuild files). $ dotnet build Couldn't find 'project.json' in current directory $ xbuild XBuild Engine Version 14.0 Mono, Version 4.6.1.0 Copyright (C) 2005-2013 Various Mono authors Build started 17.11.2016 18:08:11. ... Build succeeded. Also it creates project.json when creating new project.
        enricosada 10y ago
        .net core 1.1 is the runtime (coreclr + bcl) the .net core sdk (tooling, the cli command line) is 1.0.0-preview2 and use `project.json` your xbuild is from mono installed on your system, not .net core if you download and use the .net core sdk `1.0.0-preview3` you will see the msbuild based csproj in preview3 (run `dotnet new`). msbuild based mean `dotnet build` is calling the msbuild library with `/t:Build` argument. To explicity run msbuild, you can do `dotnet msbuild`
mikestew 10y ago
It's really hard to not be snarky when you could build .NET applications before there even was a Visual Studio that supported .NET. I mean, how hard have you looked? My first C# program was written using Notepad or whatever Windows text editor I had lying around and the C# command-line compiler. I wrote it sixteen years ago when C# was still in alpha. IIRC, something like csc foo.cs. So, yeah, you can create .NET applications without an IDE, and you've been able to for a long time. Was there something specific you wanted to know? EDIT: in giving the benefit of the doubt, I considered that maybe things had changed since I last written anything for .NET. Maybe the obvious search doesn't return anything. So I tried .NET command line build. I got a full page of what looked to be useful results, including the top result: https://msdn.microsoft.com/en-us/library/78f4aasd.aspx https://msdn.microsoft.com/en-us/library/78f4aasd.aspx. Now I wish I hadn't wasted the keystrokes on a rhetorical question that I surmise was asked just to be snarky.
- tree_of_item 10y ago
  I guess the downvoters think I'm being snarky, but this was an honest question. I use Go and Rust mainly and balked every time I looked at C# because of the emphasis on IDEs. Your link is a great example of what I don't want, though, and this is what I was afraid of. Compare the experience of using `csc.exe` with `cargo`, for example. I mean, obviously there is some executable that does the work of building your programs, but you wouldn't suggest someone use `gcc` to manage C projects, would you?
  - mikestew 10y ago
    I guess the downvoters think I'm being snarky, but this was an honest question. Okay, well, glad I didn't down vote the comment, then. Compare the experience of using `csc.exe` with `cargo`, for example. But, to my knowledge, Rust doesn't have an IDE (forgive me if my ignorance of Rust is showing), so if Cargo did not exist it would be necessary to invent it. C# has an IDE, it could be argued that something like Cargo is not required. I posit that your problem is solved, just not in the manner you would like. but you wouldn't suggest someone use `gcc` to manage C projects, would you? No, I'd suggest that they use the IDE. But I've done it, because I'm not shipping bits to customers that were built by a developer hitting the F5 key and pulling the output from their local drive.
ungzd 10y ago
I used xbuild, but from Mono, not .NET Core (maybe .NET Core has it too). It builds standard Visual Studio 'msbuild' files (.sln, .csproj, .fsproj). It works okay and these XML files are editable by hand but still somewhat creepy. I tried only F# so I used .fsproj build files and was able to do everything even without Visual Studio Code (in Emacs). There's also tools called Paket and Fake which look like .NET counterparts of Ruby's Bundler and Rake, created by F# community. Paket patches .fsproj/.csproj files and it looks like hack but still better than putting absolute paths to preinstalled dependencies. For creating new projects from template, Yeoman (installable from npm) is quite popular. Build process in .NET looks like is in transitional state from Visual Studio-first to build tools-first and is still painful and confusing. I didn't try project.json / dotnet tooling yet, because F# website doesn't mention it. I tried only F# and Monogame.
- enricosada 10y ago
  for f# on .net core (preview2), see https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-preview2 https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... you'll see the experience about cli and sdk. All docs about .net core sdk works. - `dotnet new -l fsharp` - `dotnet run` or - `dotnet new -l fsharp -t lib` - `dotnet build` - `dotnet pack` for nuget packages Ide works in vs code works with Ionide plugin, if you open it after first `dotnet build`
- enricosada 10y ago
  Good blog post as intro "F# Suave app on dotnet core on Kubernetes on Google Cloud" That's f# and .NET Core console app (who host suave web), published in a docker container and run on k8 on google cloud http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kubernetes-on-google-cloud/ http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kube...

steverb 10y ago

I know with previous versions of .NET you could, using MSBUILD. That's how we actually built things on the CI server. There were .csproj files and other XML files to deal with, but you can edit those by hand if you feel the need to. I wouldn't want to have to do things that way though.

sakopov 10y ago

Our CI build server has been building .NET 4.5, 4.6 and .NET CORE components via msbuild.

Locke1689 10y ago

It's still in preview, but you can build .NET Core apps with the .NET CLI tool: https://www.microsoft.com/net/core#windowscmd https://www.microsoft.com/net/core#windowscmd

michaeldwan 10y ago

Right on the dotnet core getting started page: https://www.microsoft.com/net/core#linuxredhat https://www.microsoft.com/net/core#linuxredhat dotnet build dotnet run dotnet test updated: formatting

tree_of_item 10y ago
Thanks, I don't understand why people were recommending csc.exe and msbuild if this was a thing...
- ungzd 10y ago
  Microsoft is deprecating project.json and recommending to move back to msbuild xml files: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t... Or maybe they deprecated this deprecation later? It's all very confusing.
  - Locke1689 10y ago
    It is quite confusing (sorry) but the format of the project files won't change the command line interaction -- you'll still do dotnet build dotnet run
    - ungzd 10y ago
      Installed .NET core 1.1.0 and it still looks for project.json (and not uses msbuild files). $ dotnet build Couldn't find 'project.json' in current directory $ xbuild XBuild Engine Version 14.0 Mono, Version 4.6.1.0 Copyright (C) 2005-2013 Various Mono authors Build started 17.11.2016 18:08:11. ... Build succeeded. Also it creates project.json when creating new project.
      - enricosada 10y ago
        .net core 1.1 is the runtime (coreclr + bcl) the .net core sdk (tooling, the cli command line) is 1.0.0-preview2 and use `project.json` your xbuild is from mono installed on your system, not .net core if you download and use the .net core sdk `1.0.0-preview3` you will see the msbuild based csproj in preview3 (run `dotnet new`). msbuild based mean `dotnet build` is calling the msbuild library with `/t:Build` argument. To explicity run msbuild, you can do `dotnet msbuild`

mikestew 10y ago

It's really hard to not be snarky when you could build .NET applications before there even was a Visual Studio that supported .NET. I mean, how hard have you looked? My first C# program was written using Notepad or whatever Windows text editor I had lying around and the C# command-line compiler. I wrote it sixteen years ago when C# was still in alpha. IIRC, something like csc foo.cs. So, yeah, you can create .NET applications without an IDE, and you've been able to for a long time. Was there something specific you wanted to know? EDIT: in giving the benefit of the doubt, I considered that maybe things had changed since I last written anything for .NET. Maybe the obvious search doesn't return anything. So I tried .NET command line build. I got a full page of what looked to be useful results, including the top result: https://msdn.microsoft.com/en-us/library/78f4aasd.aspx https://msdn.microsoft.com/en-us/library/78f4aasd.aspx. Now I wish I hadn't wasted the keystrokes on a rhetorical question that I surmise was asked just to be snarky.

tree_of_item 10y ago
I guess the downvoters think I'm being snarky, but this was an honest question. I use Go and Rust mainly and balked every time I looked at C# because of the emphasis on IDEs. Your link is a great example of what I don't want, though, and this is what I was afraid of. Compare the experience of using `csc.exe` with `cargo`, for example. I mean, obviously there is some executable that does the work of building your programs, but you wouldn't suggest someone use `gcc` to manage C projects, would you?
- mikestew 10y ago
  I guess the downvoters think I'm being snarky, but this was an honest question. Okay, well, glad I didn't down vote the comment, then. Compare the experience of using `csc.exe` with `cargo`, for example. But, to my knowledge, Rust doesn't have an IDE (forgive me if my ignorance of Rust is showing), so if Cargo did not exist it would be necessary to invent it. C# has an IDE, it could be argued that something like Cargo is not required. I posit that your problem is solved, just not in the manner you would like. but you wouldn't suggest someone use `gcc` to manage C projects, would you? No, I'd suggest that they use the IDE. But I've done it, because I'm not shipping bits to customers that were built by a developer hitting the F5 key and pulling the output from their local drive.

ungzd 10y ago

I used xbuild, but from Mono, not .NET Core (maybe .NET Core has it too). It builds standard Visual Studio 'msbuild' files (.sln, .csproj, .fsproj). It works okay and these XML files are editable by hand but still somewhat creepy. I tried only F# so I used .fsproj build files and was able to do everything even without Visual Studio Code (in Emacs). There's also tools called Paket and Fake which look like .NET counterparts of Ruby's Bundler and Rake, created by F# community. Paket patches .fsproj/.csproj files and it looks like hack but still better than putting absolute paths to preinstalled dependencies. For creating new projects from template, Yeoman (installable from npm) is quite popular. Build process in .NET looks like is in transitional state from Visual Studio-first to build tools-first and is still painful and confusing. I didn't try project.json / dotnet tooling yet, because F# website doesn't mention it. I tried only F# and Monogame.

enricosada 10y ago
for f# on .net core (preview2), see https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-preview2 https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... you'll see the experience about cli and sdk. All docs about .net core sdk works. - `dotnet new -l fsharp` - `dotnet run` or - `dotnet new -l fsharp -t lib` - `dotnet build` - `dotnet pack` for nuget packages Ide works in vs code works with Ionide plugin, if you open it after first `dotnet build`
enricosada 10y ago
Good blog post as intro "F# Suave app on dotnet core on Kubernetes on Google Cloud" That's f# and .NET Core console app (who host suave web), published in a docker container and run on k8 on google cloud http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kubernetes-on-google-cloud/ http://blog.2mas.xyz/fsharp-suave-app-on-dotnet-core-on-kube...