For those of you unaware:
There is still a seemingly random problem with the VB .Net 2005 Compiler (And yes everyone of our developer machines has the recently released patch installed). Basically a DLL project somehow gets corrupted on a specific machine, and any project that references that DLL immediately begins getting compiler errors (even on load of the .NET Project). From that point on that machine can no longer load any project that references that dll.
Note:
- Disabling edit and continue does absolutely nothing
- Completely deleting the files and copy over fresh WORKING projects from another developer machine does nothing (the errors still occur)
Up to yesterday the only way to get past this problem was to completely rebuild the project from scratch (New Project Name, etc) then delete the references and reference the new project. In 5 months of development we have had this happen 3 times, and this 3rd time it occurred I got frustrated and started picking apart the project from every angle I could think of. Finally when I changed the Assembly GUID and rebuilt it immediately fixed the issue.
Again, this is more of a bug report as a question. I know there is come guys still out there scared of this problem recocurring for them and how frustrating it can be in a large solution environment.
Jason
Workaround for Compiler Error That Was NOT FIXED BY THE PATCH
coyly
(Just to confirm your other point: this issue would indeed be orthogonal to the issues that the recent fix addressed – different area of code. In fact, it wouldn’t even be a compiler issue at all per se, since basically the compiler just consumes the assembly information that’s passed to it from the project properties.)
Thanks for the report!
--Matt--*
LHill
Folks here may very well indeed be looking into it and I just don’t know about it. I just want to make sure that you’re satisfied that someone here is looking into it, and if not, let’s make sure that it happens. (Like I said, the issue could very likely fall upon an allied team, and I may not necessarily have visibility on any progress on it – once they go out of my scope, I’m not always current.)
The source safe angle is very interesting, since as I alluded to in my previous post, it really does seem like something’s not in sync on a check-in.
--Matt--*
lucadb
Well Mathew, I had figured you guys were already looking into it. If you take a look at the long Compiler error thread, you will see posts by many people:
Breeze, Charles.Burrins, Matthew Sorvaag
who all directly told you about a slightly different error, the same one i am getting. I cant say for sure that the patch did not resolve it for any of them, as they did not post again afterwords, but I would be guessing there is 2 serious problems here, one has been fixed but the other remains.
The error:
System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
is the one that we constantly get thrown at us. You cannot edit/change code, load your project, even access project properties without having to click ok to repeated error messages. As to a point you mentioned, we dont edit/touch the assembly info in any way, just create simple references to our libraries.
And unfortuantely (I guess :)), I am not experiencing the problem at the moment to submit a bug report again. When it occurs again I will defenitely follow your instructions.
One final note, that I am sure you will love :), was the developer who began receiving this error the last time, had it occur to him first thing in the morning after a fresh reboot... Sequence of events (I am 100% sure):
a) Developer working in the project.
b) End of day arrives, Checks project into source safe (last person to do so)
c) Reboots the computer for the night
d) Logins in first thing in the morning, loads project and the errors immediately begin.
Thats honestly what scares me the most (Am glad I now have a workround). Was there was always no warning or no apparent reason why it would get corrupted any of the times that it happened.
A few notes about the project if it helps at all:
- There is about 10 libraries, all which inherit forms from one base plugin library.
- All these libraries reference a our own custom "Grid" library, and inherit Column/Row/Cell objects out of the project to provide extremely customized grid support.
- The Grid Library appears to be the one that somehow gets corrupted as other projects are referencing it, even though we rarely load it/make any changes.
Fun stuff.
Jason