Reputation: 705
Hopefully someone can elucidate where I went wrong here.
We have a number of shared assemblies built with VS 2015 that were already making use of certain C# 6 linguistic features (string interpolation, null conditional operators, etc). We didn't need to add the Roslyn Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider nuget reference to those projects; Visual Studio/msbuild just handled that for us.
Recently I was working on an ASP.Net website project, which we ship pre-compiled and we build with msbuild. I had to update the target framework on that solution so that we could use those shared assemblies - but I still couldn't use the C# 6 language features in the code behinds.
I found posts about how the compilers were no longer part of the main .net, and were not in the gac anymore, and that to use them with asp.net website solutions and code behinds, you had to a) change web.config to reference the newer compilers and b) add nuget references to those compilers to the solution.
My reasoning was thus: the other shared assemblies didn't have to add the Roslyn compilers as nuget packages to use those features, and we were pre-compiling the whole solution for the build product and didn't ship any compile-on-the-fly code behinds so we didn't want/need the Roslyn compiler assemblies to be in the build product (we didn't have to for our other WebApi and other application builds; msbuild/VS 2015 just took care of that - besides string interpolations and null conditional operators are syntactic sugar that don't seem to have extra runtime requirements).
So I tried just updating the web.config section to reference the Roslyn compilers instead. On my dev machine, I hit Build in VS and it worked fine. I ran msbuild on my system locally and it worked fine.
But that was only because Visual Studio implicitly added the Roslyn compilers as a nuget reference. They show up in the packages directory and in the output bin directory.
On the build server, just running msbuild, it fails because the Roslyn compilers weren't fetched and put in the packages folder.
Is there any way for a pre-compiled website solution to use the C# 6.0 linguistic sugar without pulling Roslyn in as a nuget package, the way other shared assemblies can?
Thanks
Upvotes: 1
Views: 482
Reputation: 705
Turned out there didn't seem to be any elegant ways to achieve this. Nuget was particularly flaky with web site solutions, too, so the only way to plow ahead that direction was to add a whole bunch of work-arounds to the makefile.
I opted instead to move pretty much everything under App_Code into a separate assembly and pick up the compilation for free.
Upvotes: 1