Omer asks me why we do in place servicing for .Net framework SP, and not following our own recommended practice of using publish policy.
This is an excellent question. And I am sure many many people have the same question in mind.
There are several reasons:
1. Publisher Policy can be opted out by applications.
In App.Config you can say publisherPolicy=”No”, effectively ignore any publisher policy. Majority of the fixes in SP are security fixes. We don’t want people to opt out security fixes.
In retrospection, the reason we introduce publisherPolicy=”No” is for app compat. Since then the thinking has been shifted to security first.
2. Framework assemblies are tested in a group. And we want to ship them in a group.
This is the same reason we introduce framework unification policy. We tested all the framework assemblies in redist SP together. And we ship them together. Say we shipped publisher policy. If you intend to opt out publisher policy, you end up with a configuration we did not test, and we do not want to support. Of course if you do not intend to opt out publisher policy, then it makes no difference for you whether we use publisher policy or not.
The bottom line is the current policy system is not optimal for .Net framework Servicing, and we intend to change that in future releases.