Repository navigation
Retarget the .NET Framework examples to net481 - #36
Merged
Merged
Conversation
The integration packages target net481 as of their latest releases, so net472 could not take them. Autofac 6.5.0 to 9.3.2 across all six projects, plus Autofac.Mvc5 7.0.0, Autofac.Wcf 8.0.0, Autofac.Web 8.0.0, Autofac.Owin 8.0.0, Autofac.WebApi2 7.0.0, Autofac.WebApi2.Owin 7.0.0, Autofac.Multitenant 9.0.1, and Autofac.Multitenant.Wcf 7.0.0. ASP.NET MVC, Razor, WebPages, OWIN, and Newtonsoft.Json also move to current. Three binding redirects had to move with them. Microsoft.Bcl.AsyncInterfaces goes to 10.0.0.11, System.Threading.Tasks.Extensions to 4.2.4.0, and System.Web.Mvc to 5.3.0.0. Autofac needs a redirect it never had: every integration package is compiled against 9.3.1.0 while these projects now load 9.3.2.0, and web projects get no auto-generated redirects the way the self-host exe does. Without it the apps throw at startup, and a build-only CI would never notice. Redirect versions were read from the built output rather than guessed, and cross-checked against what MSBuild generated for WebApiExample.OwinSelfHost. Part of #32
System.Web.Mvc, System.Web.Optimization, and System.Web.WebPages all reference Microsoft.Web.Infrastructure 1.0.0.0, but 2.0.0.0 is what ships in bin. The mismatch predates the net481 retarget; it surfaced while computing which redirects the retarget needed, and leaving it would keep these three examples from starting. Part of #32
9 tasks done
Appending new entries left each assemblyBinding in insertion order, and it was already unsorted before that: System.Web.Mvc sat after System.Web.WebPages, and WebGrease ahead of Antlr3.Runtime. Alphabetical means the next addition has an obvious home instead of landing at the bottom. Reordering only; the entries themselves are unchanged. Part of #32
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #32
Proposed Changes
net472tonet481. This wasn't optional: the integration packages targetnet481as of their latest releases, sonet472couldn't take them.Microsoft.Bcl.AsyncInterfaces→ 10.0.0.11,System.Threading.Tasks.Extensions→ 4.2.4.0,System.Web.Mvc→ 5.3.0.0.9.3.1.0, and these projects now load9.3.2.0. On .NET Framework that mismatch is fatal, and web projects get no auto-generated redirects the way the self-host exe does. Without this the five web apps throw at startup.Microsoft.Web.Infrastructureredirect. This one predates the retarget —System.Web.Mvc,System.Web.Optimization, andSystem.Web.WebPagesall reference1.0.0.0while2.0.0.0ships inbin. It's split out so it's reviewable on its own, but leaving it would mean three examples still don't start.How the redirect versions were determined
Not by guessing. I read the assembly versions out of the built output with
System.Reflection.Metadata, walked everyAssemblyRefin each project'sbin, and flagged each reference whose version differs from the assembly actually shipping alongside it. That produced the required redirect set per project, which I then verified against theWeb.configfiles. As a cross-check, the values match what MSBuild auto-generated forWebApiExample.OwinSelfHost.exe.config, which is the one project that gets redirects for free.Existing redirects for
System.Web.Helpers,System.Web.WebPages,WebGrease, andAntlr3.Runtimewere left alone. Static analysis says they're currently satisfied, but runtime Razor view compilation can need them and that isn't visible from the build output.What is and isn't verified
All six projects build clean in Release with zero warnings, and both gates pass.
No runtime verification was possible. These are .NET Framework web and self-host apps; they can't run on macOS, and CI only builds. Everything above about redirects is derived from assembly metadata rather than observed at startup, which is exactly why I computed it instead of eyeballing it — but a real startup test on Windows is the only thing that proves it. Worth a spot-check by someone who can run one of the web examples under IIS Express before this is trusted.