Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Mar 05, 2019 @ 09:58
    Peter Duncanson

    Error with "Microsoft.CodeDom.Providers" when trying to run compiled V8 source

    I've got the latest source code from yester (and did a pull today to see if anything changed over night). I've got it compiling now but it won't run and throws a YSOD when I "Ctrl + 5" in Visual Studio:

    The CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be located.

    I've followed the instructions on the quick start guide (massively worried this is out of date):

    I'm running VS Community v15.9.7 and have installed both .NET Framework 4.7.2 and the developer pack but still no luck.

    What on earth can I try next? When googling the error I get references to blogs from 2014 talking about enabling the Rosyln compilers with mentions that they are still in "beta" which can't be right. What am I doing wrong?

  • Stephen 767 posts 2265 karma points c-trib
    Mar 05, 2019 @ 10:28

    weird. tried to clear the solution before rebuilding? force-restoring nuget packages? empty the bin directory entirely?

  • Tom Madden 207 posts 274 karma points c-trib
    Mar 05, 2019 @ 10:58
    Tom Madden

    I had something similar and found different projects within the soltion had different versions of that package installed, updated the older one to match and that solved that issue once I also updated the other 5 packages where this happened.

    I was running my own branch and merging in from what was temp8 every now and then when this happened. Put it down to being pre-release at that time (or a mistake I made somewhere along the way)

  • Sebastiaan Janssen 4876 posts 14511 karma points MVP admin hq
    Mar 05, 2019 @ 11:45
    Sebastiaan Janssen

    So at first, it was you own NuGet server messing with you (as I read on Slack).

    Have you tried to run .\build\build.ps1 now so it can try to reset all the dependencies? Also delete \src\Umbraco.Web.UI\web.config since you've probably got the wrong bits in there now installed by the Offroad nuget server's dependencies.

    In general, always a good idea if it doesn't work to try the build script.

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Mar 05, 2019 @ 12:07
    Peter Duncanson

    I've got a big long reply with all the things I've tried in draft for all the other folks who might get this odd error. I think its my machine and what I'm doing not Umbraco's fault but I'll document it here in a bit in case anyone has this query issue and raise an issue on github for a few quirks I've found so it should "just work" for others in future.

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Mar 05, 2019 @ 14:45
    Peter Duncanson

    Urgh. So learnt some things along the way.

    • Deleted all my DLL's from the /bin folder.
    • Had to rebuild the Umbraco.Web.UI project separately (right click on it in solution explorer and select "Rebuild" from the pop up menu).
    • Ran the /build/build.ps1 file in a powershell window (this takes a long time btw)

    That got rid of the error and got me to another error about ClientDependancy Logger! But that taught me some new stuff:

    • Switching between a v7 branch and a v8 branch gets you in trouble. Seems there are lots of config files that are ignored and when you switch around they don't get over-written so you end up running v7 config on a v8 site. This to me shouldn't happen but I found a line on the quick start guide ( that does warns me to do a fresh check out of v8! Stupid Pete. So I've now done a fresh check out of just the dev-v8 branch.
    • I've run the build.ps1 file again a fresh and then rebuild all my DLL's in VS with a right click on the solution file in the solution explorer window and selecting "Rebuild"
    • This got things working!

    Thanks all.

  • Benjamin Carleski 5 posts 77 karma points c-trib
    Mar 05, 2019 @ 22:36
    Benjamin Carleski

    Another option would be to add a dependency on the Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix package instead of the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package. The .BinFix adds a target which copies the compilers in automatically before building.

Please Sign in or register to post replies

Write your reply to: