Download compiler

[ghost]

I wish to do some basic compiling. I got the latest Framework from here:

https://dotnet.microsoft.com/download/dotnet-framework

installed it and get this result:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319>csc.exe
Microsoft (R) Visual C# Compiler version 4.8.3761.0
for C# 5
Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only
supports language versions up to C# 5, which is no longer the latest version.
For compilers that support newer versions of the C# programming language, see
http://go.microsoft.com/fwlink/?LinkID=533240

So I visit that linked page, which goes here:

https://github.com/dotnet/roslyn

I look here, no download:

https://github.com/dotnet/roslyn/releases

I look here, no download:

https://docs.microsoft.com/dotnet/csharp/roslyn-sdk

I look here:

https://github.com/dotnet/roslyn#download-c-and-visual-basic

and it says to Download Visual Studio. I dont want to do that. So then it says to use Nuget, I dont have Nuget. So then it says to go here:

https://dotnet.myget.org/F/roslyn/api/v3/index.json

but no download links are there. This seems much harder than it should be. Compare with Framework. You go here:

https://dotnet.microsoft.com/download/dotnet-framework

and literally 2 clicks and its downloading.

[jmarolf]

@cup use Microsoft.Net.Compilers.Toolset from nuget. see the documentation here.

The normal experience for this is to download the .NET Core SDK from here which will include both a standalone runtime and the latest compiler. Is there a reason this does not work for you?

[ghost]

Thanks for response. If that is the case, I am not seeing:

https://dotnet.microsoft.com/download/dotnet-core

linked here either.

[jmarolf]

If you click on the recommended link

It will take you to a link to the SDK.

The language on the dot.net site is about "building apps" not "compiling". Was that the source of the confusion?

[huoyaoyuan]

Download compiler

You can never download "compiler" alone. They are always pakced and used with an SDK.

The language on the dot.net site is about "building apps" not "compiling". Was that the source of the confusion?

Modern systems drops "compile" as an user task, but a technical internal stage. You can never download a single "compiler".

This does the job: https://nuget.org/packages/Microsoft.Net.Compilers should be linked somewhere.

No. This is for advanced scenario to consume preview compilers that haven't be packed into any SDK.

In fact, the command csc.exe is available only if you have Visual Studio installed, and the main reason is backward compatibility. To be modern, any "basic compiling" should be done with dotnet build.

[huoyaoyuan]

I assume you are reading some out-of-date books (2017 is out of date!), which lets you compile with command line using csc.exe. That will be only supported when VS installed. Or, read the online tutorial to learn how to build (or compile) an HelloWorld, then follow the book to edit Program.cs.

An alternative is to download Visual Studio Build Tools, instead of the whole VS.

[ghost]

@jmarolf that page you have a picture of is here:

https://dotnet.microsoft.com/download/dotnet-core

the issue is, that page is not linked anywhere in this repository.

You can never download "compiler" alone. They are always pakced and used with an SDK.

@huoyaoyuan um, yeah, no. thats not true. As I downloaded and extracted the package here which contains the compiler:

https://nuget.org/packages/Microsoft.Net.Compilers

In fact, the command csc.exe is available only if you have Visual Studio installed, and the main reason is backward compatibility.

The csc.exe is included with all Windows installations, starting with at least Windows 7. Here is example path:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe

Further, csc.exe is also included with .NET Framework downloads here:

https://dotnet.microsoft.com/download/dotnet-framework

albeit an old version. Finally, csc.exe is available with the Nuget package I linked above. In all 3 cases, csc.exe works as expected, even though I dont have Visual Studio installed. Perhaps you should not spread misinformation.

[huoyaoyuan]

The csc.exe is included with all Windows installations, starting with at least Windows 7. Here is example path:

I'm referring the up-to-date csc.exe. The one in nuget package is up-to-date, but it's not intended to be used. It's just packed as-is with the same packing process of Visual Studio.

[ghost]

The one in nuget package is up-to-date, but it's not intended to be used. It's just packed as-is with the same packing process of Visual Studio.

Again, it seems you are spreading misinformation. I have tested the compiler included in that package, and it compiles basic programs just fine.

So unless you can point to a sourced, valid reason why "it's not intended to be used" or its detrimental to be used on its own, then I will continue to do so. I will also recommend others to do so as well, if they only need basic compiling.

[huoyaoyuan]

So unless you can point to a sourced, valid reason why "it's not intended to be used" or its detrimental to be used on its own

I remember seen discussion somewhere in the dotnet organization saying "don't use it for enforcing your project at a certain compiler version". Tagging official member @sharwell for help.

[sharwell]

Microsoft.Net.Compilers.Toolset will version-lock the compiler, but the compiler is not the only piece of the build. On the command line, the compiler can interact with MSBuild, the SDK, and the dotnet tooling (for .NET Core scenarios). If you lock the versions of any of these, the chosen versions might not be compatible with one or more others, and you end up outside an official supported scenario if anything doesn't work (and these failures might be subtle, like silently failing to produce correct outputs).

Also, if you version-lock any of these, there is no guarantee that IDE features will behave properly with respect to the chosen versions. They might work, but it's a completely untested scenario so you're basically "on your own" if anything goes wrong.

Overall, I'll version-lock the compiler as a temporary workaround for bugs in the version of the compiler currently installed on CI systems, but it's not my preference to do so and I'll remove the lock once the CI systems get updated.

[huoyaoyuan]

On the command line, the compiler can interact with MSBuild, the SDK, and the dotnet tooling (for .NET Core scenarios).

Here seems require a response for "basic compiling", not interacting to anything listed.

His usage is csc a.cs without anything else. And there's not project to install nuget, but download it and unzip, then invoke csc.exe from them.

@sharwell I think the official team should have deprecated direct invocation of csc.exe.

[sharwell]

@dotnet/roslyn-compiler can answer that. Using csc directly always seemed to me like a lot of work for no gain.

[huoyaoyuan]

It literally the least amount of work you could do to compile a file.

To be literally, the current toolchain is never designed for compiling "a file".

Yes, I know the purpose of 1 file because I was an OIer, but the usage scenarios are more limited than several years ago.

To run some simple logic, the simplest way should be csi a.csx. The compilation step is omited. To debug, there must be a project file for support. To create something reuseable, once you are not just doing Readline WriteLine, you can probably benefit from nuget packages and other references. To be OI, you can achieve very little without debugger. And also, any environment that can provide useful completion service will require a project file, to get the context precisely.

[svick]

@cup

I am not going to debate you of the benefits of command line compiling, as they speak for themselves.

Which is why dotnet exists. In almost any situation, dotnet build is going to be a much better choice than csc.

[saucecontrol]

You're comparing a .NET Core app (portable runtime) with a .NET Framework app (system-installed runtime). You can create a 10KiB app with dotnet build as well. Just change the targetFramework in your .csproj file to net48 (or some other .NET Framework TFM)

[ghost]

@saucecontrol I dont have a .csproj file, I just have a .cs file.

[saucecontrol]

All you need is this in your .csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>
</Project>

That tells the compiler what binary type to output and what runtime to target. CSC is not the same as a C compiler. It doesn't make a fully-functioning .exe, it makes a .NET assembly which has to be run on a .NET runtime of some kind. The csproj is the key to controlling your compilation and the runtime references/linkages. Using an old and limited way of interacting with CSC is simply hiding the details that you can make explicit with a project and dotnet build.

[jmarolf]

hey @cup what series of events led you to want to call csc directly instead of using dotnet build? You can obviously do that, and there are a lot of tests that ensure that keeps working but I don't expect that to be the main way people compile C# programs.

the issue is, that page is not linked anywhere in this repository.

Yeah, we should link to it more directly. Right now the only way you are going to get that link is if you look and the building instructions for windows, the building instructions for linux and macOS leave them out. We should update them.

[agocke]

@huoyaoyuan Is correct. The only officially supported mechanisms for accessing the csc.exe binary is to install Visual Studio or the Build Tools MSI.

Every other way of accessing csc.exe: the Microsoft.Net.Compilers toolset package, the Microsoft.Net.Compilers.Toolset package, the dotnet SDK -- these are all unsupported for running csc.exe.

[svick]

@cup

"what is the absolute simplest way to do this?"

To do what? If you're talking about executing a small piece of C# code, then I think there are simpler options:

1. Use Try .NET or SharpLab to run the code.
2. Use LINQPad.
3. dotnet new console, followed by dotnet run. It's two commands, just like csc file.cs and file.exe.

Options 2 and 3 require you to install something, but that's unavoidable if you want to use a reasonably modern compiler.

They dont have to go to any website and figure out how to download and install anything, its already there.

They still have to go to a website to figure out where the compiler is located or the basics of C#. Compared with that, I think installing the .Net Core SDK is a tiny hurdle.

Currently it seems the culture just pushes users to the exact opposite end, not the simplest method but the most complex "Visual Studio". While thats certainly a robust solution, its not and shouldnt be for everyone.

Based on what I've seen, the culture is to push you to use one of two methods:

1. Visual Studio.
2. Visual Studio Code together with dotnet.

If you consider these two main methods, and the alternatives I mentioned previously for running a small piece of code, I think there's no reason to encourage people to use csc, certainly not when learning C#.

[jmarolf]

@jmarolf Jonathon Marolf FTE when I am learning something new, I ask myself "what is the absolute simplest way to do this?". In this case its csc.exe file.cs. Its unfortunate that Microsoft devs have such antipathy towards this method.

All of our docs are very top-down in the way they describe C#. This is because most people are trying to build a working application with C#, not learn the language in a bottom-up approach. I personally also approach things in a bottom up manner and I should make clear using csc is a perfectly valid scenario, just not one we advertise as much.

My only concern is that

1. We are never going to update the compiler that comes with the .NET Framework, so people that call csc from there will get whichever version happens to be on their machine and will run into trouble if they want to try features developed in the last 10 years
2. The response file that is deployed with the compiler (no matter how you get it) is only valid for desktop applications on windows. As soon as you want to build program that runs on linux you either need msbuild to resolve the references for you or pass in /r for all the references manually (meaning a simple csc meow.cs will not work)

All that being said, it sounds like downloading Microsoft.Net.Compilers.Toolset, unzipping it, and running it, is exactly what you want. This is something that is supported just not advertised because it is hard to build a multi-dll application with just csc and so most users will need to learn the dotnet cli that somes with the SDK anyways.

[ghost]

@jmarolf what difference between these?

• https://nuget.org/packages/Microsoft.Net.Compilers.Toolset
• https://nuget.org/packages/Microsoft.Net.Compilers

[jmarolf]

The difference is that nuget.org/packages/Microsoft.Net.Compilers is deprecated. nuget.org/packages/Microsoft.Net.Compilers.Toolset is the replacement and supports running in more types of environments

[agocke]

All that being said, it sounds like downloading Microsoft.Net.Compilers.Toolset, unzipping it, and running it, is exactly what you want. This is something that is supported just not advertised because it is hard to build a multi-dll application with just csc and so most users will need to learn the dotnet cli that somes with the SDK anyways.

@jmarolf This is not supported.

[jmarolf]

@agocke This is not supported.

calling csc with the correct commandline arguments is supported. I assume that if this is not supported we wouldn't ship csc in any capacity as it could just be a build task.

[agocke]

@jmarolf Not if you're using csc from the NuGet package. The only supported entry point in the NuGet packages is the build task.

[jmarolf]

Sorry, @agocke is right. The nuget package could have its layout or contents changed at any time so you shouldn't consider it supported in the same way the dotnet cli is. @cup I am still trying to understand what why the dotnet SDK is insufficient for your needs.

[ghost]

@jmarolf its not that its insufficient, it does that job quite fine. Its just that if its 119 MB:

https://dotnet.microsoft.com/download

and this is 18 MB:

https://nuget.org/packages/Microsoft.Net.Compilers.Toolset

Im going to go with the smaller one, if it works for basic compiling. My other reservation as that Roslyn can compile for the .NET Framework, but I realized recently that .NET Core can do that too. But I also realized recently that .NET Core is planned replacement for .NET Framework.

So when that happen I might need to move to .NET Core anyway, as I am not sure what role Roslyn will be able to play at that point, if any.

[jmarolf]

@cup the roslyn compiler already ships with .NET core. The dotnet cli ships with a superset of what csc ships with. The point of the additional 100 MBs that comes with the dotnet cli is to give you a "batteries included" experience so if you want to build any kind of app you don't run into the issue of "oh wait I'll need to find and download those references/targets/SDKs"

[chucklu]

From my experience, I host a wcf as a site, and then I got the error. The web application project is based .net 4.7.2, why I got the exception for C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe version 4.8 . @jmarolf any update? It has been almost 10 months.

c:\windows\system32\inetsrv> "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /t:library /utf8output

Microsoft (R) Visual C# Compiler version 4.8.3752.0

for C# 5 Copyright (C) Microsoft Corporation. All rights reserved.

This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240

[sharwell]

@chucklu The C# compiler is distributed as part of various toolchains. While it is supported (in some scenarios) to directly invoke the compiler, it is not expected. If you are having trouble with a specific scenario, please file a new issue with the full steps to reproduce the problem so we can get it routed to the correct team.

[sharwell]

Closing as answered since this is not directly actionable and any specific answer will not be broadly applicable.

[chucklu]

@sharwell I just find the compilation error occurred under a class file under App_Code folder of a web application project. However I already set the .cs file's build action as compile as mentioned https://stackoverflow.com/questions/18102692/class-file-doesnt-compile-outside-of-app-code-folder Have no idea why this file get compiled at runtime since it already compiled into library(.dll) file.

[chucklu]

Got an explanation here https://stackoverflow.com/questions/7504767/the-type-or-namespace-name-lad-could-not-be-found-are-you-missing-a-using-dir

The App_Code folder is a special folder in ASP.NET. ASP.NET will compile the types App_Code into an assembly which is actually separate from your web application assembly. This means, when you try and use those types from your backend code (e.g. an MVC controller), it is unable to resolve the type because those types will have a Build Action set to Content. With that build action, the file will not be included in the compilation of your main application.

What I would recommend doing, is ditch using App_Code because simply changing the build action to Compile won't stop ASP.NET dynamically compiling an App_Code assembly, so you end up with ambiguous types (i.e., the runtime doesn't know whether to use the type compiled into your main application assembly, or the dynamic App_Code assembly.

Move those files to another location, and set the Build Action (in Properties) to Compile.

[chucklu]

By the way, I just deploy the site under the source code folder for develop environment, which means the site contains .dll and the App_Code/myclass.cs file. Actually when we deploy it, we will not deploy App_Code/myclass.cs, it will be compiled in to dll file.