To all 3rd party control vendors: push MS to release hotfix 887818

I've had it completely with Microsoft's Hotfix policy for VS.NET 2002/3. This is the most lowest form of support you possibly can get. What's the problem? Well, the (in)famous 'Cannot copy assembly <Referenced Assembly> to file <Current Project Output Folder>\bin\Debug\Release\<Referenced Assembly>.dll. The process cannot access the file because it is being used by another process' error.

The thing is, Microsoft already fixed it in October 16th, 2004. That's right, almost 9 months ago. Please see the details of this crappy bug and its fix here:;en-us;887818

My problem is that I have to support my customers who run into this error sometimes with our assemblies. They have it referenced in 1 ASP.NET application but still get this error once in a while. I'm pretty fed up with telling my customers there is a fix but they can't receive it from me because I'm not allowed to distribute the fix. That's right, I have it right here on my harddrive.

So, I'm pretty close to distributing the fix to my customers so they're happy and this stupid bug won't happen to them. But it's better if Microsoft does this. The fix is already available, all they have to do is to make it a public download. Perhaps if all ISV's who sell / distribute signed assemblies which are used in ASP.NET applications (as that's the problem, the assemblies can't be signed apparently) and which aren't in the GAC push MS to release this hotfix, we ALL are better of.

After all, it's been 9 months since the fix, for crying out loud! Microsoft support? Don't make me laugh. Take this: in Open Source land, this wouldn't have happened: either the fix was distributable, or the fix was already in the core downloadable product. Microsoft, if you want to win from Open Source so badly, start by supplying fixes to the developers who are still on your side.


  • This year at TechEd US I had the opportunity to speak with a lot of PM from various teams, C#, ASP.NET, VB.NET and so on.

    I complained about lack of support and bug fixing and the only answers that I received were: &quot;we fixed it in VS2005&quot;...

    Yes... but I want that for my crappy VS.NET not for a future version that I have to pay for...

  • I get this all the time, very irritating.

    I've also had the pleasure of struggling with ImageLists and PNG alpha-values, the &amp;&quot;^*&#163; DataGrid, Theme support causing NullExceptions, lack of Themed controls (TabPage, etc..).

  • Its a good patch. Maybe the answer is to publicise it a lot.

    If it is in the first results for &quot;Cannot copy dll&quot; on Google, then people should find it.

    If enough people call and ask for it maybe the will take a more active stance.

  • This has been a huge problem for my team for quite some time, both in debug and release builds.

    I have contacted Microsoft to receive the hotfix. I was told by the VS.NET 2003 C# support person that this hotfix has been requested by many developers. I was the third one today.

    I was also told that we should see a service pack for VS.NET 2003 in the August/September timeframe.

  • Thanks Rob for the info :) They apparently see a spike in the calls, good, perhaps SOMEONE pays attention and says 'Hey,... how about starting up some regression testing on those year old patches?&quot;.

    What I find strange is that they reveal a release date of the SP to a customer while we MVP's got a date under NDA...

  • You don't have to exit VS.NET. Just close down the solution and re-open it. Sure it still takes time but it much faster than shutting the whole evironment down and restarting.

    -- Robert

  • Lorenzo, i totally share your pain with this attitude. &quot;Upgrade or perish&quot; is total BEE-ESS. Seriously, MS - if you don't support the people who speak on how awesome your stuff is and instead tell them &quot;if you don't like it upgrade to the new stuff we haven't released and don't support [either] and you won't have to deal with it any more&quot; you'll end up losing them - US - too.

  • Actually, you do have to exit VS.NET to make the problem go away. Since devenv.exe has the lock on that file a simple close solution does not work. I have tried it many times.


  • In my experience, renaming and then deleting the locked .dll will also help. No need to restart Visual Studio at all. Still, a great pain in the ass.

  • It's not only VS.NET that is supported very badly. It also happens with the .NET Framework itself. This is even worse, because end-users need to request hotfixes from MS.

    Microsoft describes in KB884871 that the Server property of the SqlError always returns an empty string. I investigated the code with Reflector and the property only contains return String.Empty, so this is pretty obvious. It's not a real bug, they probably didn't have time to implement it anymore. Microsoft fixed it and provides a hotfix for it, so it now works. So far, so good...

    Unfortunately, they changed the internals of this class that breaks serialization. A SqlError generated by the old version cannot be deserialized with the new version anymore (and vice versa). So it becomes difficult to pass a SqlException to another system if it uses a different version.

    The hotfix is included in Windows Server 2003 SP1, but not in .NET Framework v1.1 SP1. After our customers upgraded to Windows Server 2003 our software didn't work anymore. Client systems needed to be upgraded with the hotfix, but we cannot supply it. Grrrr....

Comments have been disabled for this content.