asp.net - System.Web.MVC not copied into bin folder since MS14-059. How to protect against creating builds with missing DLLs as a result of Windows Updates? -

asp.net - System.Web.MVC not copied into bin folder since MS14-059. How to protect against creating builds with missing DLLs as a result of Windows Updates? -

this morning reported our web app on our qa server broken next error reported web.config:

could not load file or assembly 'system.web.mvc, version=5.1.0.0, culture=neutral, publickeytoken=31bf3856ad364e35' or 1 of dependencies. scheme cannot find file specified

remembering seeing windows update mentioned mvc, did digging , found lots of people reporting recent windows update breaking mvc.

after much digging through questions , our server, seems what's bitten not match what's in other questions, appear related. here's think know:

our app broken uses asp.net mvc 5.1 mvc installed via nuget our buildserver , qa servers not have mvc 5.1 installed (therefore, not gac'd)

what believe has broken caused "bad build" created:

a patch mvc 5.1 installed on buildserver via windows update despite not having mvc 5.1 installed in gac the patch has set "updated" version of mvc 5.1 in gac copylocal=true ignored when dll in gac; hence since patch, means builds of our app buildserver no longer have system.web.mvc in output folder since system.web.mvc not in gac on our qa servers (they have not yet been patched), application fails, because system.web.mvc cannot found

assuming behavior described above correct, means time ms service nuget dll via windows update that not have in gac, our buildserver start producing incomplete builds (missing out dlls have been injected gac).

upgrading mvc 5.2 solves issue (likely because wasn't patched, , hence not injected gac); dll copied output folder. there no changes in diff upgraded 5.2.2 except version number changes (there's no <private> node been added/edited).

we not wish start gacing everything, nor creating manual build steps re-create of our dlls bin folder in case ms patches them.

so, can alter today ensure don't ever end out buildserver silently producing bad builds if ms patch other dlls in future?

a patch mvc 5.1 installed on buildserver via windows update despite not having mvc 5.1 installed in gac

yes, behavior design. see http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx.

the patch has set "updated" version of mvc 5.1 in gac

yes, that's correct; it's how patch gets updated code run instead of old code. see https://technet.microsoft.com/en-us/library/security/ms14-059.

copylocal=true ignored when dll in gac; hence since patch, means builds of our app buildserver no longer have system.web.mvc in output folder

not exactly. happens project copylocal=true gets switched copylocal=false. copylocal can set in 1 of 2 ways: 1) if there's explicit <private>true</private> setting in .csproj file, or 2) default, if no such setting exists (gac'd assemblies not copylocal default; other assemblies do).

so appears have happened in case project file didn't have setting in csproj file. result, gui showed setting based on evaluated default value before patch (copylocal = true) after patch installed, gui show new default value gac'd assembly (copylocal = false).

since system.web.mvc not in gac on our qa servers (they have not yet been patched), application fails, because system.web.mvc cannot found

that's correct.

assuming behavior described above correct, means time ms service nuget dll via windows update not have in gac, our buildserver start producing incomplete builds (missing out dlls have been injected gac).

for .csproj reference without explicit <private>true</private> setting, correct. also, note using nuget update mvc reference can remove setting if present. see http://nuget.codeplex.com/workitem/4344.

upgrading mvc 5.2 solves issue (likely because wasn't patched, , hence not injected gac); dll copied output folder. there no changes in diff upgraded 5.2.2 except version number changes (there's no node been added/edited).

that's correct. since mvc 5.2 not gac'd, without explicit <private>true</private> setting, default value of non-gac'd assembly copylocal=true.

we not wish start gacing everything, nor creating manual build steps re-create of our dlls bin folder in case ms patches them. so, can alter today ensure don't ever end out buildserver silently producing bad builds if ms patch other dlls in future?

the best can today is:

put explicit <private>true</private> settings in .csproj file nuget bundle assembly references. until nuget bug #4344 fixed, time utilize nuget update bundle reference, go .csproj file , re-add explicit <private>true</private> setting.

asp.net .net asp.net-mvc windows security