Please update to C# 13 or preview (C# 14)

[iJungleboy]

We would really, really like to use the latest C# in DNN.

From our quick tests replacing Microsoft.Net.Compilers.Toolset we believe it should just work.

Could this be prioritized?

[monoblaine]

In my case, editing the Web.config file and adding the following config line into configuration/appSettings node works:

<add key="aspnet:RoslynCompilerLocation" value="<full path to packages folder in the solution>\Microsoft.Net.Compilers.Toolset.5.3.0\tasks\net472"/>

Alternatively, using the global NuGet packages (cache?) folder also works:

<add key="aspnet:RoslynCompilerLocation" value="<full path to userprofile/.nuget folder>\packages\microsoft.net.compilers.toolset\5.3.0\tasks\net472"/>

The second solution requires you to change permissions of the folder <full path to userprofile/.nuget folder>\packages\microsoft.net.compilers.toolset and authorize the IIS_IUSRS group.

You can also edit the csproj file and add the following line into Project/PropertyGroup node in order to prevent the build process copy the roslyn folder into the bin folder:

<RoslynCopyToOutDir>false</RoslynCopyToOutDir>

This step might in fact be required because the tasks defined in Microsoft.CodeDom.Providers.DotNetCompilerPlatform.targets only performs a shallow copy (ignores the l18n folders).

[iJungleboy]

@monoblaine I'm a bit confused about your solution.

If you add the nuget to your project (in this case DNN), and then deploy that project, then adding a web.config would not work since the target system (a normal windows server) would not have a user-profile or nugets.

[monoblaine]

Oh, @iJungleboy I might have incorrectly assumed that you were also just trying to use the latest Microsoft.Net.Compilers.Toolset for Razor views. I'm sorry if that was not the case. But if that's the case, precompiling the Razor views during the publish should just work.

[CZEMacLeod]

I think you can do this a little easier with:

<ItemGroup>
    <PackageReference Include="Microsoft.Net.Compilers.Toolset" PrivateAssets="All" GeneratePathProperty="true" />
    <PackageReference Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" />
</ItemGroup>
<PropertyGroup>
    <RoslynToolPath>$(PkgMicrosoft_Net_Compilers_Toolset)\tasks\net472</RoslynToolPath>
</PropertyGroup>

Note the package references above don't have version numbers (when you use CentralPackageManagement), but otherwise work with

<ItemGroup>
    <PackageReference Include="Microsoft.Net.Compilers.Toolset" PrivateAssets="All" GeneratePathProperty="true" Version="5.3.0" />
    <PackageReference Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" Version="4.1.0" />
</ItemGroup>

The trick is the

<PropertyGroup>
    <RoslynToolPath>$(PkgMicrosoft_Net_Compilers_Toolset)\tasks\net472</RoslynToolPath>
</PropertyGroup>

makes it ignore the built in version and pull in the version from the Microsoft.Net.Compilers.Toolset package (whichever version you use) - but it requires the GeneratePathProperty="true" attribute on the PackageReference.

[monoblaine]

@CZEMacLeod If, for some reason, you're still using ASP.NET MVC and .NET Framework, migrating to PackageReference is not an option. Even so, I tried adding <RoslynToolPath>..\packages\Microsoft.Net.Compilers.Toolset.5.3.0\tasks\net472</RoslynToolPath> to csproj file and it works. However, if you also want to use the <RoslynCopyToOutDir>false</RoslynCopyToOutDir> option it won't work. You still need to use the Web.config/appSettings configuration.

[CZEMacLeod]

Yes, this was to make it copy the files from the newer compiler. It requires no Web.Config changes.

I use aspnet framework and mvc with PackageReference instead of packages.config without issue, even without switching to Sdk style projects.

Ymmv.

[monoblaine]

Thank you, I'll look more into it.

[iJungleboy]

@tvatavuk fyi