Why is `dotnet publish` not including Roslyn for my ASP.NET Framework 4.8.1 Web App?
I converted my .NET Framework 4.8.1 Web Application to SDK-style projects (like Microsoft recommended).
I think I've worked out all of the quirks except for the publish piece.
For some reason, the publish likes to modify my web.config and add stuff to it not included in the original.
It also is not including the roslyn folder in the bin folder in the published output.
ANYWAY. I worked around the web.config getting molested. Now I just (I think) need to find a way to include the
bin\roslyn folder in the published output.
I've tried uninstalling and reinstalling Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Reinstalling it did change the web.config section just a tad from what it was, but it works while debugging in Visual Studio.
I've also tried just uninstalling that nuget package, but the website fails to run with it removed.
Thanks for your advice.17 Replies
excuse my lack of knowledge, but why would an asp app need some kind of roslyn directory in the output?
because that’s how it compiles the razor files
mhh
how did you convert it to SDK-style exactly? the .NET SDK doesn’t support ASP.NET 4.x on its own, and if it works it is by accident
I did a combination of the Upgrade Assistant and manually fixing the breakage it caused. The Upgrade Assistant did a SDK-only upgrade.
can you post your csproj file?
Eh, it's huge and proprietary
This is one of those "Do this before you migrate to .NET" things and I've wasted about 1.5 weeks on getting this one thing to work before moving on to .NET upgrade.
Well, not exactly on this one thing, but it's been a couple of weeks since I did the SDKification.
While I hate the idea of reaching into the build output and including it in the output, whatever this is is likely to be a short-term fix. my build output includes the roslyn folder. Is there an easy way to just include that in the publish output?
well. to be clear. SDK-style projects don’t support ASP.NET 4.x. there is a long issue where people are asking for it to be supported https://github.com/dotnet/project-system/issues/2670. some people have written custom SDKs to let you use SDK-style projects, but they are, of course, not by Microsoft, and i doubt that upgrade-assistant did that for you
Why in the WORLD did Microsoft encourage us to migrate to SDK-style first before migrating to .NET???
This has been a phenomenal waste of my time
I mean, I had no problems with other csproj files
Windows services, etc.
yes, it is a fine thing to do for non-ASP.NET projects
Why not put a huge warning: Don't do this for ASP.NET projects?
what upgrade assistant is supposed to do—well, what it says it does—is it creates an ASP. NET Core project with a reverse proxy that forwards anything you haven’t migrated yet to the old application https://learn.microsoft.com/en-us/aspnet/core/migration/inc/overview?view=aspnetcore-9.0
Incremental ASP.NET to ASP.NET Core update
Incremental ASP.NET to ASP.NET Core migration
I didn't go down that path. I only selected the SDK-style project option
That is a legitimate option in the tool.
well, the article claims it’s the only option
https://learn.microsoft.com/en-us/aspnet/core/migration/mvc?view=aspnetcore-9.0
In Solution Explorer, right click on the project to upgrade and select Upgrade. Select Side-by-side incremental project upgrade, which is the only upgrade option.anyway. that’s beside the point
YUCK, but I got the output I wanted 😄
Your only support channel for that is the GitHub repo, https://github.com/CZEMacLeod/MSBuild.SDK.SystemWeb/issues. If you find some useful tips, you might share with the audience there in case they hit the same issue.
Okay, so this is weird. I'm thinking that perhaps the .NET Framework 4.8.1 devpack is compatible with .NET Framework Runtime 4.8?
It looks like we have one of our .NET Framework 4.8.1 apps deployed to a server running Windows Server 2019. And that app appears to be running fine, though it did fail to install netfx-4.8.1. But it already has .NET Framework Runtime 4.8 installed.