Julien writes:
PSS is the first line of contact for issues and if you contact them and tell them about your issue we will look into it. If we have a hotfix available for it, even if the SP is not yet released, we will provide you it. If we don't have a hotfix and your issue doesn't have a good workaround, we will make a hotfix for you (that's how they get done usually).
Now, first of all, I'd like to say that it is great this facility is there. There are problems with this set-up however: the fix is not made public, other developers don't know about the fix and will spend hours debugging code that is not flawed. There is however another problem with 'hotfixes'.
Say, I develop a certain tool, ABC, using only .NET 1.1. During development I run into some issues with .NET 1.1. and it turns out .NET contains some flaws. After long debug sessions and Google searches, I'm totally desperate and call PSS. PSS walks me through the scheme Julien described and I get a couple of hotfixes for my problems. However this is a serious problem. How are my customers able to run my tool ABC if they do not have the hotfixes?
Am I allowed to distribute the hotfix to all my customers and demo-application downloaders? It's my understanding I'm not allowed to. If I'm not allowed to, do my customers have to call PSS themselves? If so, isn't that a little silly?
It's then far better to release a service pack, or a roll up, every month like the COM+ team did for years. Then, a customer of tool ABC can be pointed to the latest service pack for .NET 1.1. and there are no problems. That's support that actually works; the roll ups come with documented fix lists so they are easily findable in the KB search. Developers just have to install the latest roll up and they're set. Customers of tools like ABC: ditto.
I hardly dare to ask but: "Why is .NET support not like this and how are tool vendors able to solve this Hotfix problem?"