Replacing c# compiler with new Roslyn build

Question

I'm playing around with some changes to Roslyn, but unfortunately, even the unmodified solution would crash when I run VisualStudioSetup.Next, with an error trying to load an MS assembly. So I made some simple changes and replaced my machine's existing binaries and config files with the new build. Changes were made in C:/Program Files (x86)/MSBuild/bin and Windows/Microsoft.NET/Framework64.

Replacing CSC, VBCSCompiler, the DLLs, and config files causes csc.exe to throw an error on any build. It complains that the manifest specifies a different version of the CodeAnalysis.CSharp DLL. It doesn't give a path for the file or even the name. I've replaced both configs and DLLs that are found in the above-mentioned folders with the new builds. What files do I need to actually replace for it to work correctly?

I did a search of the entire drive for all instances of CSC and made sure all of the configs specify the new version of the DLL, so I'm not sure where to look now.

I know it is possible to pass a parameter to MSBuild or add a section to the csproj file to specify a directory for the compiler binaries, but I'd like to get a victory over this thing.

EDIT: So I decided to just change the version number for my builds. Doing it through the assembly properties in VS causes the build to fail. I tried to use MSBuild, but it fails in every single project with this error:

"F:\Git\Repos\roslyn\src\Compilers\CSharp\csc\csc.csproj" (default target) (1) ->

F:\Git\Repos\roslyn\build\Targets\Versions.props(42,5): 

error MSB4184: The expression ""1".Substring(3)" cannot be evaluated. 

startIndex cannot be larger than length of string. 

Parameter name: startIndex F:\Git\Repos\roslyn\src\Compilers\CSharp\csc\csc.csproj]

It builds fine from VS though.

MSBuild params: /p:OfficialBuild=true /p:BuildNumber=1.3.1.60616 /p:Configuration=Release

Chemisette

What you're doing sounds a bit dirty. – Refusal

@MathiasLykkegaardLorenzen Sure. My team likes to pull some pranks and make them difficult to reverse. That's why I'm not keen on just modifying the build params to use a new compiler. – Chemisette

What you try to achieve sounds very interesting, But please let us know what your goal is. Are you trying to replace csc.exe of your Visual Studio installation ? So that when you compile in Visual Studio the updated csc,exe is used ? – Fanechka

@AedvaldTseh My goal is to replace the csc and VBCSCompiler executables used by MSBuild on a TFS Build Agent. So any time a build is transferred to an agent and it calls MSBuild, my compiler should be used. – Chemisette

Please confirm: github.com/dotnet/roslyn compiles fine in Visual Studio, but it fails if you try to build it on your TFS build machine. But if you try to build it on your developer machine from the commandline ? Which version of MS Build do you use on your build machine ? – Fanechka

@AedvaldTseh All ~150 projects in the solution build successfully from VS. They fail when I run MSBuild from the same dev machine. I'm using MSBuild version 14. – Chemisette

Have you considered using msbuild properties CscToolPath and CscToolExe. See msdn.microsoft.com/en-us/library/bb629394.aspx – Fanechka

Have you considered using nuget.org/packages/Microsoft.Net.Compilers for this job? – Allegiance

Answer 1

To replace compiler in experimental instance of Visual Studio 2017 currently min. required version is v15.3 or later. And it is necessary to install Roslyn.Compilers.Extension.vsix and not VisualStudioSetup.Next.

Exact information from documentation of DotNet Roslyn github repo is as follows:

CompilerExtension: this project can be found inside the Compilers folder from the Solution Explorer, and builds Roslyn.Compilers.Extension.vsix. This deploys a copy of the command line compilers that are used to do actual builds in the IDE. It only affects builds triggered from the Visual Studio experimental instance it's installed into, so it won't affect your regular builds. Note that if you install just this, the IDE won't know about any language features included in your build. If you're regularly working on new language features, you may wish to consider building both the CompilerExtension and VisualStudioSetup projects to ensure the real build and live analysis are synchronized.

Description of VisualStudioSetup.Next clearly states it's limitations and expected usage, which is fixing IDE bugs:

VisualStudioSetup.Next: this project can be found inside the VisualStudio folder from the Solution Explorer, and builds Roslyn.VisualStudio.Setup.vsix. In theory, it contains code to light up features for the next version of VS (Dev16), but currently hasn't been updated for that since Dev15/VS2017 shipped. If you're working on fixing an IDE bug, this is the project you want to use.

If the plan is to replace Roslyn compiler in default instance of the Visual Studio 2017 than do the following:

1. Close all instances of Visual Studio 2017.
2. Double click on Roslyn.Compilers.Extension.vsix package and after elevating install extension. This time it should be available in default instance.

The above steps can be applied to Visual Studio Build Tools as well.

Beware - if you build and use not released code expect it to be buggy even during installation step.

Musky